What domain should the X server run in

What domain should the X server run in

[Eamon Walsh]

The X server runs as xdm_xserver_t if it is started from a display
manager.  It runs as user_xserver_t if it is started with startx.

Is the X server part of the user's session or not?

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.


-- 
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.

Re: What domain should the X server run in

[Christopher J. PeBenito]

On Thu, 2007-10-25 at 13:27 -0400, Eamon Walsh wrote:
> The X server runs as xdm_xserver_t if it is started from a display
> manager.  It runs as user_xserver_t if it is started with startx.
> 
> Is the X server part of the user's session or not?
> 
> 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.

If you're running from [gkx]dm, then the server is running before the
user has logged in, and not restarted or anything after the user logs
in, so it stays xdm_xserver_t.  Whereas from startx, the user runs it,
so its a straightforward type_transition to get user_xserver_t.  Unless
the server can be restarted somehow when a user logs in, it seems that
the only other option would be a dyntransition.

> 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.

I agree.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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.

Re: What domain should the X server run in

[Eamon Walsh]

Christopher J. PeBenito wrote:
> On Thu, 2007-10-25 at 13:27 -0400, Eamon Walsh wrote:
>> The X server runs as xdm_xserver_t if it is started from a display
>> manager.  It runs as user_xserver_t if it is started with startx.
>>
>> Is the X server part of the user's session or not?
>>
>> 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.
> 
> If you're running from [gkx]dm, then the server is running before the
> user has logged in, and not restarted or anything after the user logs
> in, so it stays xdm_xserver_t.  Whereas from startx, the user runs it,
> so its a straightforward type_transition to get user_xserver_t.  Unless
> the server can be restarted somehow when a user logs in, it seems that
> the only other option would be a dyntransition.

Among other solutions, a text-based or DirectFB-based display manager 
could be written that doesn't need X.  But I'm going with the single 
domain for now.

> 
>> 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.
> 
> I agree.
> 

I tried to go into the xserver module and rip out all the $1_xserver_t 
and xdm_xserver_t in favor of just "xserver_t".  But, I got bogged down 
rather quickly so I gave up on that for now.


-- 
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.

Re: What domain should the X server run in

[Russell Coker]

On Friday 26 October 2007 03:27, Eamon Walsh <ewalsh@tycho.nsa.gov> 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.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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.

Re: What domain should the X server run in

[Casey Schaufler]

--- Russell Coker <russell@coker.com.au> wrote:

> On Friday 26 October 2007 03:27, Eamon Walsh <ewalsh@tycho.nsa.gov> 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@schaufler-ca.com

--
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.

Re: What domain should the X server run in

[Russell Coker]

On Saturday 27 October 2007 01:43, Casey Schaufler <casey@schaufler-ca.com> 
wrote:
> > 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.

My recollection of playing with Trix some years ago is that it enforced policy 
in the X server (and for full functionality required turning off some GL 
features that would allow reading/writing outside window borders).

> 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.

You make a good point about the conceptual design being clearer if you either 
have the X server as a user application or as a policy enforcing system 
service.

But it seems to me that the best result is to have it running on behalf of a 
user but enforcing access control.  As an analogy consider a SETUID 
application such as /bin/passwd, it has policy (or rather enforces policy 
requested by the PAM configuration in a modern system) and is run by the user 
but transitions to a context that has greater privs.

We could of course have the password change operation on a Unix system be a 
system service that a user connects to (I'm sure that I'm not the only person 
to have written a CGI-BIN script to change passwords over https or something 
conceptually similar).  There is nothing preventing a Unix system being 
implemented with passwd, chfn, etc all talking over Unix domain sockets to a 
privileged server process that does the work (it would probably be easier to 
secure than the current way of doing things).

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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.

Re: What domain should the X server run in

[Casey Schaufler]

--- Russell Coker <russell@coker.com.au> wrote:

> On Saturday 27 October 2007 01:43, Casey Schaufler <casey@schaufler-ca.com> 
> wrote:
> > > 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.
> 
> My recollection of playing with Trix some years ago is that it enforced
> policy 
> in the X server (and for full functionality required turning off some GL 
> features that would allow reading/writing outside window borders).

That was (maybe still is) Trix6.5. As the corporate coffers dwindled
the features included in the evaluation deminished and the windowing
environment, although included in the product, was not included in
the LSPP evaluation.

> > 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.
> 
> You make a good point about the conceptual design being clearer if you either
> 
> have the X server as a user application or as a policy enforcing system 
> service.
> 
> But it seems to me that the best result is to have it running on behalf of a 
> user but enforcing access control.  As an analogy consider a SETUID 
> application such as /bin/passwd, it has policy (or rather enforces policy 
> requested by the PAM configuration in a modern system) and is run by the user
> 
> but transitions to a context that has greater privs.

If you are counting on the program to make access control decisions
the analysis/assurance/trust required is the same regardless of the
runtime attributes of the process. That includes the analysis of the
SELinux policy. Once you have elevated the program to Security Enforcing
status everything about it has to be called into question. Running it
with limited privilege via capabilities, userid, or policy attributes
can help with the analysis, but it can't remove the analysis.

> We could of course have the password change operation on a Unix system be a 
> system service that a user connects to (I'm sure that I'm not the only person
> 
> to have written a CGI-BIN script to change passwords over https or something 
> conceptually similar).  There is nothing preventing a Unix system being 
> implemented with passwd, chfn, etc all talking over Unix domain sockets to a 
> privileged server process that does the work (it would probably be easier to 
> secure than the current way of doing things).

Believe it or not, the first Unix system to be evaluated under the
Orange Book scheme did exactly that, back in 1987. Gould C2. It was
a commercial failure because it didn't look enough like "real" Unix.


Casey Schaufler
casey@schaufler-ca.com

--
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.