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