FC2 and FC1 and common home

[Colin Walters]

On Mon, 2004-04-05 at 12:57, Shahms King wrote:

> Mostly, yes.  However, my biggest issue is a lack of Fedora-specific
> documentation.  

I agree with you.  The issue is that the Fedora policy is still changing
a lot.  So documenting things is difficult.

> 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. 

Yeah.  We do need an entry in the man page.  I submitted a bug report.

> 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.

The documentation for the roles is important.  I don't think at the
moment we have plans to have any roles other than user_r, staff_r and
sysadm_r.  You can think of user_r as the normal "Unix account"
privileges.  staff_r should be used as the everyday account role for
users who can become sysadm_r.

As for domains: most (althought certainly not all) of them are generally
self-documenting, I think.  

> 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.  

Yeah.  Jeremy?  What do you think?  Maybe each previously-formatted
filesystem could have a checkbox for whether it should be relabeled with
security contexts.  Alternatively we could just do it - older ext{2,3}
should still be able to read it.

> Another potential problem is read-only media
> formatted with an xattr-capable filesystem.

This is a pretty uncommon case though, and if they're not labeled then
it just falls under the "unlabeled media" case.

> 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.  

Generally you can't expect this to work unless you make sure that the
policies on the systems match up, I don't see a way around it.

> 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 depends on the end user of course.   Maybe we could make things
slightly simpler with a mount-unsecured command that passes
context=system_u:object_r:full_access_t or something that any userdomain
can do anything to.  Or even an "unsecured" option that you could use in
/etc/fstab that would mount with the context in
/etc/security/default_unsecured_context so you wouldn't have to remember
the whole system_u:object_r:full_access_t context.

The whole user-level (non-uid 0) mounting issue is another thing.  

> 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.

Yes :)

> 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).

There are a few solutions to this.  One I've been thinking of is to have
an unlimited_t type (and corresponding unlimited_exec_t).  Then when you
install a third-party daemon, the system administrator could just run:

chcon -t unlimited_exec_t /path/to/daemon

As its name implies, unlimited_t would have all permissions.  Then you
could later create a policy and secure the daemon.  Or maybe we should
call it unsecured_t.

> 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.

Having all users be user_u and just relying on DAC should be sufficient
for most sites.  But I don't see why having a script to add users to
users.te would be so 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.

We're going to try to make it workable for as many of those before the
release as possible :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040406/0bc878d3/attachment.sig>