Re: current->uid

Andrea Arcangeli (kernel@vdr.qc.ca)
Mon, 12 Apr 1999 17:26:43 -0400 (EDT)


On Mon, 12 Apr 1999, Sean Hunter wrote:

> >> OK, but there won't be such system call. The goal of this is to set an
> >> array of 500 possible users that could be root (including 0). This would
> >> mean that an exploit would have to try many uids before getting somewhere,
> >> and if root is paranoid, he can change his ID 5 times a day. Then the
> >> exploits would only work for a fairly short time.
>
> >Exploits usually work by taking over an pivileged process, so this won't
> >help a bit. Or they work by cracking root's password in some way, and
> >loging in normally. Your scheme won't protect against any of those.
>
> Actually, its even worse than this, because Papi has already said that
> he would iterate all the processes that are running with uid ==
> root_uid and change them to the uid of the new root uid when root's
> uid changes. This of course means that once your evil crackers binary
> is running with root privs it keeps getting "helpfully" updated to the
> new root uid when root's uid changes.

Very good point.

> The implications for NFS are interesting. What happens when you NFS
> mount a volume that has files owned by UID's that are part of the
> array of root uid's. Bingo! They get root access! (or at best get
> root access when the root uid changes to equal theirs) From then
> onwards, they have total power, and can read and write as uid 0, and
> also get their UID remapped to root_uid when the uid changes.

Not quite. Because only one of the uids in the array would have been
considered root at a given time. And of coarse, no normal user would have
been given one of these uids.

The main exploit I was aiming to disable was as a matter of fact an nfs
expoit. And I was planning to disallow root access over nfs unless a given
user had the right uid.

It would have been fun, but I've learned from some replys that this would
have not been a good idea to start with.

>
> You still have to have uid 0 being root as well, or you break just
> about every binary that runs as root, but changes its euid to
> drop/raise privaleges (a lot of daemons do this). You'll also break
> the security of a lot of stuff that checks to make sure its not uid 0
> before running. It could now run insecurely as root_uid without
> really knowing.

Well, the point of this would have been for the system to keep the special
uid transparent to the application layer. As most of the access control is
beeing done by the kernel anyway.

>
> Presumably he's going to have to hack libc to check /proc/root_uid
> every time any process wants to do something privaleged (eg connect
> to a low port). He's also going to have to change kill and many other
> tools so that root_uid can kill other users processes, shutdown the box
> etc. This is bound to open a real can of worms.
>
> The whole thing seems extremely ill-concieved and astoundingly
> foolish. Based on what the poster has shown here, he has no real
> understanding of unix security at all. If he insists on writing this,
> I only hope his tutors know more about unix than he does.

Hmm, the point of writting this mail was to get some feedback from
hardcore kackers. While I will not insist on writting this, I still
beleive that it could have been done in a secure way (anyway, what is so
special about the number 0).

Maybe I don't know everything about UNIX security, but I guess we all have
to start somewhere. While I have been using UNIX/Linux for a few years and
don't consider myself a beginner or an expert, I do know enough about OSs
and C programming to do something usefull for Linux.

As it is impossible to know everything in computer sciences, I don't think
it is appropriate to insult people like this. I am learning from these
replys, and maybe in a few years I hope to be some help to some, or maybe
just one of you. Untill then, I beleive that it is possible to point to
some weaknesses without insulting me so bad. Unless, of coarse, you've
been born with your UNIX skills, remember that you are just an
ex-beginner/intermidiate/good/very good/etc UNIX user.

Thank you

Papi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/