Messages in this thread | | | Date | Wed, 30 Dec 2009 14:17:12 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [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
| |