Messages in this thread | | | Date | Sun, 11 Apr 1999 11:57:43 +0200 | From | Holger Thon <> | Subject | Re: current->uid |
| |
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. > > This would break some exploits, and might improve security > slightly. I've been studying the sources for 8 mounth now, and I feel this > could be done with an interface in /proc.
Well, your idea sounds good, but do you know what time you need to implement this? I'm just 1 month in kernel now, but with my very little knowledge i think it would take month to implement this. Additionally as a computer scientist you know that faking important values in code is bad for both readability and stability of the code. And who shall understand this years later?
Regarding to /proc implementation: For other users to change root uid, the proc file has to become group writable. Thus, all users of that group will increase the chance of a potential cracker to break into system with supervisor rights.
Regarding to uid: I don't think it's a problem to implement a code that let's a different uid read files of uid 0. But what do you expect to do with all the daemons running as root? They are started at boot time, with root rights. When root uid changes, all these processes have to get a new uid/gid.
And keep in mind the following situation: Root uid is changed to uid of user xy. User xy has started a program which is written in bad code. Now uid of this prog changes to root uid. It will become an additional threat to exploits. Of course you can change the uids of these progs to other uids, but at least this will end in an uid desaster. I.e. kernel doesn't know who is who. Panic... ;-)
Well, maybe my sight is too pessimistic, but i don't think that implementation of this is possible in reasonable time. But you are welcome to tell (maybe even proof?) me the opposite. ~:-)
Regards, Holger
> > I would like to have some feedbask from some more experienced > hackers. I know this sounds silly at first, but if tou make system calls > lie about the uid of super-user processes, and don't touch the file > system, this can be done relativly painlessly.
I hope this feedback doesn't offend you, but i think even if it can be realized it'll be a hard, long work.
> > I would just like to know why this has never been done, and what
Maybe because kernel code should remain readable. Also maybe this idea is too complicated to implement -> lack of time.
> 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 > unknown university hidden getting just a bit dustier every year ?
Well, if your ideas can be realized and safety will be improved (safety=stability and your idea of exploit protection), this might become part of kernel code. Though changes should be somehow transparent, i.e. nobody who just wants to USE uid operations must understand how the faking code works. Though, it might remain as a kernel patch (e.g. like the cryptofs). It remains on how usable and stable the code is.
Regards, Holger
- 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/
| |