FC2 and FC1 and common home

[Shahms King]

> 
> > And, more importantly, it lets me share data between my FC1 install
> > and FC2 install as an ordinary user ;-P
> 
> I'm assuming the problem here is that you write the data from both,
> potentially losing xattrs?
> 

Mostly, yes.  However, my biggest issue is a lack of Fedora-specific
documentation.  The FAQ presents some information, and the links from
that page provide a lot generic SELinux information, but I have been
unable to find any kind of documentation for things like the mount
options you mentioned.  Those are vitally important for systems
administrators who want to get anything remotely resembling NFS mounted
home directories actually working.

Obviously, the Fedora policy is a work in progress, but, beyond the
policy sources themselves, there is no places to look for information on
what roles, identities, and domains have been defined and why.

In furtherance of smoothing out the current bumps in SELinux
integration, I have a list of questions/complaints about the current
policy and SELinux in general that may need to be addressed before
widespread rollout is reasonable.

1) Unlabeled files in an xattr-capable filesystem.
   -- Yes, this is a corner case, but will have to be dealt with,
especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. 
Most people don't want to reformat their home directories ;-P (isn't
that the point of an upgrade?).  Having anaconda 'make relabel' on
unformatted, mounted partitions is probably reasonable for this specific
case, but not all.  Another potential problem is read-only media
formatted with an xattr-capable filesystem.  Jaz drives and Zip disks
may very well be ext3 formatted but physically marked "read-only".  Or
removable media I want to use with an FC2 box at home and an FC1 box at
work . . . the possibilities are nearly endless.

2) Mislabeled files.
   -- Not that likely?  Removable devices.  Say I have an ext3 formatted
USB Key that gets used from my SELinux Debian install at home and the
SELinux Fedora at work.  Odds are good that these systems will want to
label files differently.  Running "make relabel" on an inserted
filesystem is NOT a viable option.

3) Unlabeled files in an xattr-incapable filesystem.
   -- Currently handled by "genfs_contexts" I believe, probably the most
well understood of the above examples.

Removable media may suffer from any combination of the above problems
and while they can be resolved on a case-by-case basis by an
administrator with mount options, that's unreasonable for an end user
who wants to plug in his USB Key and have it "just work".  It is also
possible to simply say "all removable storage, regardless of existing
labels has the context: system_u:system_r:removable_media_t" or
something...

4) NFS directories and executable files.  That's a policy decision, and
probably a tricky one to get right.  In general, it seems there are a
lot of areas in which the NFS:SElinux interface is difficult.

5) Third-party daemons.  Looking at the current policy, a lot of
services have their own domains, and for good reason.  However, in order
to do this, every single Fedora service has to have it's domain
information added to the policy source in a number of places.  And that
information has to be present regardless of whether or not the service
is actually installed.  Third-party daemons now must patch multiple
files in the policy sources, compile and load the new policy, or just
live with whatever domain options they are given (and live with the fact
that they have only slightly more security than the simple
user-group-other model).

6) NIS/LDAP user information.  If giving all users the user_u identity
and just living with that is acceptable, that's one thing, but if the
"standard practice" is expected to be adding every system user into
users.te and recompiling/reloading the policy, it's more than simply
impractical.


I'm sure most of these are already being considered and worked on, but
from where things stand currently, the above problems prevent reasonable
deployment of FC2 in a number of different, but common, scenarios.
-- 
Shahms King <shahms at shahms.com>