lkml.org 
[lkml]   [2009]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH v2] Unprivileged: Disable raising of privileges
    Quoting Eric W. Biederman (ebiederm@xmission.com):
    > "Serge E. Hallyn" <serue@us.ibm.com> writes:
    >
    > > Quoting Andrew G. Morgan (morgan@kernel.org):
    > >> Eric,
    > >>
    > >> I'm not clear why capabilities need to be manipulated by this feature
    > >> (the pure capability support already has a feature for disabling
    > >> privilege and blocking unsafe, or insufficient privilege, execution).
    > >
    > > Not entirely - this option would also prevent file capabilities from
    > > being honored.
    >
    > All my patch does is verify the caller doesn't have privilege.

    No, you shortcut security/commoncap.c:get_file_caps() if (bprm->nosuid),
    which is set if test_tsk_thread_flag(current, TIF_NOSUID) at exec.

    So if we're in this new no-suid mode, then file capabilities are not
    honored.

    Which is the right thing to do.

    > >> Perhaps I'm just unclear what features can be more safely enabled with
    > >> this in effect - that is, your description suggests that this is why
    > >> you are doing this, but leaves it unclear what they are. Could you
    > >> take a few moments to enumerate some of them?
    > >
    > > There are two desirable features which are at the moment unsafe for
    > > unprivileged users, because it allows them to fool privileged (setuid
    > > or bearing file capabilities) programs. One is to unconditionally
    > > restrict privilege to yourself and all your descendents. The recent
    > > disablenetwork patchset is one example. The other is the ability to
    > > make substantial changes to your environment in a private namespace.
    > > A private namespace can protect already-running privileged program,
    > > but cannot protect privilege-bearing binaries. Unless we prevent
    > > them from bearing privilege. Which is what this patch does.
    >
    > Effectively by ensuring privileges can not be raised this removes
    > the set of circumstances that lead to the sendmail capabilities bug.
    >
    > So any kernel feature that requires capabilities only because not
    > doing so would break backwards compatibility with suid applications.
    > This includes namespace manipulation, like plan 9.
    > This includes unsharing pid and network and sysvipc namespaces.
    >
    > There are probably other useful but currently root only features
    > that this will allow to be used by unprivileged processes, that
    > I am not aware of.
    >
    > In addition to the fact that knowing privileges can not be escalated
    > by a process is a good feature all by itself. Run this in a chroot
    > and the programs will never be able to gain root access even if
    > there are suid binaries available for them to execute.
    >
    > Eric


    \
     
     \ /
      Last update: 2009-12-30 21:19    [W:0.024 / U:0.604 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site