drop SECURITY_FILE_CAPABILITIES? (fwd)
by James Morris
How might this affect the Fedora kernel?
---------- Forwarded message ----------
Date: Tue, 10 Nov 2009 08:07:39 -0600
From: Serge E. Hallyn <serue(a)us.ibm.com>
To: lkml <linux-kernel(a)vger.kernel.org>
Cc: linux-security-module(a)vger.kernel.org, Andrew Morgan <morgan(a)kernel.org>,
Steve Grubb <sgrubb(a)redhat.com>, Kees Cook <kees.cook(a)canonical.com>,
Andreas Gruenbacher <agruen(a)suse.de>,
Michael Kerrisk <mtk.manpages(a)gmail.com>,
George Wilson <gcwilson(a)us.ibm.com>
Subject: drop SECURITY_FILE_CAPABILITIES?
Hey,
Just a probe to see what people think. I've seen two cases
in about the last month where software was confounded by
an assumption that prctl(PR_CAPBSET_DROP, CAP_SOMETHING)
would succeed if privileged, but not handling the fact
that SECURITY_FILE_CAPABILITIES=n means you can't do that.
Are we at the point yet where we feel we can get rid of
the SECURITY_FILE_CAPABILITIES=n case?
Note that there is a boot arg no_file_caps which prevents
file capabilities from being used if SECURITY_FILE_CAPABILITIES=y.
I think that's the case most users will care about, whereas the
remaining differences between CONFIG_SECURITY_FILE_CAPABILITIES=y
and =n are that with CONFIG_SECURITY_FILE_CAPABILITIES=y :
(1) certain security hooks (task_setscheduler, task_setioprio, and
task_setnice) do capability set comparisions,
(2) it is possible to drop capabilities from the bounding set,
(3) it is possible to set per-task securelevels,
(4) and it is possible to add any capability to your inheritable
set if you have CAP_SETPCAP.
Does anyone know of cases where CONFIG_SECURITY_FILE_CAPABILITIES=n
is still perceived as useful?
thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
14 years
Checking if running kernel compiled with CONFIG_PREEMPT
by planetf1
I have a 2.6.31 kernel from F12.
I believe I've built it with CONFIG_PREEMPT but given the intracacies of
the rpm build, what's the easiest way to check an installed kernel to
see if that flag had been used during build?
Thanks
Nigel.
14 years, 1 month