--- Russell Coker <russell@xxxxxxxxxxxx> wrote: > On Friday 26 October 2007 03:27, Eamon Walsh <ewalsh@xxxxxxxxxxxxx> wrote: > > Is the X server part of the user's session or not? > > It probably would be best to have the X server run in a domain specific to > the > user. Even without the domain-type issues if we want to use labelled > networking to control access to X servers (let's not assume there is a strict > > 1:1 mapping of X servers to user sessions) in a MLS/MCS environment then > having an X server instance per user makes sense. > > > If it is, then it should always run as user_xserver_t, and the display > > managers should be "fixed" to label the X server with the user's context > > at login time. > > > > It if isn't, then it should always run in the same domain, and > > startx/xinit should be "fixed" to transition into this context. > > > > From my perspective I would favor the latter option for now since it's > > easier to write policy for. The user's individual windows can be > > labeled with a per-user type, maintaining separation. > > Why would either option be easier for policy writing? Getting both to work > (as has currently been done) is tricky - and we have had repeated breakage > along the way. For ease of policy writing we would support exactly one of > the options. > > I think that having the display manager start a new X server for each login > will give the best result. That certainly has advantages, including making the object reuse argument worlds simpler. In the Unix world it has been done both ways. Some instances treated the X server as a user application. Trix4.0.5epl, B1 evaluated, did it this way. Others made the X server a policy enforcing mechanism, and ran it as a system process. The important thing is that you have to decide if the X server is a policy enforcing entity or if it is not. Once you've made that choice it's pretty clear what you need to do. And who's going to get upset. Casey Schaufler casey@xxxxxxxxxxxxxxxx -- 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.
