linux-kernel - Re: [PATCH 06/10] NFSv4: Add label recommended attribute and NFSv4 flags

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, 09 Jul 2010 09:47:50 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	James Morris <jmorris@...ei.org>
Cc:	"David P. Quigley" <dpquigl@...ho.nsa.gov>,
	"J. Bruce Fields" <bfields@...ldses.org>, hch@...radead.org,
	viro@...iv.linux.org.uk, casey@...aufler-ca.com,
	matthew.dodd@...rta.com, trond.myklebust@....uio.no,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	linux-nfs@...r.kernel.org
Subject: Re: [PATCH 06/10] NFSv4: Add label recommended attribute and NFSv4
 flags

On Fri, 2010-07-09 at 08:48 +1000, James Morris wrote:
> On Thu, 8 Jul 2010, David P. Quigley wrote:
> 
> > > The maximum security label size on Linux is:
> > > 
> > > #define XATTR_SIZE_MAX 65536
> > > 
> > > Why arbitrarily limit this over the network?
> > 
> > Because there is no easy way not to. The specification doesn't specify a
> > limit to label size in the IETF draft. However there is no way to do
> > allocation of the memory needed to store the label where we first get
> > access to its size. We tried this before and it failed. When I asked
> > trond about it he said doing memory allocation in the rpc context isn't
> > allowed.
> 
> In the NFSv3 code, the workaround I've been using is to always allocate 
> 64k, but the correct way of doing this apparently is to use the page 
> cache, as is used for ACLs and symlinks.
> 
> > For the most part what would make this label size inadequate would be 
> > the MLS component. There are some cases where people want every other 
> > compartment or something crazy like that. In terms of a normal label 
> > though 4096 should be more than enough.
> 
> Yes, but we should not unnecessarily limit the network protocol when 
> something is valid and possible in the local implementation (which is ~64k 
> under Linux).
> 
> > Just to put this in perspective the string below is 4096 a's.
> 
> A security label include just about anything, e.g. an x509 certificate, or 
> a base64 encoded image.
> 
> In the Linux implementation, if we can store a local label up to 64k, then 
> we should try and ensure that it can be conveyed via NFS.

You can't store a local label up to 64k on Linux; that is just what the
xattr API permits, not the underlying filesystem implementations (at
least ext[234]).

# touch foobar
# setfattr -n user.foo -v `perl -e 'print "a" x 4096'` foobar
setfattr: foobar: No space left on device

Also the /proc/self/attr and selinuxfs APIs are presently limited to
page size.

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