[lkml]   [1998]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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?



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:2.452 / U:0.736 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site