lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 09:23:35 -0800
From:	Kees Cook <>
To:	"Serge E. Hallyn" <>
Cc:	lkml <>,,
	Andrew Morgan <>,
	Steve Grubb <>,
	Andreas Gruenbacher <>,
	Michael Kerrisk <>,
	George Wilson <>


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

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 Cook
Ubuntu Security Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists