Re: [PATCH] refpolicy: experimental X policy -v2

[Eamon Walsh <ewalsh@tycho.nsa.gov>]

Christopher J. PeBenito wrote:
> On Wed, 2007-03-21 at 15:58 -0400, Eamon Walsh wrote:
>> Look at the example of the /dev/mem access denial.  This issue was 
>> reported to me even though it's an X server issue, not an X application 
>> issue.  If I were in charge of managing X application policy on some 
>> installation, I wouldn't want the kernel policy for the X server jumbled 
>> in with it.
>>
>> Just like how we're separating userspace object manager Flask 
>> definitions from the kernel ones.  In fact, I had originally created an 
>> entire separate directory "userspace" to use instead of services/. 
>> Reconsidered that, but still like the idea of separate modules.
> 
> I'm not saying that all the X object class rules are supposed to go in
> xserver, just the common ones.  Consider dbus, it has a template that
> other modules use for being client to a dbus, but the rules for sending
> dbus messages to other domains follows the same refpolicy conventions as
> kernel object classes, and thus are put in the relevant interface, eg
> hal_dbus_send().  I think the distinction between server and
> applications here is clear, and also I think its an analogue to the X
> server (there is a system dbus and also user dbuses).

OK, this makes sense.

>> Maybe gdm should restart the X server after the user has logged in, or 
>> the xserver should change its own context.  Both programs already have 
>> SELinux patches, adding this functionality could be done.
> 
> Yes, though I don't know the pros and cons, other than the latter option
> would be a dyntransition.

The fast user switching support in rawhide runs multiple xservers on 
virtual consoles; having them all be xdm_xserver_t is problematic.

Other ideas: have the display manager always running on the first 
virtual console, and launch the user servers on other consoles.  Or 
maybe we should go back to a text-based login only running X through startx.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.