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.

Jan