Messages in this thread | | | Subject | Re: [PATCH 1/2] file capabilities: add no_file_caps switch (v2) | From | Stephen Smalley <> | Date | Mon, 22 Sep 2008 15:16:04 -0400 |
| |
On Mon, 2008-09-22 at 13:48 -0500, Serge E. Hallyn wrote: > (Resend of two patches from late August. If noone objects, would it be > possible to see this pair take a turn in security-testing?) > > Add a no_file_caps boot option when file capabilities are > compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).
Is there a reason you didn't just use a filecaps=0/1 approach ala the selinux= boot parameter? And let the default value be selectable as well?
> This allows distributions to ship a kernel with file capabilities > compiled in, without forcing users to use (and understand and > trust) them. > > When no_file_caps is specified at boot, then when a process executes > a file, any file capabilities stored with that file will not be > used in the calculation of the process' new capability sets. > > This means that booting with the no_file_caps boot option will > not be the same as booting a kernel with file capabilities > compiled out - in particular a task with CAP_SETPCAP will not > have any chance of passing capabilities to another task (which > isn't "really" possible anyway, and which may soon by killed > altogether by David Howells in any case), and it will instead > be able to put new capabilities in its pI. However since fI > will always be empty and pI is masked with fI, it gains the > task nothing. > > We also support the extra prctl options, setting securebits and > dropping capabilities from the per-process bounding set. > > The other remaining difference is that killpriv, task_setscheduler, > setioprio, and setnice will continue to be hooked. That will > be noticable in the case where a root task changed its uid > while keeping some caps, and another task owned by the new uid > tries to change settings for the more privileged task.
Seems a bit confusing to offer a no_file_caps option with different behavior than disabling it at build time.
BTW, I think Fedora kernel have had CONFIG_SECURITY_FILE_CAPABILITIES=y for quite some time. Not that they are using it AFAIK, but the kernel support has seemingly been enabled.
> Signed-off-by: Serge Hallyn <serue@us.ibm.com> > Acked-by: Andrew G. Morgan <morgan@kernel.org> > --- > kernel/capability.c | 13 +++++++++++++ > security/commoncap.c | 11 +++++++++++ > 2 files changed, 24 insertions(+), 0 deletions(-) > > diff --git a/kernel/capability.c b/kernel/capability.c > index 33e51e7..5d034ec 100644 > --- a/kernel/capability.c > +++ b/kernel/capability.c > @@ -33,6 +33,19 @@ EXPORT_SYMBOL(__cap_empty_set); > EXPORT_SYMBOL(__cap_full_set); > EXPORT_SYMBOL(__cap_init_eff_set); > > +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES > +int file_caps_enabled = 1; > + > +static int __init file_caps_disable(char *str) > +{ > + file_caps_enabled = 0; > + return 1; > +} > +__setup("no_file_caps", file_caps_disable); > +#else > +static const int file_caps_enabled = 0; > +#endif > + > /* > * More recent versions of libcap are available from: > * > diff --git a/security/commoncap.c b/security/commoncap.c > index e4c4b3f..8c66d34 100644 > --- a/security/commoncap.c > +++ b/security/commoncap.c > @@ -27,6 +27,12 @@ > #include <linux/prctl.h> > #include <linux/securebits.h> > > +#ifdef CONFIG_SECURITY_FILE_CAPABILITIES > +extern int file_caps_enabled; > +#else > +static const int file_caps_enabled = 0; > +#endif > + > int cap_netlink_send(struct sock *sk, struct sk_buff *skb) > { > NETLINK_CB(skb).eff_cap = current->cap_effective; > @@ -279,6 +285,11 @@ static int get_file_caps(struct linux_binprm *bprm) > struct vfs_cap_data vcaps; > struct inode *inode; > > + if (!file_caps_enabled) { > + bprm_clear_caps(bprm); > + return 0; > + } > + > if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) { > bprm_clear_caps(bprm); > return 0; -- Stephen Smalley National Security Agency
| |