How might this affect the Fedora kernel?
---------- Forwarded message ---------- Date: Tue, 10 Nov 2009 08:07:39 -0600 From: Serge E. Hallyn serue@us.ibm.com To: lkml linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org, Andrew Morgan morgan@kernel.org, Steve Grubb sgrubb@redhat.com, Kees Cook kees.cook@canonical.com, Andreas Gruenbacher agruen@suse.de, Michael Kerrisk mtk.manpages@gmail.com, George Wilson gcwilson@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-11-10 at 18:00 -0500, Dave Jones wrote:
On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote:
How might this affect the Fedora kernel?
We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway.
google codesearch to the rescue:
http://google.com/codesearch?hl=en&sa=N&filter=0&q=prctl.*PR_CAP...
- ajax
On Wed, Nov 11, 2009 at 09:52:02AM -0500, Adam Jackson wrote:
On Tue, 2009-11-10 at 18:00 -0500, Dave Jones wrote:
On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote:
How might this affect the Fedora kernel?
We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway.
google codesearch to the rescue:
http://google.com/codesearch?hl=en&sa=N&filter=0&q=prctl.*PR_CAP...
afaik, that prctl is available regardless of the option being set. I meant I don't think anything we ship is using the file capabilities, which is a way of marking executable files with the caps they need instead of having them be setuid.
(I'm not even sure what tool we would use to set those capabilities, or if we ship it)
Dave
On Wed, 2009-11-11 at 11:32 -0500, Dave Jones wrote:
On Wed, Nov 11, 2009 at 09:52:02AM -0500, Adam Jackson wrote:
On Tue, 2009-11-10 at 18:00 -0500, Dave Jones wrote:
On Wed, Nov 11, 2009 at 09:56:57AM +1100, James Morris wrote:
How might this affect the Fedora kernel?
We set it =y, so it wouldn't affect us if I understand correctly. Also, I'm not sure that anything in userspace is actually using this feature yet anyway.
google codesearch to the rescue:
http://google.com/codesearch?hl=en&sa=N&filter=0&q=prctl.*PR_CAP...
afaik, that prctl is available regardless of the option being set. I meant I don't think anything we ship is using the file capabilities, which is a way of marking executable files with the caps they need instead of having them be setuid.
(I'm not even sure what tool we would use to set those capabilities, or if we ship it)
/usr/sbin/setcap from libcap
But you are right, Fedora makes no use of file capabilities anywhere in the distro to my knowledge.
-Eric
kernel@lists.fedoraproject.org