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:	Sun, 11 Jul 2010 01:02:59 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	"David P. Quigley" <dpquigl@...ho.nsa.gov>
Cc:	James Morris <jmorris@...ei.org>,
	"J. Bruce Fields" <bfields@...ldses.org>, hch@...radead.org,
	viro@...iv.linux.org.uk, casey@...aufler-ca.com, sds@...ho.nsa.gov,
	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, Jul 9, 2010 at 10:05, David P. Quigley <dpquigl@...ho.nsa.gov> wrote:
> On Fri, 2010-07-09 at 08:48 +1000, James Morris wrote:
>> 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).
>>
>> 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.
>
> If you want that to be the case you need to make your case to Trond
> about that. I've already had this conversation before and he seems to
> think that a page is sufficient. Bruce also has concerns about not
> wanting these labels to require a high order allocation. Under memory
> pressure finding 16 contiguous pages for each label might be a problem.

I would argue that if somebody wants to stick a base64-encoded image
or an x509 certificate in their security labels then shipping the
whole thing across the wire every time somebody does an extended
"stat" is just stupid.  Think about how much overhead there would be
if you did an "ls -Z" of a directory with 100 files (64k * 100 ==
6.4MB!!!), where that data would previously have fit in no more than
10-20k TOTAL.

A better solution would be something along the lines of putting at
most a SHA512 sum in the label field and have a separate caching
communication protocol (either in-band or out-of-band) to pass the
fully-descriptive payload.

Even in local filesystems like ext3 we prefer to turn labels into
numbers, store the number with each inode, and then keep the labels
indexed in a separate datastructure.

Cheers,
Kyle Moffett
--
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/