On Jul 30, 2008, at 7:13 AM, Stephen Smalley wrote:
On Tue, 2008-07-29 at 19:22 -0400, Eamon Walsh wrote:
Joe Nall wrote:
ls -Z /dev/mem
crw-r----- root kmem system_u:object_r:memory_device_t:SystemHigh /
dev/mem
In our MLS X policy, we are giving the X server
mls_file_read_all_levels and mls_file_write_all_levels to be able to
access the SystemHigh /dev/mem. I would prefer not to give X general
file MLS override if possible.
The X server is trusted to manage MLS objects internally, so a
general
file MLS override doesn't seem to be inappropriate in this case. But
see below.
Is there a way to assign MLS read up/write up on just one type (i.e.
allow X to read up only on memory_device_t)?
You could add an exception to the MLS constraints for the "file read"
ops. This exception would be an "or" clause taking the form (t1 ==
xserver_type) and (t2 == memory_device_t). Steve doesn't think these
kinds of specific exemption are very maintainable, and I would tend
to
agree.
Another option could be to split up the "file read" constraint,
taking
the chr_file (character device file type) out and adding a separate
override interface just for device files.
Is there a potential refactoring of the X server that eliminates the
need for /dev/mem access? Dan hinted at this at the developer summit
to allow X to run as the user.
My understanding of this is that the ability to run the X server as
an
unprivileged UID is a long-term goal but not something that's ready
just
yet.
Would it be better to mls_file_write_within_range(memory_device_t)
(i.e. make it a trusted object) and pull the MLS override out of
the X
policy?
I think this may work. You would be relying on type enforcement
alone
to protect /dev/mem in this case, if I understand correctly.
I think Joe must have meant mls_trusted_object(memory_device_t), as
that
is the interface for marking a file type as being unconstrained by MLS
restrictions, e.g. for /dev/null. That would allow any domain to
read/write /dev/mem without MLS restrictions (but still subject to TE
policy), which may not be what you want.
mls_file_write_within_range()
takes a domain as the argument, not a file type.
mls_file_write_within_range() or mls_file_write_to_clearance() are
possible options for making the X domains MLS trusted but bounded by
their range/clearance.
I was thinking about making /dev/mem SystemLow-SystemHigh and using
mls_file_write_within_range, but mls_trusted_object would match the
intent better.
I think I'll wait for the non-suid X server and revisit the policy
then. I do like the idea of separating the device file policy.
joe
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
