How might this affect the Fedora kernel?
---------- Forwarded message ----------
Date: Tue, 10 Nov 2009 08:07:39 -0600
From: Serge E. Hallyn <se...@us.ibm.com>
To: lkml <linux-ker...@vger.kernel.org>
Cc: linux-security-mod...@vger.kernel.org, Andrew Morgan <mor...@kernel.org>,
Steve Grubb <sgr...@redhat.com>, Kees Cook <kees.c...@canonical.com>,
Andreas Gruenbacher <agr...@suse.de>,
Michael Kerrisk <mtk.manpa...@gmail.com>,
George Wilson <gcwil...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
