On Wed, 2008-07-30 at 09:23 -0400, Christopher J. PeBenito wrote: > On Wed, 2008-07-30 at 08:13 -0400, 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. > > I definitely think that we don't want mls_trusted_object(). /dev/mem > should certainly be system high and treated thusly, since by using the > device you gain access to all processes memory, regardless of level. > The TE policy will always be there for integrity sake, but I think we > should protect it in both an integrity and a confidentiality sense. You can certainly use TE for both confidentiality and integrity, and memory_device_t should be a highly restricted type regardless, but I agree with you - they should use one of the mls_trusted interfaces on the X server domains instead to mark it as being at least a partially trusted subject, as it has to be in order to do its job (at least when using X as an object manager). -- Stephen Smalley National Security Agency -- 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.
