> kernel@vdr.qc.ca wrote:
> > Hello,
> >
> > I am student in computer sciences at a university somewhere in
> > Quebec Canada. For my final project I have to change the kernel to allow
> > root's uid to change dynamicly.
>
> Something like "echo 1234" > /proc/root_uid" ?
>
> And from that moment on, "uid 1234" has root-powers, but not uid 0?
>
> Well, "init" will already be running, and have uid 0. It won't like
> its powers taken away.
True, but in the write method of the /proc file, it is fairly easy to do a
for_each_process(p) and change the uid of all priviledged processes, so
init will get the new super-uid.
> There is a macro "suser" in older kernels that did something like
>
> return (current ->uid == 0)
>
> which is now replaced by capabilities stuff. That capabilities stuff
> is much better.
>
> Replacing that macro with
>
> return (current->uid == root_uid)
>
> and declaring the root_uid variable isn't more than 15 minutes
> work. Getting the proc interface working might take the rest of the
> day. I don't think that the "level" of this assignment is valid for a
> final project.
Maybe, but there are more implications. What about nfs and NO_ROOT_SQASH,
ore what about /etc/hosts.equiv ? Memory manadgment in also an issue here
since priviledged processes are allowed to get_free_pages even in very low
memory situations.
These are just a few examples, and I am now at the stage of looking for as
many implications as possible in order to write properly design an
apropriate tactic that would deal with all of this. Anyway, just fully
understanding all the aspects of the kernel is in it's self a finality.
>
> But what will all this gain you? A program classically requiring
> "root" to run, will now run under "1234", and getting that program to
> do "exec /bin/sh" will still give a root-power-shell.
>
> And if you're afraid that current exploits are doing
> setreuid (0,0);
> exec ("/bin/sh");
> or
> cp /bin/sh /tmp/.sh
> chown 0 /tmp/.sh
> chmod 4755 /tmp/.sh
>
> then you should realize that the first needs to be rewritten to:
> t = geteuid ();
> setreuid (t,t);
> exec ("/bin/sh");
>
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.
> and that the second has an extra "chown" that serves no purpose except
> to make it fail when your patch is installed. Without the chown, it will
> work with and without the patch!.
>
> > I would just like to know why this has never been done, and what
>
> Because it is a stupid idea.
>
> > are the implications of this. Also, would such a patch be considered to
> > become official some day or would this just sit in some folder of an
>
> No.
>
> > unknown university hidden getting just a bit dustier every year ?
>
> Yes.
>
> Roger.
OK, this sounds like a valid opinion... Thank you for your feedback.
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/