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.