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]

Date:	Wed, 18 Nov 2009 12:49:29 -0500
From:	Steve Grubb <sgrubb@...hat.com>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.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?

On Wednesday 18 November 2009 11:40:13 am Andrew G. Morgan wrote:
> >> But back to detecting the capability version number...if I pass 0 as the
> >> version in the header, why can't the kernel just say oh you want the
> >> preferred version number, stuff it in the header, and return the syscall
> >> with success and not EINVAL?
> 
> This is so a library can understand that it doesn't understand the
> current ABI.

If user space is passing a NULL for the cap_user_data_t argument, user space 
has a pretty good idea that its not expecting actual capabilities to be filled 
in. My basic point is that there is no way to "correctly" use the capabilities 
API to determine what the preferred version is.

> For example, consider the case of some kernel of the
> future with a different ABI meeting an old library.

Right. Either user space checks version numbers to verify it knows what its 
doing and errors out, or it blindly tries to set capabilities and gets an 
error. Either way, if user space is *really* using the API to do work, it 
won't be passing NULL as the user data argument.

Maybe if version is set to 0 and NULL is being passed for arg 2 to getcap, 
that would be the secret handshake that lets the kernel know all I want is the 
preferred version number and nothing else since there is no data structure to 
fill in.

> The intention is for it to fail safe and not blunder on doing
> "security" related operations with an imperfect idea of the current
> kernel interface.
> 
> This is how libcap figures out it can work with the hosting kernel:

capget(0x20080522, 0, NULL)             = -1 EFAULT (Bad address)

Still an error.

-Steve
--
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/