[lkml]   [2003]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: posix capabilities inheritance
    On Thu, Oct 23, 2003 at 05:05:40PM -0500, Michael Glasgow wrote:
    > Even with selective capability inheritance enabled in this fashion,
    > it is still possible to avoid using it and modify programs directly,
    > if you think that's more secure. Personally, I think that in some
    > cases it's slightly more secure to have a very small (statically
    > linked) setuid wrapper program which sets up capabilities properly
    > than to make a very large program setuid-root (when it was not
    > designed to run as root), only to add one capability.
    > Yes, you can do the capability-setup first thing in main()... but
    > this is occasionally insufficient. Also, it makes it a pain to
    > have, for instance, a backup user with CAP_DAC_READ_SEARCH who is
    > able to run several apps, e.g. dump, tar, cpio, rsync, etc. from
    > a restricted shell.
    > The code to drop privs is not hard, but it's also not trivial.
    > Those without a clue are just as likely to screw it up as they are
    > a wrapper; and anyway since when did it become a design goal for
    > the kernel to cater to the ineptitude of the clueless? That sounds
    > more like a Redmond, Washington philosophy than one fit for Linux. :-)

    Modifying source code requires programming capabilities, which means
    that the most clueless won't do it at all. It's something that needs
    to be done by the upstream authors, or perhaps by the distributions,
    at which point the clueless will get it when they upgrade.

    It's not matter of catering to the ineptitude of the clueless but
    pursueing a design which doesn't leave an open manhole cover where a
    clueless system administrator can screw up and put their entire system
    at risk. Consider that even if the distributions ship a package using
    your system, there will be a config file which will be an opportunity
    for a system administrator to screw up. In general, for any
    particular system program, there is only one acceptable setting in
    terms of what capabilities it will need. So why make it be something
    which can be screwed up in a config file?

    Fix it once, by a programmer who knows what he/she is doing, and the
    problem is fixed for everyone. Furthermore, it will be more efficient
    since it avoids an exec and requirement for a program to parse a
    config file.

    - Ted
    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: 2005-03-22 13:58    [W:0.025 / U:11.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site