Messages in this thread | | | From | "Sean Hunter" <> | Date | Mon, 12 Apr 1999 14:17:43 +0100 | Subject | Re: current->uid |
| |
>From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl> >Date: Sun, 11 Apr 1999 22:02:45 -0400 >Subject: Re: current->uid
><kernel@vdr.qc.ca> said:
>[...]
>> 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.
He hasn't said how he's going to show files in the filesystem as being his new root uid. I presume he intends to leave them as uid 0 and then start them up as the new root uid. If this is the case it won't protect against known exploits in files, because they will just be started up with the root uid. He'll also have to map files written as uid == root to uid 0 when they get written to disk. Also, you'd have to prevent files being written/read as any of the uids in your array of 500 possible users or would have to have them all = root in the filesystem too. Neither of these solutions seems very attractive to me.
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.
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.
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.
Sean Hunter
- 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/
| |