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 :)
Attachment:
signature.asc
Description: This is a digitally signed message part
