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:53:49 -0600
From:	"Serge E. Hallyn" <>
To:	Steve Grubb <>
Cc:	lkml <>,,
	Andrew Morgan <>,
	Kees Cook <>,
	Andreas Gruenbacher <>,
	Michael Kerrisk <>,
	George Wilson <>,
	KaiGai Kohei <>

Quoting Steve Grubb (
> On Tuesday 10 November 2009 09:07:39 am Serge E. Hallyn wrote:
> > 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?
> As a library writer, I wished that the kernel behavior was either consistent, 
> or there is an API that I can use to find out what model we are operating 
> under. The biggest issue is that for a distribution we know the assumptions 
> the distribution should be running under. But end users are free to build 
> their own kernel that has it disabled. This has already lead to dbus not 
> working at all.
> I also take issue with probing the capability version number returning EINVAL 
> when its the only way to find out what the preferred version is.

In 2007/2008, KaiGai had floated patches to export capability info
over securityfs.  If it was something library writers and distros
wanted, we could resurrect those patches - and tack on some info
about cap-related kernel config.

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