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