Messages in this thread | | | Date | Sun, 11 Apr 1999 13:37:44 -0400 (EDT) | From | <> | Subject | Re: current->uid |
| |
On Sun, 11 Apr 1999, Holger Thon wrote:
> 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?
OK, what I meant by faking some values is that a super-uid process should be seen by others as a root process. This could be done by making some simple system calls lie about them. And to my opinion, just a few system calls would have to lie.
As for readability, comments are a good start, and since at my university they are very strict about documenting every single detail, I could make documentation available in linux/Documentation.
> > 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.
Well, I don't think that is exactly true. To make a file writable in /proc, I have to implement a struct file_operations (witch has a write method). In that method, I can personnaly check the uid of the current process and return an appropriate error message.
> > 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.
Good question, in the write method, I can block interruptions, then do a for_each_process(p) and change all the super-user's processes to the new super-uid. Then, reable interrupts.
> > 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... ;-)
Good point, but it is possible to say that we put 500 possible roots. Let's say from 500-1000. Normal users would use higher uids. And since the root account shouldn't be used for regular uses, it wouldn't be a problem. Root would only start daemons, and as it is today, all of the jobs he started will be priviledged with the same advantages and disadvantages they have today.
> > > 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. ~:-)
OK, I've been studying the sources for 8 mounths now. I feel that I know what I'm doing. And I am aware that this can not be done in a few days, but keep in mind that this project in meant to measure my knowladge of computer sciences. It has to be relativly big anyways.
> > > 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.
Also, I plan to give a user the option to compile this support or not to compile it in the kernel. But this, couldn't be done as a module for fairly obvious reasons. And I will do my best to make tha code as stable and highly tested as possible.
Thanks a lot 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/
| |