lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: Capabilities
    On Thu, 10 Feb 2000, Chris Evans wrote:

    > > I don't believe that this is functionality for its own sake. If
    > > you think or it as a sysctl which allows you to turn off bits of
    > > SECURE_NO_SETUID_FIXUP.
    >
    > It _is_ functionality for its own sake, because the design of the
    > capabilities system gives you the tools you need.

    But the implementation doesn't.

    This is the same argument which we heard against a capability
    bounding set, and I consider it thoroughly bogus in both cases.

    > We will have filesystem support soon.

    I see no evidence of that. The last patch I saw (admittedly,
    I haven't been looking hard for one) was against 2.1.xx, and
    used reserved space in the ext2 inode which has since been
    used for other things. Linux has available a pair of __u32s
    in the on-disk inode which is not sufficient, I believe[0].
    reiserfs has no inode space reserved for future expansion.

    I am not saying that these are good things but merely that I
    can't see filesystem-format inducing changes arriving in a
    great hurry for so little direct gain.

    > Once you have that, the solution becomes one of userspace setup rather
    > than kernel support. Complexity is better in userspace than the
    > kernel.

    Don't claim that this is complexity. A(n untested) patch to
    implement it is appended to this email. It really is that
    easy.

    > We don't want to introduce temporary kernel tweaks between now and
    > such time as we have filesystem support for capabilities, because then
    > people will _use_ that support and we could get stuck with it.

    The all-powerful-root legacy is so great that the additional
    hassle of rooting out problems caused by this change are far,
    far outweighed by its usefulness, IMHO.

    Matthew.

    [0] My thinking is somewhat slow today, but as I recall the
    fs caps implementation wants to include all three sets,
    yes?


    --- linux-2.3/include/linux/capability.h.capsetuid Thu Feb 10 19:55:06 2000
    +++ linux-2.3/include/linux/capability.h Thu Feb 10 19:55:36 2000
    @@ -276,6 +276,11 @@
    extern kernel_cap_t cap_bset;

    /*
    + * Privs that setuid-root programs get
    + */
    +extern kernel_cap_t cap_setuidset;
    +
    +/*
    * Internal kernel functions only
    */

    --- linux-2.3/include/linux/sysctl.h.capsetuid Thu Feb 10 19:56:33 2000
    +++ linux-2.3/include/linux/sysctl.h Thu Feb 10 19:57:50 2000
    @@ -110,7 +110,8 @@
    KERN_SPARC_STOP_A=44, /* int: Sparc Stop-A enable */
    KERN_SHMMNI=45, /* int: shm array identifiers */
    KERN_OVERFLOWUID=46, /* int: overflow UID */
    - KERN_OVERFLOWGID=47 /* int: overflow GID */
    + KERN_OVERFLOWGID=47, /* int: overflow GID */
    + KERN_CAP_SETUIDSET=48 /* int: capabilities given to suid-root programs */
    };


    --- linux-2.3/kernel/sys.c.capsetuid Thu Feb 10 19:52:21 2000
    +++ linux-2.3/kernel/sys.c Thu Feb 10 20:06:04 2000
    @@ -350,7 +350,8 @@
    cap_clear(current->cap_effective);
    }
    if (old_euid != 0 && current->euid == 0) {
    - current->cap_effective = current->cap_permitted;
    + current->cap_effective = cap_intersect(current->cap_permitted,
    + cap_setuidset);
    }
    }

    --- linux-2.3/kernel/sysctl.c.capsetuid Thu Feb 10 19:52:39 2000
    +++ linux-2.3/kernel/sysctl.c Thu Feb 10 19:59:37 2000
    @@ -253,6 +253,8 @@
    {KERN_OVERFLOWGID, "overflowgid", &overflowgid, sizeof(int), 0644, NULL,
    &proc_dointvec_minmax, &sysctl_intvec, NULL,
    &minolduid, &maxolduid},
    + {KERN_CAP_SETUIDSET, "cap-setuidset", &cap_setuidset, sizeof(kernel_cap_t),
    + 0600, NULL, &proc_dointvec},
    {0}
    };

    --- linux-2.3/kernel/capability.c.capsetuid Thu Feb 10 20:00:44 2000
    +++ linux-2.3/kernel/capability.c Thu Feb 10 20:00:35 2000
    @@ -17,7 +17,7 @@
    * uninteresting and/or not to be changed.
    */

    -kernel_cap_t cap_bset = CAP_FULL_SET;
    +kernel_cap_t cap_bset = CAP_FULL_SET, cap_setuidset = CAP_FULL_SET;

    asmlinkage long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
    {

    -
    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.023 / U:0.860 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site