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: <200911101251.21703.sgrubb@redhat.com>
Date:	Tue, 10 Nov 2009 12:51:21 -0500
From:	Steve Grubb <sgrubb@...hat.com>
To:	"Serge E. Hallyn" <serue@...ibm.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?

On Tuesday 10 November 2009 10:53:49 am Serge E. Hallyn wrote:
> > > 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.

Unfortunately, I would have to support the kernels from 2.6.26->2.6.32 which 
presumably don't have this facility. So, I'm kind of stuck. I think in a 
previous discussion you mentioned that I could call getcap or 
prctl(PR_CAPBSET_READ) and check for CAP_SETPCAP. I think I have to go that 
direction for backwards compatibility.

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?

Another irritation...if I want to clear the bounding set, I have to make a for 
loop and call prctl 34 times (once for each bit). I'd rather see a v4 
capability that takes the bounding set as part of the same syscall. Maybe all 
3 of these could be fixed in the same OS release so that changing to v4 also 
signifies the other behavior changes.

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