lkml.org 
[lkml]   [2002]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Filesystem Capabilities in 2.6?

    On Sat, 2 Nov 2002, Oliver Xymoron wrote:
    >
    > Bindings are cool, but once you start talking about doing a lot of
    > them, they're rather ungainly due to not actually being persisted on
    > the filesystem, no?

    Well, they _are_ persistent in the filesystem, although in this case "the
    filesystem" is /etc/fstab.

    It's not that different from the ".capabilities" file, except it's a lot
    more explicit, and from an implementation standpoint it's a lot easier.

    However, I think there is a problem with Al's original approach: the bind
    can _not_ be just a mask that takes away capabilities from a suid
    application, since that would imply that the app has to be marked suid in
    the first place (and accessing it _without_ going through the bind will
    give it elevated privileges, which is what we're trying to avoid).

    So the bind would have to _add_ capabilities, not take them away.

    That's not really a problem, and the advantage of the filesystem bind
    approach is that it is extremely explicit, and it is trivial for a
    maintainer to at all times see all such "elevated" binaries: as Al points
    out, the only thing you need to do is to just ask to be shown the mount
    list with "mount" or with "cat /proc/mounts".

    > A better approach is to just make a user-space capabilities-wrapper
    > that's setuid, drops capabilities quickly and safely and calls the
    > real app.

    This is _not_ a good approach from a sysadmin standpoint. The sysadmin
    does not explicitly know what the suid binary does internally, the
    sysadmin just sees a number of suid binaries and has to trust them.

    Yes, I realize that your example had "showcapwrap" etc sysadmin tools to
    work around this, and make the wrapping be transparent to the sysadmin.
    That certainly works, although it still depends on trusting that the
    wrapping cannot be confused some way. I guess that could be done fairly
    easily (although I think you'd want to make "mkcapwrap" actually _sign_
    the wrapped binaries, to make sure that nobody can later try to inject a
    "bad" binary that _looks_ ok to "showcapwrap" and fools the admin to think
    everything is ok).

    But from a security maintenance standpoint, wouldn't it be _nice_ to be
    able to

    - do a complete "find" over the whole system to show that there is not a
    single suid binary anywhere.

    - trivially show each and every binary that is allowed elevated
    permissions (and _which_ elevated permissions) by just doing a "mount".

    - and since the mount trees are really per-process, you can allow certain
    process groups to have mounts that others don't have.

    I think that as a anal-retentive security admin, I'd like such a system.

    Linus

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:3.054 / U:0.292 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site