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

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