lkml.org 
[lkml]   [1999]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.066 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site