From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 17 Dec 2001 12:52:09 -0500 From: forrest whitcher To: Stephen Smalley Cc: SELinux@tycho.nsa.gov Subject: Re: persistent labelling on afs, jfs, xfs? - also read-only media??? Message-Id: <20011217125209.508d4128.fw@fwsystems.com> In-Reply-To: References: <20011214160928.209536e6.fw@fwsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Fri, 14 Dec 2001 16:39:27 -0500 (EST) Stephen Smalley 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.