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:	Fri, 29 Feb 2008 08:30:06 -0500
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Dave Quigley <dpquigl@...ho.nsa.gov>, casey@...aufler-ca.com,
	viro@....linux.org.uk, trond.myklebust@....uio.no,
	bfields@...ldses.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr
	name


On Thu, 2008-02-28 at 20:00 -0500, Christoph Hellwig wrote:
> On Thu, Feb 28, 2008 at 07:32:47PM -0500, Dave Quigley wrote:
> > I can always go with the original hook name of get_security_xattr_name
> > which turns into a security_get_security_xattr_name call which seems a
> > bit ludicrous. The only other complaint that I saw from Casey besides
> > the name of the function was that there could be more than one xattr. If
> > we want to address that then I need another hook that says give me all
> > data that the LSM deems important for this file. Which is essentially
> > the same thing as taking each of the xattr names that the module will
> > provide, grabbing each of them in turn, and concatenating them together.
> > For SELinux this is no different than getsecurity with the selinux
> > suffix. The same goes for SMACK.
> 
> What about Casey's suggestion of get_security_blob?  For any reasonable
> module that just has a single xattr it's trivial and for those that
> have multiple or a different storage model it might get complicated
> but that's not our problem for now.

Possibly I'm missing something, but if I'm implementing a security
module that has any security attribute at all, e.g. capability module
with security.capability, and I see a hook called "get_security_blob" or
"get_security_attr" or the like, I'll implement that hook and return my
attribute there.  Which in turn will _break_ the labeled NFS
functionality because it is expecting a MAC label specifically.

The whole point here is that we do not want modules like capability to
return their security attributes here, because this is to support
labeled NFS functionality in support of enforcing MAC.

I don't especially care about the hook name per se, but the interface
(whatever it may be) needs to convey the proper semantics, and the
semantics truly are MAC specific (and should be).


-- 
Stephen Smalley
National Security Agency

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ