FC2 and FC1 and common home

[Shahms King]

On Tue, 2004-04-06 at 13:43, Colin Walters wrote:
> On Mon, 2004-04-05 at 12:57, Shahms King wrote:

<snip documentation discussion>

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

Probably a checkbox that is only visible in "Advanced", on by default.

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

Good to know.

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

Yeah, user-level mounting is the only real issue, IMO.  Administrative
mounts should follow whatever options are passed at the discretion of
the administrator who will, presumably, know if security contexts will
need to be overridden, execution disabled, etc.

As a user, however, mounting should follow a system default policy as
stated above, overriding any context information on the device with that
policy.  For user-level mounts it might even be reasonable to override
user:group information with that of the mounting user.  Essentially,
user-level mounts are "private" to the user that mounted the device. 
I'm not familiar enough with SELinux to suggest a policy for
user-mounted (probably removable) devices, but it might make sense to
disallow execution for user_r, but allow user_r to change the
user_mount_exec_r or something . . .

On a related note, getting rid of 'updfstab' seems like a noble goal. 
/etc/fstab "should" be a static file.  The only reason it's currently
necessary is to allow user mounts.  I'd think an appropriate SELinux
policy would be a better route, but I'm not sure all the pieces that
would be necessary to implement it.

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

It's good to know that 'user_u' should be sufficient, because having a
LDAP -> user.te synchronization cron job is the only other way to do
it.  We've done that in the passed for other things (Samba didn't used
to support LDAP), and it's ugly and fragile.

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

Glad to hear it :-)

________________________________________________________________________
-- 
Shahms King <shahms at shahms.com>