Prev: writeback cleanups and trivial fixes
Next: [PATCH net-next] drivers/scsi: Remove warnings after vsprintf %pV introduction
From: Kyle Moffett on 11 Jul 2010 01:10
On Fri, Jul 9, 2010 at 10:05, David P. Quigley <dpquigl(a)tycho.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Casey Schaufler on 11 Jul 2010 01:20
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.

> Cheers,
> Kyle Moffett
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kyle Moffett on 16 Jul 2010 20:20
On Mon, Jul 12, 2010 at 10:36, Stephen Smalley <sds(a)tycho.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: writeback cleanups and trivial fixes
Next: [PATCH net-next] drivers/scsi: Remove warnings after vsprintf %pV introduction