persistent labelling on afs, jfs, xfs?

persistent labelling on afs, jfs, xfs?

[forrest whitcher]

I am happy to be able to have SELinux work with Reiserfs, to 
have the data-reliability of journalling.

It seems that SELinux happily creates fs labels on reiserfs,
However on JFS volumes or AFS it will not (correctly) create 
the ...security PSID mappings. 

Interestingly, using a JFS filesystem, on a vanilla kernel
setfiles created the ...security/* structure, however the 
then-booted selinux kernel saw the files as ':unlabelled_t'

It looks possible to use jfs under SELinux with non-persistent
labels. Running 'setfiles /afs/cellname.dom/test_directory ' with
an appropriate rule in file_contexts results in correct mapping
of file contexts for the lifetime of that boot instance.

Attempting to map the AFS tree on a live SELinux kernel 
resulted in no ...security structure, however something
like 15% of the files / directories were assigned the context
which had been defined in file_contexts. There was appearantly
no consistency in which files were 'correctly labelled'

I'm guessing that this is due to the different filesystem
semantics of afs vs physical storage?

Under a vanilla kernel, setfiles created the ...security directory,
however the files "contexts, index, inodes" were zero-length.

Does anyone have ideas why the ...security psid structure works on reiser 
and not on jfs? Do people have experience with XFS or other journaled file 
stores? I assume ext3 works.

I have some concerns about continued stability with alternate filesystems. 
The following note suggests that there are differences in how inodes
are represented. Can anyone throw some light on why SELinux works
ok with reiser and AFS does not? It would be good to have the various
journalling filesystems maintaining structures that SELinux can
continue to operate on through future revisions. 

---- quote copied from the OpenAFS list

> I have problems with starting OpenAFS when the AFS cache is on a
> ReiserFS filesystem. It seems to work the first time after I install it,
> but crashes the next time the machine (or AFS resp.) it started. With
> the cache on an ext2 filesystem, it's ok. Don't know if this is SuSE
> related, because I get the same behaviour with a vanilla 2.4.7 kernel.
> Just thought I'd let you know.

This is Reiserfs related.  The problem is that Reiserfs breaks the
inode-number assumption (the assumption is that a file is uniquely
represented by a device number for the partition and an inode number).
Unfortunately reiserfs doesn't do this, so AFS cache wont work.
---- end quote


Note:

OpenAFS has been working on SELinux since OpenAFS snapshots in mid-
october and the subsequent release version 1.2.2. and on kernels 
2.4.10 & 12 I'm not sure about .16, but it almost certainly works. 
- Some problems in the afs kernel patch were resolved. 

Recent AFS releases still will not run on the original 2.2.19 SELinux 
prototype, possibly due to the changes which that version of SELinux
made to the ext2 filesystem. When time permits I may look and see 
if this was the reson that afsd was having problems on that kernel.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs?

[Stephen Smalley]

On Fri, 14 Dec 2001, forrest whitcher wrote:

> It seems that SELinux happily creates fs labels on reiserfs,
> However on JFS volumes or AFS it will not (correctly) create
> the ...security PSID mappings.

The SELinux kernel module only tries using a persistent label mapping if
it recognizes the filesystem type as being one of a set of known types
that are known to have persistent inodes.  See the superblock_precondition
function in the hooks.c file.  You can patch it to recognize additional
filesystem types if you wish.  However, note that for networked
or distributed filesystems, this isn't safe, since there is no mechanism
for coordinating updates to the mapping among the clients.

> Interestingly, using a JFS filesystem, on a vanilla kernel
> setfiles created the ...security/* structure, however the
> then-booted selinux kernel saw the files as ':unlabelled_t'

Right, this is what I would expect.  You have to patch the module to
recognize JFS before it will try using a persistent label mapping on it.

>I assume ext3 works.

Yes, ext3 works fine.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs?

[Stephen Smalley]

On Fri, 14 Dec 2001, forrest whitcher wrote:

> This is Reiserfs related.  The problem is that Reiserfs breaks the
> inode-number assumption (the assumption is that a file is uniquely
> represented by a device number for the partition and an inode number).
> Unfortunately reiserfs doesn't do this, so AFS cache wont work.

We haven't tested SELinux with reiserfs, but others have claimed that it
works.  However, if it is true that reiserfs doesn't have unique and
persistent inode numbers for files, then SELinux will have problems with
it.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs?

[Hans Reiser]

Stephen Smalley wrote:

>On Fri, 14 Dec 2001, forrest whitcher wrote:
>
>>This is Reiserfs related.  The problem is that Reiserfs breaks the
>>inode-number assumption (the assumption is that a file is uniquely
>>represented by a device number for the partition and an inode number).
>>Unfortunately reiserfs doesn't do this, so AFS cache wont work.
>>
>
>We haven't tested SELinux with reiserfs, but others have claimed that it
>works.  However, if it is true that reiserfs doesn't have unique and
>persistent inode numbers for files, then SELinux will have problems with
>it.
>
>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>
>
>--
>You have received this message because you are subscribed to the selinux list.
>If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>the words "unsubscribe selinux" without quotes as the message.
>
>
We currently have unique and persistent inode numbers (at least until we 
someday write a repacker that will optimize key assignments for better 
layout), but you can't use them for finding files that are not in the 
cache.  To find such files requires a key.

Hans



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs?

[Stephen Smalley]

On Sat, 15 Dec 2001, Hans Reiser wrote:

> We currently have unique and persistent inode numbers (at least until we
> someday write a repacker that will optimize key assignments for better
> layout), but you can't use them for finding files that are not in the
> cache.  To find such files requires a key.

SELinux uses the inode number as an identifier for the file in the
persistent label mapping in each filesystem.   So it doesn't find files
based on the inode number, but it needs each file in a filesystem to have
a unique and persistent inode number.  It sounds like reiserfs does
currently provide this property.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs?

[Hans Reiser]

Stephen Smalley wrote:

>On Sat, 15 Dec 2001, Hans Reiser wrote:
>
>>We currently have unique and persistent inode numbers (at least until we
>>someday write a repacker that will optimize key assignments for better
>>layout), but you can't use them for finding files that are not in the
>>cache.  To find such files requires a key.
>>
>
>SELinux uses the inode number as an identifier for the file in the
>persistent label mapping in each filesystem.   So it doesn't find files
>based on the inode number, but it needs each file in a filesystem to have
>a unique and persistent inode number.  It sounds like reiserfs does
>currently provide this property.
>
>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>
>
>
>
>

yes, so everything is easy for now.:)

Hans


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Inode persistence generally - was: Re: persistent labelling on afs, jfs, xfs?

[forrest whitcher]

<reiser@namesys.com> Hans Reiser did inscribe thusly:

>>We currently have unique and persistent inode numbers (at least until we 
>>someday write a repacker that will optimize key assignments for better 
>>layout), but you can't use them for finding files that are not in the 
>>cache.  To find such files requires a key.
>>
>>Hans
>>

Off-list I inqured:
fw>
fw> When a repacker is implemented, can your project allow persistent inode 
fw> numbers be kept as a configure - option?
fw>

And recieved in reply

Hans> Probably a good idea.  Ok, will do.

I will check in with the JFS list and inquire about maintaining
persistence of Inodes in future versions

What about XFS? I believe xfs Inodes are persistent, does anyone here have 
certain knowlege either way?

On Mon, 17 Dec 2001 07:29:44 -0500 (EST)
Stephen Smalley <sds@tislabs.com> Stephen Smalley did inscribe thusly:

> SELinux uses the inode number as an identifier for the file in the
> persistent label mapping in each filesystem.   So it doesn't find files
> based on the inode number, but it needs each file in a filesystem to have
> a unique and persistent inode number.  It sounds like reiserfs does
> currently provide this property.
> 

And (separate email):

> that are known to have persistent inodes.  See the superblock_precondition
> function in the hooks.c file.  You can patch it to recognize additional
> filesystem types if you wish.  However, note that for networked
> or distributed filesystems, this isn't safe, since there is no mechanism
> for coordinating updates to the mapping among the clients.
> 

I patched to try jfs, simple enough, seems to work.

The SELinux builds for kernel versions 2.4.12, 2.4.16 respectively 
maintain PSID's for:

.12   (ext2, ufs, sysv, v7, reiserfs)
.16   (ext2, ext3, reiserfs)

I think all of the above as well as (jfs, xfs) are probably 'safe'
(why were (ufs, sysv, v7) removed from the code (hooks.c) between
these two versions?)

However, pondering this brought me to wonder: do these various 
filesystems provide alternate ways of changing the Inode# - file
mapping in ways that could circumvent the AVC, or the LSM hooks
generally?

I looked through my LSM mail and didn't find that this has been
discussed there (tho I've far less time to apply to staying current
with LSM generally)

I assume that the interface is 

<kernel> -> <vfs> -> <(ext[23], rieserfs, xfs, jfs ...)>

The journalling filesystems must have added calls for manipulating
the logs at the very least. Could these functions be mis-used?

A more prosaic concern: 

Can we depend on the log check & replay functions and the fs-specific 
backup/restore to maintain inode:file persistence?


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs? - also read-only media???

[forrest whitcher]

On Fri, 14 Dec 2001 16:39:27 -0500 (EST)
Stephen Smalley <sds@tislabs.com> Stephen Smalley did inscribe thusly:


> function in the hooks.c file.  You can patch it to recognize additional
> filesystem types if you wish.  However, note that for networked
> or distributed filesystems, this isn't safe, since there is no mechanism
> for coordinating updates to the mapping among the clients.
> 

Yes, I understood this, however I can think of a few methods or conventions
which could be used to handle this:

1. ensure that all 'secured' clients use the same policy / psid definitions
to begin.

2. in a 'client-read-only' environment (a common use of AFS) write static 
PSID's into the AFS filesystem, to allow type enforcement in that space.


In a general read-write distributed environment If (1) above is established,
then I think the outstanding problem is what happens if a client *changes*
the PSID, invalidating the SID's of other clients.

I can think of 2 ways of handling this: 

The first would be to enforce a policy that prohibits *changes* of SID / 
context to objects in the distributed filesystem.

The second (far more involved) would be to use the AFS client-callback
to syncronize dynamic changes to persistent data files. Clearly this would
be a large project, requiring mods to (at minimum) afsd and the client
module; and on the server side, the fileserver, and possibly volserver,
volume location server.

AFS would present some other challenges, psid data would probably not
be best stored in the /afs directory, as that is usually RO.

AFS provides persistent and consistent inodes to clients in at
least the standard operation, I believe that this remains true
even for volumes moved dynamically between fileservers and for
backup volumes.



In poking about this and journalling filesystems I observed the following

SELinux (or the 'setfiles program) will dynamically map SID's to an r/w 
filesystem which is not recognized by hooks.c

A filesystem mounted r/o will will read ...security and report
file contexts as they were written when the filesystem was mounted
r/w.

I haven't tried to create this, however it looks like an iso9660
CDROM should be able to transport PSID-labelled data between 
SELinux systems. Is this correct?

Would it make sense to add logic to SELinux (or LSM) to look use a
digital signature on security label data (...security/*) when
accessing readonly optical data? 

I think this would provide for a degree of trust in distributing 
optical medea between SEL systems  and an appropriate assurance for 
maintaining type-enforcement on same. An obvious candidate would be 
system file signatures generated by Tripwire or similar integrity 
checking systems.

forrest


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Inode persistence generally - was: Re: persistent labelling on afs, jfs, xfs?

[Stephen Smalley]

On Mon, 17 Dec 2001, forrest whitcher wrote:

> fw> When a repacker is implemented, can your project allow persistent inode
> fw> numbers be kept as a configure - option?

Ultimately, if reiserfs supports extended attributes, then we can retarget
SELinux to use that support for binding security contexts to files rather
than the persistent label mapping when using reiserfs.  So at that point,
we would no longer care whether it keeps persistent inode numbers.

> The SELinux builds for kernel versions 2.4.12, 2.4.16 respectively
> maintain PSID's for:
>
> .12   (ext2, ufs, sysv, v7, reiserfs)
> .16   (ext2, ext3, reiserfs)
>
> I think all of the above as well as (jfs, xfs) are probably 'safe'
> (why were (ufs, sysv, v7) removed from the code (hooks.c) between
> these two versions?)

We hadn't actually tested with those filesystem types, so I removed them
to be safe.  I left reiserfs since I knew that there was specific
interest in it, even though we have only tested ext2 and ext3 ourselves.
Also, if I recall correctly, excluding experimental options, the kernel
only provides read-only access for ufs, sysv, and v7, so you can't really
maintain a persistent label mapping anyway for those types.

> The journalling filesystems must have added calls for manipulating
> the logs at the very least. Could these functions be mis-used?

Possibly.  However, if the filesystem uses the existing capable() and/or
permission() functions to perform access control for new operations, then
there will be a corresponding SELinux permission check, since LSM inserts
hooks into these functions.  But it may be desirable to define new SELinux
permissions that are more specific to these operations.

> Can we depend on the log check & replay functions and the fs-specific
> backup/restore to maintain inode:file persistence?

Probably not.  As far as backup/restore goes, there are two options:
1) You can always run setfiles on the file_contexts configuration after
restoring a filesystem to reset the file security contexts to a known
state.  But this requires you to periodically update file_contexts, and
doesn't capture dynamic changes to file labels.  You could use the
modified find program to periodically snapshot your file security contexts
and regenerate a file_contexts file based on it if you are concerned about
such dynamic changes.

2) You can use the modified tar program to save and restore file security
contexts with the corresponding files.  This doesn't depend on the inode
number at all.  It would be nice to have similar modified versions of
other typical backup/restore programs.

Long term, if support for extended attributes becomes mainstream, SELinux
could be retargeted to use it.  At that point, the modified utilities for
extended attributes could be used for this purpose.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: persistent labelling on afs, jfs, xfs? - also read-only media???

[Stephen Smalley]

On Mon, 17 Dec 2001, forrest whitcher wrote:

> Yes, I understood this, however I can think of a few methods or conventions
> which could be used to handle this:
>
> 1. ensure that all 'secured' clients use the same policy / psid definitions
> to begin.

PSIDs are dynamically allocated on a per-filesystem basis.  The
initial run of 'setfiles' allocates an initial set of PSIDs as needed by
the contexts in the file_contexts configuration, but subsequent file
creations while running SELinux will require the dynamic allocation of new
PSIDs for other security contexts.  If you do a list_sids on a running
SELinux kernel, you'll see far more file security contexts than are
present in the file_contexts configuration.

> 2. in a 'client-read-only' environment (a common use of AFS) write static
> PSID's into the AFS filesystem, to allow type enforcement in that space.

If you are only providing the clients with read-only access, then this is
fine.

> In a general read-write distributed environment If (1) above is established,
> then I think the outstanding problem is what happens if a client *changes*
> the PSID, invalidating the SID's of other clients.

This doesn't deal with the need to synchronize the allocation of new PSIDs
for new files (when no existing SID exists for the desired security
context).  This involves synchronizing updates both to the on-disk mapping
files and the in-memory data structures.

> I haven't tried to create this, however it looks like an iso9660
> CDROM should be able to transport PSID-labelled data between
> SELinux systems. Is this correct?

Possibly.  We haven't tried it.

> Would it make sense to add logic to SELinux (or LSM) to look use a
> digital signature on security label data (...security/*) when
> accessing readonly optical data?

Yes, this would be useful, but it isn't a priority for us right now.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Inode persistence generally - was: Re: persistent labelling on afs, jfs, xfs?

[Russell Coker]

On Mon, 17 Dec 2001 17:39, forrest whitcher wrote:
> A more prosaic concern:
>
> Can we depend on the log check & replay functions and the fs-specific
> backup/restore to maintain inode:file persistence?

Log check and reply merely guarantee the results that would be usual anyway 
(IE Inodes don't change etc), so they should be fine.

As for backup and restore, it'll work for dump/restore but not for tar/cpio.  
There is no dump for ReiserFS...

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.