Re: RFC: Security feature: partly prohibit process uid-changing

Alexander Kjeldaas (astor@fast.no)
Tue, 23 Feb 1999 13:18:30 +0100

On Tue, Feb 23, 1999 at 11:59:45AM +0100, Ph. Marek wrote:
> How about implementing a new field in the process structure, which gives
> the SMALLEST possible uid for this process? standard would be 0, but could
> be raised by all|root to any other value, maybe root could want lower it too.
>
> that would primarily be used in servers, where e.g. after a setreuid() the
> uid should NEVER AGAIN become 0 (chroot() environments). this flag would be
> given to the children too.
> that should prohibit use of SETUID programs too ...
>
> the standard cases would be 0 (normal usage) and 1 (no root anymore), maybe
> 100 (no daemon-uid's).
> We would need a syscall for that and preferable an entry like
> /proc/*/security.
>
>
> I think that something like that wouldn't make much work - I volunteer for
> that, although I have not much knowledge in kernel hacking. but if someone
> looks at my piece of code, I'd write it.
>
>
> comments? is that A Right Thing To Do?
>

I don't think this is a good idea. There is no smooth scale from
"unprivileged" to "privileged". Processes need different kinds of
privilege, and access to a set of UIDs which is individual for each
process. Trying to cram this into a linear scale won't work.

I see the need for more flexible mechanisms for switching UIDs, but
don't think your proposal is flexible enough. The examples you give
where you want it to be impossible for a process to obtain any sort of
root privileges are enforceable without any changes - set the
inheritable set of the executing process to 0.

A more flexible way of doing this would be to allow UIDs to be passed
over a socket - that way the policy can be put in a user-land daemon
and we can implement whatever policy the application needs.

astor

-- 
 Alexander Kjeldaas, Fast Search & Transfer, Trondheim, Norway


-
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/