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

[forrest whitcher <fw@fwsystems.com>]

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.