(Illustration by Gaich Muramatsu)
On Mon, Mar 26, 2007 at 02:00:19PM -0400, Chris PeBenito wrote: > On Mon, 2007-03-26 at 11:31 -0400, Jan Harkes wrote: > > On Sun, Mar 25, 2007 at 09:08:00PM -0400, Chris PeBenito wrote: > > > Does coda support extended attributes? In particular I'd like to use > > > coda with SELinux systems, which uses the extended attributes (security > > > namespace) to store its labels. I did some googling, but I only found a > > > thread from 1997 asking pretty much the same question, so my guess would > > > be no. > > > > Extended attributes are not supported, and most likely will never be > > supported in Coda. > > > > There is no place in the existing meta-data structure for such > > information, it would only be useful for systems running SELinux. > > Extended attributes are not limited to use by SELinux (or security in > general). In fact Linux supported them before SELinux began using them. According to the first announcement I could find on linux-fsdevel, one of the main arguments to include extended attributes was to support SELinux (or 'trusted OS extensions'), | Date: Sun, 22 Oct 2000 16:23:53 +0200 (CEST) | From: Andreas Gruenbacher <ag_at_bestbits.at> | To: linux-fsdevel_at_vger.kernel.org | Subject: [PROPOSAL] Extended attributes for Posix security extensions ... | WHY DO WE NEED THAT? | | Various recent and not-so-recent OS developments require storing | additional pieces of information with files and directories. A prominent | example are trusted OS extensions, including Access Control Lists, | Capabilities and Mandatory Access Control. > > unclear what a non SELinux system should do if it encounters an extended > > attribute. I'm not even sure if it is appropriate, since such security > > labels define a local policy. > > I don't agree with this last point. If security was local to a machine, > there would never be anything like domains in Windows. SELinux is > already building up infrastructure for network policies in the same > administrative domain, and also researching policies between > administrative domains. One significant design decision in Coda is that clients are considered untrusted and all significant security decisions are enforced by the servers. This has guided design since before the introduction of realms and has become even more important since. As you may see from recent discussions on the mailing list, there is some discussion whether we should reduce some of the paranoia checks on the client, based on the idea that if a server gave us a file, we clearly had access and as such should not restrict such access based on token expiry or connectivity changes unless we received an explicit revokation from the server. The same sort of count for write permission, since the server is the ultimate enforcer a client may allow updates from unpriviledged users, since they won't propagate to the server (this second part is somewhat more contentious since it would require per-user isolation, which doesn't fit well in the UNIX model of file sharing semantics. Another reason is possibly because I view Coda's usage model very differently from a local disk, or NFS, SMB/CIFS network file system. In my mind I mostly compare Coda with a portable USB storage device with a VFAT file system. It carries all my personal files, and possibly even some of my executable environment, and I can 'plug' it into any machine that happens to have an available USB port (or installed Coda client), with no additional configuration on the machine itself. Any computer with a Coda client could be considered, similar to having a machine with enabled USB ports, anyone who walks up to the machine could potentially access any file they have stored on a (possibly not locally trusted) location. Now I see two main uses for SELinux, I am by no means an SELinux expert so I may be wrong, - Elevating permissions or process capabilities, this is something you really never want to support for any binary that may possibly be coming from an untrusted source. - Restricting access, this is traditionally enforced by the Coda servers and any additional restrictions that would only be enforced by the client are suspect if there may be any clients that do not adhere to the additional restrictions. And as I mentioned earlier, > > There is no place in the existing meta-data structure for such > > information, Which pretty much means that implementing anything like this would better be really useful, since it would be incompatible and as such quite painful for anyone who needs to upgrade their existing installations. There is a good reason why extended attributes are not implemented for a majority of supported filesystems in Linux. And it isn't because nobody uses vfat, isofs, udf, jfs, afs, or smbfs. And there are even a couple of commonly used Linux specific filesystems like sysfs, devpts, ramfs, and cramfs. JanReceived on 2007-03-26 22:38:40