Messages in this thread | | | Date | Tue, 10 Nov 2009 09:23:35 -0800 | From | Kees Cook <> | Subject | Re: drop SECURITY_FILE_CAPABILITIES? |
| |
Hi,
On Tue, Nov 10, 2009 at 08:07:39AM -0600, Serge E. Hallyn wrote: > 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?
It seems to me that the process caps bounding set (and file caps) are the way forward and retaining the =n option is nonsense, especially since caps are an integral part of the kernel.
> Does anyone know of cases where CONFIG_SECURITY_FILE_CAPABILITIES=n > is still perceived as useful?
Building a kernel that willfully ignores fscaps? I don't see the point. It saves only a few bytes of code, AFAICT, and if it needs to be disabled for some reason, the kernel boot option "no_file_caps" can be set.
At the very least it should default to "y" and/or have its help updated to include the list of things it enables.
-Kees
-- Kees Cook Ubuntu Security Team
| |