lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Capabilities
    Date
    In article <Pine.LNX.4.21.0002101833050.20618-100000@ferret.lmh.ox.ac.uk>,
    Chris Evans <chris@ferret.lmh.ox.ac.uk> wrote:
    >On Thu, 10 Feb 2000, Matthew Kirkwood wrote:
    > > [Peter Benie wrote:]
    > > > 1) Permitted capability set for setuid programs
    > > >
    > > > I want setuid root programs not to have all capabilites. cap_bound is
    > > > not the answer since I still want some programs that are started from
    > > > the system initialisation scripts to run with all capabilities.
    > >
    > > Mmm.. I'd like that too.
    >
    > You'll get that when the filesystem support for capabilities goes in.

    Filesystems without capabilities will exist for a _long_ time, and
    people will want to be able to use them for setuid root programs. How
    about diskless clients mounting their root filesystem over NFS?

    > Alternatively, tighten up the bounding set as part of your system
    > initialisation scripts.

    As Matthew points out, that doesn't work since it affects all
    processes, not just setuid processes.

    I haven't really figured out what the bounding set is for. It doesn't
    seem to do anything that couldn't be done trivially by using wrappers
    in inittab to remove capabilities from the inheritable set a la Irix.

    And I'm puzzled by the capabilities given to init. Why doesn't init
    run with all capabilites? cap_setpcap is a subset of cap_sys_admin
    (because of mknod and /dev/kmem) so I see no point in not making
    setpcap inheritable from init.

    > > > 2) Inherited capability set for setuid programs
    > > >
    > > > It is possible to run a non-capability-aware setuid-root program from
    > > > an environment that has cap_setuid-i. This prevents the program from
    > > > using setuid() to demote privilege back to a non-zero uid (unless that
    > > > uid was the real, effective or saved uid). This is a security risk
    > >
    > > The whole lot, or merely CAP_SETUID?

    The whole lot, so we get the old behaviour for setuid root back.

    > > I see no reason that these two shouldn't be sysctls. Want
    > > a patch?
    >
    > It feels like functionality for the sake of it.

    The behaviour of the inheritable capabilities when doing setuid
    emulation changes the assumptions that setuid programs are allowed to
    make - setuid root programs are expected to be capability aware.

    This makes me very nervous since it is impossible to analyse what the
    possible consequences of this are without reading the source to every
    setuid root program. I would be much happier if setuid emulation
    accurately implemented the traditional behaviour of setuid root since
    that brings us back to the status quo. It may not be ideal, but it
    doesn't introduce any extra problems.

    I haven't come up with an example of an exploit involving the
    inheritable capabilities, but I can say where I would start looking.
    Choose a program that uses more than two uids as part of its operation
    (ie. your uid, 0, and something else). Queuing systems are good
    candidates. I'll pick exim (an MTA). Run it with cap_setgid+i and
    cap_setuid-i. (IME, programs check the return value from initgroups
    but don't check for setuid; exim is no exception.) Now check in /proc
    which uids exim is running with. Oops - it's running as root when it
    shouldn't be.

    > Once we've got some proper, extensive _real world_ use of capabilities,
    > we'll be in a better situation to evaluate what tweaks/additions are
    > required. Quite a lot of capabilities complaints boil down to
    > "theoretically, this could be an issue" rather than "I've been using
    > capabilities to do X, and came across this issue"

    Solving the theoretical problems makes the design secure.
    Solving the practical problems make the design usable.

    It is in the nature of security holes that code is pushed beyond the
    limits of what the author expected. Assuming that certain input data
    will never happen is likely to lead to security holes, therefore you
    should consider problems that you consider merely 'theoretical'.
    Only looking at practical problems will tell you a lot about the API,
    but will tell you little about how secure the design is.

    Peter

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

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