linux-kernel - Re: drop SECURITY_FILE

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20091110155349.GA18185@us.ibm.com>
Date:	Tue, 10 Nov 2009 09:53:49 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Steve Grubb <sgrubb@...hat.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Andrew Morgan <morgan@...nel.org>,
	Kees Cook <kees.cook@...onical.com>,
	Andreas Gruenbacher <agruen@...e.de>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	George Wilson <gcwilson@...ibm.com>,
	KaiGai Kohei <kaigai@...gai.gr.jp>
Subject: Re: drop SECURITY_FILE_CAPABILITIES?

Quoting Steve Grubb (sgrubb@...hat.com):
> 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.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/