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: <20080228234850.GA25829@infradead.org>
Date:	Thu, 28 Feb 2008 18:48:50 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	casey@...aufler-ca.com, Dave Quigley <dpquigl@...ho.nsa.gov>,
	hch@...radead.org, 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, Feb 28, 2008 at 02:30:35PM -0500, Stephen Smalley wrote:
> This is an interface to be used by NFS to get information from the
> security module.  The information desired is specific to the MAC
> labeling functionality in NFSv4 that is being proposed.  That
> functionality is MAC specific (necessarily so, just like the ACL
> functionality is ACL specific).  We are hiding the SELinux-specific bits
> behind the LSM interface, and non-MAC LSMs are free to return NULL in
> order to indicate that they don't support MAC labeling.  We do NOT want
> the capability module to return its security blob here, or any other
> non-MAC LSM - it will yield the wrong semantics for the NFS MAC support.

I think Casey is totally right here.  The LSM interface should not be
as specific here.  If you want to limit the NFSv4 interface to single
MAC xattr label based systems add an additional method to check if
the LSM is that.  But the proper fix is of course to not add somthing
so specific to NFSv4 at all, as it's got enough shortcoming already.
Please add a proper xattr protocol.  It's not like it's hard, SGI
has been doing this in IRIX for NFSv3 for ages as a sideband protocol,
and even release the reference source under the GPL.  Just either use
that with NFSv4 or if you feel fancy merge it into the NFS spec for
NFSv6^H4.2.

> In any event, I don't think we need your permission.

Wow, that's rude even to someone as direct as me.  Casey is the only
other person having an in-tree LSM, and I think his input in this
area is important.  But if not I as a VFS person can happily give
you my "no" for the current version from the VFS point of view.

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