Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: persistent labelling on afs, jfs, xfs? Date: Fri, 14 Dec 2001 16:09:28 -0500
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.
> I have problems with starting OpenAFS when the AFS cache is on a 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 midoctober 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: persistent labelling on afs, jfs, xfs? Date: Fri, 14 Dec 2001 16:39:27 -0500 (EST)
On Fri, 14 Dec 2001, forrest whitcher wrote:
> It seems that SELinux happily creates fs labels on reiserfs, 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 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.From: forrest whitcher <fw_at_fwsystems.com> subject: Re: persistent labelling on afs, jfs, xfs? - also read-only media??? Date: Mon, 17 Dec 2001 12:52:09 -0500
> function in the hooks.c file. You can patch it to recognize additional Yes, I understood this, however I can think of a few methods or conventions which could be used to handle this:
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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: persistent labelling on afs, jfs, xfs? - also read-only media??? Date: Mon, 17 Dec 2001 15:42:11 -0500 (EST)
On Mon, 17 Dec 2001, forrest whitcher wrote:
> Yes, I understood this, however I can think of a few methods or conventions 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 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, 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 Possibly. We haven't tried it.
> Would it make sense to add logic to SELinux (or LSM) to look use a 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: persistent labelling on afs, jfs, xfs? Date: Fri, 14 Dec 2001 16:53:49 -0500 (EST)
On Fri, 14 Dec 2001, forrest whitcher wrote:
> This is Reiserfs related. The problem is that Reiserfs breaks the 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.From: Hans Reiser <reiser_at_namesys.com> subject: Re: persistent labelling on afs, jfs, xfs? Date: Sat, 15 Dec 2001 17:57:09 +0300
>On Fri, 14 Dec 2001, forrest whitcher wrote: 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: persistent labelling on afs, jfs, xfs? Date: Mon, 17 Dec 2001 07:29:44 -0500 (EST)
On Sat, 15 Dec 2001, Hans Reiser wrote:
> We currently have unique and persistent inode numbers (at least until we 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.From: Hans Reiser <reiser_at_namesys.com> subject: Re: persistent labelling on afs, jfs, xfs? Date: Mon, 17 Dec 2001 17:34:33 +0300
>On Sat, 15 Dec 2001, Hans Reiser wrote: 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.From: forrest whitcher <fw_at_fwsystems.com> subject: Inode persistence generally - was: Re: persistent labelling on afs, jfs, xfs? Date: Mon, 17 Dec 2001 11:39:03 -0500
<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 And (separate email):
> that are known to have persistent inodes. See the superblock_precondition 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)
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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: Inode persistence generally - was: Re: persistent labelling on afs, jfs, xfs? Date: Mon, 17 Dec 2001 14:54:46 -0500 (EST)
On Mon, 17 Dec 2001, forrest whitcher wrote:
> fw> When a repacker is implemented, can your project allow persistent inode 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 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 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 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: Inode persistence generally - was: Re: persistent labelling on afs, jfs, xfs? Date: Mon, 17 Dec 2001 23:32:06 +0100
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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |