Re: Securelevel bitmap patch

Richard Gooch (rgooch@atnf.CSIRO.AU)
Mon, 30 Mar 1998 09:30:56 +1000


Linus Torvalds writes:
>
> Yes. We already have a complete list of all processes, so globally
> removing some capability is a trivial matter of about 5 lines of code or
> so:
>
> read_lock(&task_list_lock);
> for_each_task(p) {
> p->capability &= mask;
> }
> read_unlock(&task_list_lock);

Or have a global mask, as has already been pointed out. Just trade off
the time for a global change with the time for each check.

> Oohh.. Yes, it costs you 32 bits per process. If you tell me you are
> worried about that, I tell you that you're either lying or have extremely
> poor judgement. In fact, you probably want another bitmask which specifies
> which bits can be inherited by children (if you have a capability to add
> capabilities, then you probably also want to specify that it is only added
> to this process, not to the children of this process - that way you can
> easily revert the capability forcibly if you want to at a later date).
>
> So yes, it could easily add 8 bytes per process.

Why is the capabilities mask for children needed at all? I would
assume that the init binary (for example) would be changed to do:
fork ();
/* Child */
rip_out_capabilities ();

As things stand now, any trusted binary (i.e. suid-root) does much the
same thing if needed (such as /bin/login), by calling setuid (),
seteuid (). We don't have a child process
"uid,euid,gid,egid,gid-saved-set" table either. So why do we need the
child capabilities mask?

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu