> > > 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@xxxxxxxxxx>
