[lkml]   [2000]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Capabilities
       Date: Fri, 11 Feb 2000 22:35:32 +0100
    From: Pavel Machek <>

    But you can set allowed to ~0; forced to 0 for normal executables and
    ~0 to setuid root executables. BTW we should probably make forced set
    being honoured iff executable is suid root.
    PS: When I think of it, there's an easier way. Trash forced set. It is
    not neccessary.

    If you want to elevate some priviledges, make it setuid 0 (that will
    give it all capabilities) and you can now copy forced into
    allowed. You are done. You have nice compatibility (ls) for free, and
    you have 32 more bits for your use!


    There are a couple of philosophical questions hiding here. It's
    true the POSIX capability document never became a full standard, but
    died as only a draft. However, there are other implementations of that
    draft, most notably Trusted Irix, and Trusted HPUX. (Trusted Solaris
    isn't quite as close to the standard, and I don't know about the status
    of Trusted AIX; I believe it's fairly close to the draft POSIX
    capability as well.) So the first question is whether we want to try to
    conform to the last POSIX draft, and (as much as possible) be compatible
    with the other Trusted Unixes out there.

    Secondly, there is a philosophical principal here. Part of the
    entire Capability model is to adhere to the security principle of least
    privilege as much as possible. One of things that this means is to drop
    the idea that user ID 0 has any meaning whatsoever. So in a pure POSIX
    capability system, a program that is setuid 0 has the ability to have
    "owner" access to files that are owned by userid 0, but that's it. It
    means nothing more than that.

    The problem with making a program setuid root, and then trusting
    the program to drop the capabilities, is exactly that. You have to
    trust the program to do so correctly. That's why the POSIX capability
    model is done the way that it is done. A system administrator can look
    at an executable, and know exactly what privileges it can possibly ever
    use. If it can only create sockets whose port is below 1024, it will be
    obvious simply by looking at the flags. It also means that a program
    can be setuid to some non-zero uid, such as "smtp", so it can run as the
    "smtp" user, but still have access to a (limited) set of capabilities.

    Now, with all of that being said, if you don't want the full
    POSIX model, it's probably easier to simply leave things the way they
    are right now, and not try to put anything in the filesystem. Just
    simply allow programs to be setuid root, and then let them drop
    whatever capabilities they don't need as soon as they start running in
    main() --- hopefully before any stack overrun vulnerabilities have a
    chance to execute. :-)

    If you're going to restrict capabilities to work iff they are
    suid root, and if you're only going to trash the forced set and simply
    allow the program to drop privileges on its own, why make any changes at
    all? The functionality you propose we can do already, given what we
    already have.

    But if we want to support the full capability model, then we
    can't take shortcuts like that. As I said earlier, it's very different
    from the Unix model, and I'm not so convinced that sysadmins will be
    able to deal with it correctly. If we're going to try to do
    capabilities, however, we might as well try to do them right.

    - Ted

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

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