Re: posix capabilities inheritance

From: Albert Cahalan (albert_at_users.sf.net)
Date: 10/23/03

  • Next message: Nick Piggin: "Re: Nick's scheduler v16 - reaim" 
    To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Date:	22 Oct 2003 21:41:51 -0400

    Andy Lutomirski writes:

    > I agree with these problems, but I think the proper
    > fix is complicated. AFAICT, POSIX capability
    > evolution, as specified by whatever draft it was,
    > is broken, so the hacks in prepare_binprm
    > (cap_bprm_set_security in 2.6) are needed to avoid
    > security problems. Aside from the fact that
    > non-inheritable-by-default makes little sense
    > (and requires root to get capabilities re-added
    > from the file _permitted_ set), POSIX cap
    > evolution has some other problems:

    You've noticed! :-)

    The people who wrote the code were working from
    two different drafts of the spec. I think some
    people used draft 16, while others used draft 17.
    (or 15 and 16, or 17 and 18 -- a difference of 1)
    Between these two drafts there had been BIG changes.
    Well, a critical equation changed.

    People at SGI, mindlessly cloning the IRIX code,
    stuck us with the half-ass set of capability bits
    we have today. They ignored the DG-UX implementation
    using 256 bits and slightly different equations.
    They ignored the fact that the security model will
    be terribly inconsistent if you still have apps
    making UID-based decisions -- that is, you need to
    allocate bits for glibc, XFree86, Linux vendors,
    admin tools, various databases, and local site usage.
    Yes it's yucky, but it's required. Covering ears
    and burying the head won't make this go away.

    Nobody thought to have half the bits default
    to "on" for stuff currently allowed for regular
    users. For example, the right to listen for
    incoming network connections could be limited
    if this had been given a default-enabled bit.

    Then there's the emergency hack done to patch a
    security hole that the capability bits introduced.
    I think that was back in the early 2.4.x days.

    People like to ignore the fact that apps tend
    to answer "Do I need setuid-style precautions?"
    by examining UID.

    People like to ignore the fact that privileged
    code, written with setuid in mind, can lead to
    all sorts of mayhem if 42% of the privileged
    operations are prohibited. Yeah, you'd hope
    that a setuid app has great error checking and
    can cope... but "hope" shouldn't satisfy you.
    We really need a way for app authors to mark a
    binary as "always block rights P, Q, and R" and
    "block all rights unless given V, W, and X",
    with the assumption that an unmarked app requires
    an all-or-none situation.

    Probably there should be two worlds on the
    system. Apps with "funny" rights should be
    kept away from UID 0 and setuid apps, while
    apps with UID 0 or setuid should be kept
    away from "funny" rights. Give the init
    process a special ability to cross worlds.

    The authors of our code seem to have given up
    and moved on. Nobody cleaned up the mess.
    Is it any wonder the POSIX draft didn't ever
    make it beyond the draft state?

    (and damn, WTF is with !capable(...) meaning
    that you are capable of performing something?)

    One final horror: just imagine trying to write
    up some sane documentation for the average admin.
    Poorly-understood security mechanisms are a
    hazard. BTW, don't forget to imagine documenting
    all the interactions with UID, filesystems, etc.

    Face it: admins will think in terms of assigning
    rights to users, never minding that there are
    some weird equations, UID interactions, and
    perhaps per-executable bits.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Nick Piggin: "Re: Nick's scheduler v16 - reaim"

    Relevant Pages