Re: current->uid

Holger Thon (Holger.Thon@uni-duisburg.de)
Sun, 11 Apr 1999 11:57:43 +0200


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/