[lkml]   [2006]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: patch to make Linux capabilities into something useful (v 0.3.1)
    On Thu, Sep 07, 2006 at 06:02:45PM -0500, Serge E. Hallyn wrote:
    > Ok, so to be clear, in terms of inheritability of capabilities, your
    > three main changes are:

    Yes, this is a fair description:

    > 1. When creating a bprm, it's inheritable and effective
    > capability sets are set full on, whereas they used to be
    > cleared. The permitted set is treated as before (always
    > cleared)

    - This is to make capabilities inheritable but don't add any others
    except when executing suid root.

    > 2. When computing a process' new capabilities, the new
    > inheritable come from the new permitted, rather than the old
    > inheritable.

    - The reason for that is the necessity to preserve Unix semantics (see

    > 3. You change half the computation of p'E to replace fE by
    > pE in one half.

    - Again, to preserve Unix semantics (if a process with {r,s}uid=0 and
    euid!=0 does an exec(), the resulting process also has euid!=0, that
    is, no effective capabilities).

    > Here is one apparent change in behavior:
    > If I currently do
    > cp /bin/sh /bin/shsetuid
    > chmod u+s /bin/shsetuid
    > then log in as uid 1000 and run
    > /bin/shsetuid
    > # whoami
    > hallyn
    > # ls /root
    > ls: /root: Permission denied

    What does "currently" mean"? On an unpatched Linux, I believe (and
    observe) the following:

    * if your /bin/sh is bash, it purposely drops privileges (by doing
    something like setresuid(getuid(),getuid(),getuid()), I haven't
    checked the source), and this is the reason you get "Permission

    * if your /bin/sh is something else, it keeps euid==0 and you have
    root privileges all the way, including in children processes - this is
    traditional Unix behavior.

    My patch doesn't change any of this (I've checked), since it uses
    inheritance rules for capabilities which are closely modeled upon
    those of {r,s,e}uid (in fact, that's my very reason for "changing"
    things), and since the bash method of dropping privileges is also kept

    (I don't know *why* bash tries to drop privileges. It's probably an
    attempt at avoiding certain security problems, but I think it's a
    rather bad one.)

    > With your patch I believe it will succeed, since the sh process'
    > inheritable set will be set to it's permitted set.

    My patch doesn't change this behavior. Evidently, if it did, it would
    be very bad...

    > Put another way:

    I'm not sure why what follows is a restatement of what precedes, so
    I'll answer differently.

    > cap_set_proc("=i");
    > execve("/bin/shsetuid");
    > I obviously wanted my inheritable set to be cleared, but running the
    > setuid binary will end up resetting my inheritable set to a larger
    > set. Your goal of allowing the inheritable caps to be truly
    > inheritable may make sense, but this part of it feels wrong, and
    > changes current setuid behavior.

    In the current (unpatched) Linux kernel, the inheritable set is
    completely ignored anyway. :-( So certainly any attempt to make
    something of it must change the behavior.

    I agree that the above code snippet exhibits a difference of my patch
    w.r.t. the capabilities(7)-documented behavior (or at least, might,
    according to the way suid programs are interpreted), but this
    difference is

    (a) necessary in order not to break traditional Unix semantics
    (children of a program with euid==0 also have euid==0, and the father
    process can't avoid that), and

    (b) necessary for security reasons (it is imperative that the parent
    of a suid root process cannot prevent that process from keeping
    privileges, otherwise we get the sendmail bug again).

    To summarize my answer: as far as I know, my patch does not change
    suid behavior: I've taken great care not to let that happen. It does
    change the documented inheritance behavior of capabilities, but that
    is unavoidable.

    PS: I should be releasing a new version of my patch, along with a
    merged version of yours, very shortly.

    David A. Madore
    (, )
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-09-08 03:11    [W:0.032 / U:31.964 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site