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  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 <>
To:	Stephen Smalley <>
Cc:	Casey Schaufler <>,
	"David P. Quigley" <>,
	James Morris <>,
	"J. Bruce Fields" <>,,,,,,,,,
Subject: Re: [PATCH 06/10] NFSv4: Add label recommended attribute and NFSv4 

On Mon, Jul 12, 2010 at 10:36, Stephen Smalley <> 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:

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

Kyle Moffett
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists