><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/