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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 16 Jul 2010 20:09:23 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	"David P. Quigley" <dpquigl@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	"J. Bruce Fields" <bfields@...ldses.org>, hch@...radead.org,
	viro@...iv.linux.org.uk, 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 Mon, Jul 12, 2010 at 10:36, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> On Sat, 2010-07-10 at 22:12 -0700, Casey Schaufler wrote:
>> Kyle Moffett wrote:
>> > ...
>> > 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.
>> >
>>
>> I don't know what system you're talking about, but that notion
>> was pretty well dispelled in the late 1980's, after the SystemV/MLS
>> and SecureWare examples.
>
> SELinux did that too before switching to using xattrs for label storage.
> Persistent security identifier (PSID) associated with each inode (either
> stored directly in the inode in the original kernel patches or
> associated through a separate mapping in the LSM-based implementation),
> with a mapping from PSID to context stored in a mapping within each
> filesystem.  Allowed you to keep the labels with the volume but avoided
> storing the same label multiple times.
>
> The xattr based implementation can sometimes share storage but only when
> the xattr is stored in the additional block (not when they are stored
> inline) and only if all of the xattrs on the file are identical.

Hmm, for some reason I was still thinking that we stored an encoded
form of the label even in xattrs.  Whoops!

On the other hand, I guess it should be noted that the "common" case
of an SELinux label is the inline storage case, labels are on average
no more than ~40 bytes:
  system_u:object_r:sysadm_homedir_t:s0

In filesystems that are space optimized (like squashfs), we still
prefer to pack xattrs, symlinks, and even file permissions as tightly
as possible through table lookups of various forms.  Heck, the
read-only squashfs only stores a single empty-directory inode and
references it wherever needed.

On the other hand, if you're doing something completely silly with 64k
labels then any hope of inline storage went out the window along with
any space savings from nifty FS optimizations like de-duplication or
tail-packing.

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/