rbacsep: collapsing xserver

rbacsep: collapsing xserver

[Christopher J. PeBenito]

I've got to the point where I am collapsing the derived types in the
xserver module.  It would be nice to collapse all of the X server
domains into xserver_t, but we have xdm_xserver_t which has permissions
greater than user_xserver_t, staff_server_t, etc.  However, just about
everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
Thoughts on collapsing all of the xservers anyway?

-- 
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: rbacsep: collapsing xserver

[Joe Nall]

On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> I've got to the point where I am collapsing the derived types in the
> xserver module.  It would be nice to collapse all of the X server
> domains into xserver_t, but we have xdm_xserver_t which has permissions
> greater than user_xserver_t, staff_server_t, etc.  However, just about
> everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
> Thoughts on collapsing all of the xservers anyway?

Why is the way the xserver gets launched important once it is running?
Does that change when X is an object manager?

On a related topic, what is the type enforcement strategy for window managers?

joe

--
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: rbacsep: collapsing xserver

[Xavier Toth]

On Wed, May 28, 2008 at 10:16 AM, Joe Nall <joe@nall.com> wrote:
> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
>> I've got to the point where I am collapsing the derived types in the
>> xserver module.  It would be nice to collapse all of the X server
>> domains into xserver_t, but we have xdm_xserver_t which has permissions
>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>> everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
>> Thoughts on collapsing all of the xservers anyway?
>
> Why is the way the xserver gets launched important once it is running?
> Does that change when X is an object manager?
>
> On a related topic, what is the type enforcement strategy for window managers?
>
> joe
>
> --
> 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.
>

You mean display managers not window managers, right?

--
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: rbacsep: collapsing xserver

[Joe Nall]

On Wed, May 28, 2008 at 10:27 AM, Xavier Toth <txtoth@gmail.com> wrote:
> On Wed, May 28, 2008 at 10:16 AM, Joe Nall <joe@nall.com> wrote:
>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>>> I've got to the point where I am collapsing the derived types in the
>>> xserver module.  It would be nice to collapse all of the X server
>>> domains into xserver_t, but we have xdm_xserver_t which has permissions
>>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>>> everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
>>> Thoughts on collapsing all of the xservers anyway?
>>
>> Why is the way the xserver gets launched important once it is running?
>> Does that change when X is an object manager?
>>
>> On a related topic, what is the type enforcement strategy for window managers?
>>
>> joe
>>
>> --
>> 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.
>>
>
> You mean display managers not window managers, right?

No, window managers like Metacity.

joe

--
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: rbacsep: collapsing xserver

[Christopher J. PeBenito]

On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
> > I've got to the point where I am collapsing the derived types in the
> > xserver module.  It would be nice to collapse all of the X server
> > domains into xserver_t, but we have xdm_xserver_t which has permissions
> > greater than user_xserver_t, staff_server_t, etc.  However, just about
> > everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
> > Thoughts on collapsing all of the xservers anyway?
> 
> Why is the way the xserver gets launched important once it is running?

If you log into the console and run startx, your xserver is
user_xserver_t, staff_xserver_t, etc.  If you log in via a display
manager, your xserver is xdm_xserver_t, since the server is started by
xdm before a user logs in.  So you lose separation if you log in via
xdm.

There have been suggestions about either restarting the xserver or
dyntransitioning it to the correct context after logging in, but nothing
materialized on that.

> Does that change when X is an object manager?

No.

> On a related topic, what is the type enforcement strategy for window managers?

They currently run in the user's context.  The basic templates in the
policy should still allow for separations.  The policy for X objects is
still immature, so I'm definitely open to suggestions.

-- 
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: rbacsep: collapsing xserver

[Joe Nall]

On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>> > I've got to the point where I am collapsing the derived types in the
>> > xserver module.  It would be nice to collapse all of the X server
>> > domains into xserver_t, but we have xdm_xserver_t which has permissions
>> > greater than user_xserver_t, staff_server_t, etc.  However, just about
>> > everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
>> > Thoughts on collapsing all of the xservers anyway?
>>
>> Why is the way the xserver gets launched important once it is running?
>
> If you log into the console and run startx, your xserver is
> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
> manager, your xserver is xdm_xserver_t, since the server is started by
> xdm before a user logs in.  So you lose separation if you log in via
> xdm.

Understood.

> There have been suggestions about either restarting the xserver or
> dyntransitioning it to the correct context after logging in, but nothing
> materialized on that.
>
>> Does that change when X is an object manager?
>
> No.

Poorly worded question. _Should_ that change when X is a object manager?

What is the driver for the derived types? User preference files in
their home directory?

>
>> On a related topic, what is the type enforcement strategy for window managers?
>
> They currently run in the user's context.  The basic templates in the
> policy should still allow for separations.  The policy for X objects is
> still immature, so I'm definitely open to suggestions.

I did some brief experiments with the X server in MLS enforcing mode a
while back and it looked like a separate type would be required to
avoid giving the user silly levels of privilege. I'll try to get back
to those experiments next week.

Any opinions on spitting the display manager (gdm/xdm) policy out of
the xserver policy? The current xserver policy is quite a bit bigger
than apache and several times the average policy size (te + if).

joe


--
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: rbacsep: collapsing xserver

[Christopher J. PeBenito]

On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
> > On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
> >> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
> >> <cpebenito@tresys.com> wrote:
> >> > I've got to the point where I am collapsing the derived types in the
> >> > xserver module.  It would be nice to collapse all of the X server
> >> > domains into xserver_t, but we have xdm_xserver_t which has permissions
> >> > greater than user_xserver_t, staff_server_t, etc.  However, just about
> >> > everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
> >> > Thoughts on collapsing all of the xservers anyway?
> >>
> >> Why is the way the xserver gets launched important once it is running?
> >
> > If you log into the console and run startx, your xserver is
> > user_xserver_t, staff_xserver_t, etc.  If you log in via a display
> > manager, your xserver is xdm_xserver_t, since the server is started by
> > xdm before a user logs in.  So you lose separation if you log in via
> > xdm.
> 
> Understood.
> 
> > There have been suggestions about either restarting the xserver or
> > dyntransitioning it to the correct context after logging in, but nothing
> > materialized on that.
> >
> >> Does that change when X is an object manager?
> >
> > No.
> 
> Poorly worded question. _Should_ that change when X is a object manager?

We would certainly prefer that each role always has their derived type
xserver (or role is set on xserver, if rbacsep succeeds), regardless if
its an object manager or not.

> What is the driver for the derived types? User preference files in
> their home directory?
> 
> >
> >> On a related topic, what is the type enforcement strategy for window managers?
> >
> > They currently run in the user's context.  The basic templates in the
> > policy should still allow for separations.  The policy for X objects is
> > still immature, so I'm definitely open to suggestions.
> 
> I did some brief experiments with the X server in MLS enforcing mode a
> while back and it looked like a separate type would be required to
> avoid giving the user silly levels of privilege. I'll try to get back
> to those experiments next week.
>
> Any opinions on spitting the display manager (gdm/xdm) policy out of
> the xserver policy? The current xserver policy is quite a bit bigger
> than apache and several times the average policy size (te + if).

You can blame me for that.  The xdm policy used to be separate before
refpolicy, but it was so intertwined with the xserver policy that there
wasn't a sane way to write the policies separately and still keep the
refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
may be possible to separate xdm again.  If not, xdm will be put into a
tunable when we get real tunable support in the compiler.

-- 
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: rbacsep: collapsing xserver

[Joe Nall]

On Wed, May 28, 2008 at 1:16 PM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>> What is the driver for the derived types? User preference files in
>> their home directory?

I'm still trying to understand the need for the derived types. What
does the xserver need to do that is constrained by user role?

>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>> the xserver policy? The current xserver policy is quite a bit bigger
>> than apache and several times the average policy size (te + if).
>
> You can blame me for that.  The xdm policy used to be separate before
> refpolicy, but it was so intertwined with the xserver policy that there
> wasn't a sane way to write the policies separately and still keep the
> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
> may be possible to separate xdm again.  If not, xdm will be put into a
> tunable when we get real tunable support in the compiler.

What drives the complexity/policy commingling? Or, what would have to
change to allow the policies to be separated and simplified?

joe

--
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: rbacsep: collapsing xserver

[Daniel J Walsh]

Joe Nall wrote:
> On Wed, May 28, 2008 at 1:16 PM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>> What is the driver for the derived types? User preference files in
>>> their home directory?
> 
> I'm still trying to understand the need for the derived types. What
> does the xserver need to do that is constrained by user role?
> 
>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>> the xserver policy? The current xserver policy is quite a bit bigger
>>> than apache and several times the average policy size (te + if).
>> You can blame me for that.  The xdm policy used to be separate before
>> refpolicy, but it was so intertwined with the xserver policy that there
>> wasn't a sane way to write the policies separately and still keep the
>> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
>> may be possible to separate xdm again.  If not, xdm will be put into a
>> tunable when we get real tunable support in the compiler.
> 
> What drives the complexity/policy commingling? Or, what would have to
> change to allow the policies to be separated and simplified?
> 
> joe
> 
> --
> 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.
I say collapse it and do not allow staff_t or user_t to execute startx.
 This is what fedora does.  Allowing a confined domain to start
something as complex as X windows is just a big headache.  And would
probably allow lots of escalations and lots of bugs.

xdm (gdm.kdm) is starting to run lots of software before user login, so
we need to do a better job of isolating this from the xserver.

The current XAce software is far to complex to do anything usefull in my
opinion.  We have way too many types and transitions.  We need to
simplify down to a lot less types.

--
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: rbacsep: collapsing xserver

[Xavier Toth]

On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Joe Nall wrote:
>> On Wed, May 28, 2008 at 1:16 PM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>>> What is the driver for the derived types? User preference files in
>>>> their home directory?
>>
>> I'm still trying to understand the need for the derived types. What
>> does the xserver need to do that is constrained by user role?
>>
>>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>>> the xserver policy? The current xserver policy is quite a bit bigger
>>>> than apache and several times the average policy size (te + if).
>>> You can blame me for that.  The xdm policy used to be separate before
>>> refpolicy, but it was so intertwined with the xserver policy that there
>>> wasn't a sane way to write the policies separately and still keep the
>>> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
>>> may be possible to separate xdm again.  If not, xdm will be put into a
>>> tunable when we get real tunable support in the compiler.
>>
>> What drives the complexity/policy commingling? Or, what would have to
>> change to allow the policies to be separated and simplified?
>>
>> joe
>>
>> --
>> 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.
> I say collapse it and do not allow staff_t or user_t to execute startx.
>  This is what fedora does.  Allowing a confined domain to start
> something as complex as X windows is just a big headache.  And would
> probably allow lots of escalations and lots of bugs.
>
> xdm (gdm.kdm) is starting to run lots of software before user login, so
> we need to do a better job of isolating this from the xserver.
>
> The current XAce software is far to complex to do anything usefull in my
> opinion.  We have way too many types and transitions.  We need to
> simplify down to a lot less types.
>
> --
> 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.
>

Going back to Dan's concern about the complexity of the X SELinux
extension and the number of types and transitions I'd like to see some
discussion/resolution. Eamon what's your position on this topic?

--
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: rbacsep: collapsing xserver

[Christopher J. PeBenito]

On Fri, 2008-05-30 at 08:19 -0500, Xavier Toth wrote:
> On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > The current XAce software is far to complex to do anything usefull in my
> > opinion.  We have way too many types and transitions.  We need to
> > simplify down to a lot less types.
> 
> Going back to Dan's concern about the complexity of the X SELinux
> extension and the number of types and transitions I'd like to see some
> discussion/resolution. Eamon what's your position on this topic?

I don't want to speak for Eamon, but I suspect that he would defend the
current setup since he's the one that wrote the policy.  I just
restructured it to fit nicer in refpolicy and actually removed a few
types :)

My position is that its fine as is.  Simplifying it unconditionally
starts to make it less usable for people that actually want fine grained
controls on the desktop.  Making things simpler tends to be easy, since
it tends to be merging types or using attributes for blanket access,
like unconfined does.  The black magic voodoo that happens in the
xserver, that only a select few have previously known about, has only
recently been exposed via the SELinux controls.  I feel that it may be
premature to simplify the policy, since side effects probably aren't
well understood yet.  At least they aren't understood well by me yet.

-- 
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: rbacsep: collapsing xserver

[Joe Nall]

On Fri, May 30, 2008 at 8:47 AM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> On Fri, 2008-05-30 at 08:19 -0500, Xavier Toth wrote:
>> On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> > The current XAce software is far to complex to do anything usefull in my
>> > opinion.  We have way too many types and transitions.  We need to
>> > simplify down to a lot less types.
>>
>> Going back to Dan's concern about the complexity of the X SELinux
>> extension and the number of types and transitions I'd like to see some
>> discussion/resolution. Eamon what's your position on this topic?
>
> I don't want to speak for Eamon, but I suspect that he would defend the
> current setup since he's the one that wrote the policy.  I just
> restructured it to fit nicer in refpolicy and actually removed a few
> types :)
>
> My position is that its fine as is.  Simplifying it unconditionally
> starts to make it less usable for people that actually want fine grained
> controls on the desktop.  Making things simpler tends to be easy, since
> it tends to be merging types or using attributes for blanket access,
> like unconfined does.  The black magic voodoo that happens in the
> xserver, that only a select few have previously known about, has only
> recently been exposed via the SELinux controls.  I feel that it may be
> premature to simplify the policy, since side effects probably aren't
> well understood yet.  At least they aren't understood well by me yet.

I can relate to that :)

Voodoo note: Any post-login setuid magic will have to allow the
xserver object manager to continue to audit.

I chimed in on this thread because we need to get MLS X up and running
locally in enforcing mode. I wanted to make sure that we (Ted and I)
understood the issues involved as much as possible before changing any
policy.

joe

--
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: rbacsep: collapsing xserver

[Eamon Walsh]

Joe Nall wrote:
> On Fri, May 30, 2008 at 8:47 AM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
>   
>> On Fri, 2008-05-30 at 08:19 -0500, Xavier Toth wrote:
>>     
>>> On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>>>       
>>>> The current XAce software is far to complex to do anything usefull in my
>>>> opinion.  We have way too many types and transitions.  We need to
>>>> simplify down to a lot less types.
>>>>         
>>> Going back to Dan's concern about the complexity of the X SELinux
>>> extension and the number of types and transitions I'd like to see some
>>> discussion/resolution. Eamon what's your position on this topic?
>>>       
>> I don't want to speak for Eamon, but I suspect that he would defend the
>> current setup since he's the one that wrote the policy.  I just
>> restructured it to fit nicer in refpolicy and actually removed a few
>> types :)
>>
>> My position is that its fine as is.  Simplifying it unconditionally
>> starts to make it less usable for people that actually want fine grained
>> controls on the desktop.  Making things simpler tends to be easy, since
>> it tends to be merging types or using attributes for blanket access,
>> like unconfined does.  The black magic voodoo that happens in the
>> xserver, that only a select few have previously known about, has only
>> recently been exposed via the SELinux controls.  I feel that it may be
>> premature to simplify the policy, since side effects probably aren't
>> well understood yet.  At least they aren't understood well by me yet.
>>     

I never signed up to write "the SELinux policy" for X.  It is my 
responsibility to document my work so that others can write such 
policies, and I will do so.  See my earlier private message (pasted below).

X policy will be an area where one size doesn't fit all.  I'll try to 
address the concerns in the "current diff" mail.

>
> I can relate to that :)
>
> Voodoo note: Any post-login setuid magic will have to allow the
> xserver object manager to continue to audit.
>
>   

Changing the UID isn't all that interesting to me; it's changing the 
context that matters.  If SDTLOGIN or pam_selinux.so could be used to 
implement a setcon() solution, great.  If we could launch the server 
after the user logs in, even better.

> I chimed in on this thread because we need to get MLS X up and running
> locally in enforcing mode. I wanted to make sure that we (Ted and I)
> understood the issues involved as much as possible before changing any
> policy.
>   

The documentation links in the pasted message below are the best way to 
get started with understanding X.

---

I plan to get some documentation into shape for the upcoming X server 
release.  This will certainly include updated XACE hook documentation, 
as well as rudimentary one-liner class and permission documentation that 
can go in the table of classes and permissions I recall seeing somewhere 
(but can't find at the moment).  The only thing I have right now is a 
large spreadsheet of X protocol requests and the permissions required 
for each one.  I will do my best to make sure this knowledge gets put 
into a communicable form.

However, it is time for other people in this community besides myself to 
start figuring how X works.  The X Window System is not black magic; the 
core X protocol is described at [1] and many of the X extensions 
(additional calls that have been added over the years) are described at 
[2].  A great place to start would be the Xlib programming manual [3].  
Wikipedia also has pages on many of the popular extensions.  After that, 
the various conventions that have been established for using X: the 
ICCCM, which describes the cut & paste protocol and other aspects of how 
window managers work [4].  The NETWM standard, its successor [5].  The 
XSETTINGS selection protocol [6].  Finally, all of the GNOME and KDE 
conventions and non-conventions (which I do not understand, because I 
have not gotten that far) and the requirements of the various "core" 
desktop applications such as nautilus, gnome-panel, gnome-session, gdm, 
gnome-screensaver, gnome-power-manager, gnome-keyring, etc.

People just know how files, symbolic links, pipes, and sockets work, and 
they do not need Steve to explain this to them.   X should not be any 
different.


[1] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/XProtocol
[2] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/Xext
[3] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/X11
[4] http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/hardcopy/ICCCM
[5] http://freedesktop.org/wiki/Specifications/wm-spec?action=show&redirect=Standards%2Fwm-spec
[6] http://standards.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html


-- 
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: rbacsep: collapsing xserver

[Christopher J. PeBenito]

On Fri, 2008-05-30 at 19:10 -0400, Eamon Walsh wrote:
> Joe Nall wrote:
> > On Fri, May 30, 2008 at 8:47 AM, Christopher J. PeBenito
> > <cpebenito@tresys.com> wrote:
> >   
> >> On Fri, 2008-05-30 at 08:19 -0500, Xavier Toth wrote:
> >>     
> >>> On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >>>       
> >>>> The current XAce software is far to complex to do anything usefull in my
> >>>> opinion.  We have way too many types and transitions.  We need to
> >>>> simplify down to a lot less types.
> >>>>         
> >>> Going back to Dan's concern about the complexity of the X SELinux
> >>> extension and the number of types and transitions I'd like to see some
> >>> discussion/resolution. Eamon what's your position on this topic?
> >>>       
> >> I don't want to speak for Eamon, but I suspect that he would defend the
> >> current setup since he's the one that wrote the policy.  I just
> >> restructured it to fit nicer in refpolicy and actually removed a few
> >> types :)
> >>
> >> My position is that its fine as is.  Simplifying it unconditionally
> >> starts to make it less usable for people that actually want fine grained
> >> controls on the desktop.  Making things simpler tends to be easy, since
> >> it tends to be merging types or using attributes for blanket access,
> >> like unconfined does.  The black magic voodoo that happens in the
> >> xserver, that only a select few have previously known about, has only
> >> recently been exposed via the SELinux controls.  I feel that it may be
> >> premature to simplify the policy, since side effects probably aren't
> >> well understood yet.  At least they aren't understood well by me yet.
> >>     
> 
> I never signed up to write "the SELinux policy" for X.

I never claimed you did.  However, most of the rules on X objects in
refpolicy right now are a refinement of what you wrote.  Thats all that
I meant.  I know its up to me and other policy writers/contributors to
get this going.

> It is my responsibility to document my work so that others can write
> such policies, and I will do so.

-- 
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: rbacsep: collapsing xserver

[Christopher J. PeBenito]

On Wed, 2008-05-28 at 13:27 -0500, Joe Nall wrote:
> On Wed, May 28, 2008 at 1:16 PM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
> > On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
> >> What is the driver for the derived types? User preference files in
> >> their home directory?
> 
> I'm still trying to understand the need for the derived types. What
> does the xserver need to do that is constrained by user role?

Mainly it has to do with the associated files and domains, for the
xserver temp files, xauth, user specific fonts, etc.  If theres no
separation on the server itself, might be able to open up a window on
another role's xserver and send/receive info.  Obviously that would be
mitigated by an enforcing X server.

> >> Any opinions on spitting the display manager (gdm/xdm) policy out of
> >> the xserver policy? The current xserver policy is quite a bit bigger
> >> than apache and several times the average policy size (te + if).
> >
> > You can blame me for that.  The xdm policy used to be separate before
> > refpolicy, but it was so intertwined with the xserver policy that there
> > wasn't a sane way to write the policies separately and still keep the
> > refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
> > may be possible to separate xdm again.  If not, xdm will be put into a
> > tunable when we get real tunable support in the compiler.
> 
> What drives the complexity/policy commingling? Or, what would have to
> change to allow the policies to be separated and simplified?

Mainly the special rules that xdm_xserver_t requires.

I was also thinking that I could put those extra rules in a tunable.  So
if I collapse all of the xserver types, then people on that don't want
the extra rules can just turn them off and then log in at the console
and use startx.

-- 
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: rbacsep: collapsing xserver

[Eamon Walsh]

Christopher J. PeBenito wrote:
> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>   
>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>>     
>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>       
>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>> <cpebenito@tresys.com> wrote:
>>>>         
>>>>> I've got to the point where I am collapsing the derived types in the
>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>> domains into xserver_t, but we have xdm_xserver_t which has permissions
>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via xdm.
>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>           
>>>> Why is the way the xserver gets launched important once it is running?
>>>>         
>>> If you log into the console and run startx, your xserver is
>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>> manager, your xserver is xdm_xserver_t, since the server is started by
>>> xdm before a user logs in.  So you lose separation if you log in via
>>> xdm.
>>>       
>> Understood.
>>
>>     
>>> There have been suggestions about either restarting the xserver or
>>> dyntransitioning it to the correct context after logging in, but nothing
>>> materialized on that.
>>>
>>>       
>>>> Does that change when X is an object manager?
>>>>         
>>> No.
>>>       
>> Poorly worded question. _Should_ that change when X is a object manager?
>>     
>
> We would certainly prefer that each role always has their derived type
> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
> its an object manager or not.
>   

I have always disliked xdm_xserver_t and its associated policy 
shenanigans (what if someone creates a role named "xdm"?)

The problem has always been the display manager behavior described 
above.  However this can be solved in at least three ways: 1) Restart 
the X server after the user logs in.  2) Have the X server setcon itself 
to the new context.  3) Multi-user switching where xdm stays up all the 
time and users get new X servers on different consoles.

The easiest solution for me to work on is 2) because I don't have to 
touch the GDM code.  I'd like to see rbacsep succeed though.

>   
>> What is the driver for the derived types? User preference files in
>> their home directory?
>>     


There's some argument to be made that the X server is part of the user's 
session.  For example, in mulit-user switching there is more than one 
server running, one for each user.

If rbacsep succeeds then the derived types will go away regardless.

>>     
>>>> On a related topic, what is the type enforcement strategy for window managers?
>>>>         
>>> They currently run in the user's context.  The basic templates in the
>>> policy should still allow for separations.  The policy for X objects is
>>> still immature, so I'm definitely open to suggestions.
>>>       
>> I did some brief experiments with the X server in MLS enforcing mode a
>> while back and it looked like a separate type would be required to
>> avoid giving the user silly levels of privilege. I'll try to get back
>> to those experiments next week.
>>     

The window manager must have full access to all windows on the screens 
that it's managing.  In non-MLS this means at least full privileges on 
the role and probably for other roles too, if you're going to be popping 
up sysadm windows.  In MLS this means access across all levels, there's 
really no way around this.


>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>> the xserver policy? The current xserver policy is quite a bit bigger
>> than apache and several times the average policy size (te + if).
>>     
>
> You can blame me for that.  The xdm policy used to be separate before
> refpolicy, but it was so intertwined with the xserver policy that there
> wasn't a sane way to write the policies separately and still keep the
> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
> may be possible to separate xdm again.  If not, xdm will be put into a
> tunable when we get real tunable support in the compiler.
>   


-- 
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: rbacsep: collapsing xserver

[Xavier Toth]

On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Christopher J. PeBenito wrote:
>>
>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>
>>>
>>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>>> <cpebenito@tresys.com> wrote:
>>>
>>>>
>>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>>
>>>>>
>>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>>> <cpebenito@tresys.com> wrote:
>>>>>
>>>>>>
>>>>>> I've got to the point where I am collapsing the derived types in the
>>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>>> domains into xserver_t, but we have xdm_xserver_t which has
>>>>>> permissions
>>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via
>>>>>> xdm.
>>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>>
>>>>>
>>>>> Why is the way the xserver gets launched important once it is running?
>>>>>
>>>>
>>>> If you log into the console and run startx, your xserver is
>>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>>> manager, your xserver is xdm_xserver_t, since the server is started by
>>>> xdm before a user logs in.  So you lose separation if you log in via
>>>> xdm.
>>>>
>>>
>>> Understood.
>>>
>>>
>>>>
>>>> There have been suggestions about either restarting the xserver or
>>>> dyntransitioning it to the correct context after logging in, but nothing
>>>> materialized on that.
>>>>
>>>>
>>>>>
>>>>> Does that change when X is an object manager?
>>>>>
>>>>
>>>> No.
>>>>
>>>
>>> Poorly worded question. _Should_ that change when X is a object manager?
>>>
>>
>> We would certainly prefer that each role always has their derived type
>> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
>> its an object manager or not.
>>
>
> I have always disliked xdm_xserver_t and its associated policy shenanigans
> (what if someone creates a role named "xdm"?)
>
> The problem has always been the display manager behavior described above.
>  However this can be solved in at least three ways: 1) Restart the X server
> after the user logs in.  2) Have the X server setcon itself to the new
> context.  3) Multi-user switching where xdm stays up all the time and users
> get new X servers on different consoles.
>
> The easiest solution for me to work on is 2) because I don't have to touch
> the GDM code.  I'd like to see rbacsep succeed though.
>
>>
>>>
>>> What is the driver for the derived types? User preference files in
>>> their home directory?
>>>
>
>
> There's some argument to be made that the X server is part of the user's
> session.  For example, in mulit-user switching there is more than one server
> running, one for each user.
>
> If rbacsep succeeds then the derived types will go away regardless.
>
>>>
>>>>>
>>>>> On a related topic, what is the type enforcement strategy for window
>>>>> managers?
>>>>>
>>>>
>>>> They currently run in the user's context.  The basic templates in the
>>>> policy should still allow for separations.  The policy for X objects is
>>>> still immature, so I'm definitely open to suggestions.
>>>>
>>>
>>> I did some brief experiments with the X server in MLS enforcing mode a
>>> while back and it looked like a separate type would be required to
>>> avoid giving the user silly levels of privilege. I'll try to get back
>>> to those experiments next week.
>>>
>
> The window manager must have full access to all windows on the screens that
> it's managing.  In non-MLS this means at least full privileges on the role
> and probably for other roles too, if you're going to be popping up sysadm
> windows.  In MLS this means access across all levels, there's really no way
> around this.
>
>
>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>> the xserver policy? The current xserver policy is quite a bit bigger
>>> than apache and several times the average policy size (te + if).
>>>
>>
>> You can blame me for that.  The xdm policy used to be separate before
>> refpolicy, but it was so intertwined with the xserver policy that there
>> wasn't a sane way to write the policies separately and still keep the
>> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
>> may be possible to separate xdm again.  If not, xdm will be put into a
>> tunable when we get real tunable support in the compiler.
>>
>
>
> --
> 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.
>

>From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:

"On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
after user authentication to tell the X server to be restarted as the
user instead of as root for added security. When the user's session
exits, the GDM daemon will run the PostSession script as root."

Couldn't we utilize the same functionality on Fedora?


--
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: rbacsep: collapsing xserver

[Daniel J Walsh]

Xavier Toth wrote:
> On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>> Christopher J. PeBenito wrote:
>>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>>
>>>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>>>> <cpebenito@tresys.com> wrote:
>>>>
>>>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>>>
>>>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>
>>>>>>> I've got to the point where I am collapsing the derived types in the
>>>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>>>> domains into xserver_t, but we have xdm_xserver_t which has
>>>>>>> permissions
>>>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>>>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via
>>>>>>> xdm.
>>>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>>>
>>>>>> Why is the way the xserver gets launched important once it is running?
>>>>>>
>>>>> If you log into the console and run startx, your xserver is
>>>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>>>> manager, your xserver is xdm_xserver_t, since the server is started by
>>>>> xdm before a user logs in.  So you lose separation if you log in via
>>>>> xdm.
>>>>>
>>>> Understood.
>>>>
>>>>
>>>>> There have been suggestions about either restarting the xserver or
>>>>> dyntransitioning it to the correct context after logging in, but nothing
>>>>> materialized on that.
>>>>>
>>>>>
>>>>>> Does that change when X is an object manager?
>>>>>>
>>>>> No.
>>>>>
>>>> Poorly worded question. _Should_ that change when X is a object manager?
>>>>
>>> We would certainly prefer that each role always has their derived type
>>> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
>>> its an object manager or not.
>>>
>> I have always disliked xdm_xserver_t and its associated policy shenanigans
>> (what if someone creates a role named "xdm"?)
>>
>> The problem has always been the display manager behavior described above.
>>  However this can be solved in at least three ways: 1) Restart the X server
>> after the user logs in.  2) Have the X server setcon itself to the new
>> context.  3) Multi-user switching where xdm stays up all the time and users
>> get new X servers on different consoles.
>>
>> The easiest solution for me to work on is 2) because I don't have to touch
>> the GDM code.  I'd like to see rbacsep succeed though.
>>
>>>> What is the driver for the derived types? User preference files in
>>>> their home directory?
>>>>
>>
>> There's some argument to be made that the X server is part of the user's
>> session.  For example, in mulit-user switching there is more than one server
>> running, one for each user.
>>
>> If rbacsep succeeds then the derived types will go away regardless.
>>
>>>>>> On a related topic, what is the type enforcement strategy for window
>>>>>> managers?
>>>>>>
>>>>> They currently run in the user's context.  The basic templates in the
>>>>> policy should still allow for separations.  The policy for X objects is
>>>>> still immature, so I'm definitely open to suggestions.
>>>>>
>>>> I did some brief experiments with the X server in MLS enforcing mode a
>>>> while back and it looked like a separate type would be required to
>>>> avoid giving the user silly levels of privilege. I'll try to get back
>>>> to those experiments next week.
>>>>
>> The window manager must have full access to all windows on the screens that
>> it's managing.  In non-MLS this means at least full privileges on the role
>> and probably for other roles too, if you're going to be popping up sysadm
>> windows.  In MLS this means access across all levels, there's really no way
>> around this.
>>
>>
>>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>>> the xserver policy? The current xserver policy is quite a bit bigger
>>>> than apache and several times the average policy size (te + if).
>>>>
>>> You can blame me for that.  The xdm policy used to be separate before
>>> refpolicy, but it was so intertwined with the xserver policy that there
>>> wasn't a sane way to write the policies separately and still keep the
>>> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
>>> may be possible to separate xdm again.  If not, xdm will be put into a
>>> tunable when we get real tunable support in the compiler.
>>>
>>
>> --
>> 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.
>>
> 
> From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:
> 
> "On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
> after user authentication to tell the X server to be restarted as the
> user instead of as root for added security. When the user's session
> exits, the GDM daemon will run the PostSession script as root."
> 
> Couldn't we utilize the same functionality on Fedora?
> 
> 
> --
> 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.
Probably better asked on the Fedora List.

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

Fwd: rbacsep: collapsing xserver

[Xavier Toth]

---------- Forwarded message ----------
From: Xavier Toth <txtoth@gmail.com>
Date: Thu, May 29, 2008 at 3:02 PM
Subject: Re: rbacsep: collapsing xserver
To: Daniel J Walsh <dwalsh@redhat.com>


On Thu, May 29, 2008 at 2:50 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Xavier Toth wrote:
>> On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>>> Christopher J. PeBenito wrote:
>>>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>>>
>>>>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>>>>> <cpebenito@tresys.com> wrote:
>>>>>
>>>>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>>>>
>>>>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>>
>>>>>>>> I've got to the point where I am collapsing the derived types in the
>>>>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>>>>> domains into xserver_t, but we have xdm_xserver_t which has
>>>>>>>> permissions
>>>>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>>>>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via
>>>>>>>> xdm.
>>>>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>>>>
>>>>>>> Why is the way the xserver gets launched important once it is running?
>>>>>>>
>>>>>> If you log into the console and run startx, your xserver is
>>>>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>>>>> manager, your xserver is xdm_xserver_t, since the server is started by
>>>>>> xdm before a user logs in.  So you lose separation if you log in via
>>>>>> xdm.
>>>>>>
>>>>> Understood.
>>>>>
>>>>>
>>>>>> There have been suggestions about either restarting the xserver or
>>>>>> dyntransitioning it to the correct context after logging in, but nothing
>>>>>> materialized on that.
>>>>>>
>>>>>>
>>>>>>> Does that change when X is an object manager?
>>>>>>>
>>>>>> No.
>>>>>>
>>>>> Poorly worded question. _Should_ that change when X is a object manager?
>>>>>
>>>> We would certainly prefer that each role always has their derived type
>>>> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
>>>> its an object manager or not.
>>>>
>>> I have always disliked xdm_xserver_t and its associated policy shenanigans
>>> (what if someone creates a role named "xdm"?)
>>>
>>> The problem has always been the display manager behavior described above.
>>>  However this can be solved in at least three ways: 1) Restart the X server
>>> after the user logs in.  2) Have the X server setcon itself to the new
>>> context.  3) Multi-user switching where xdm stays up all the time and users
>>> get new X servers on different consoles.
>>>
>>> The easiest solution for me to work on is 2) because I don't have to touch
>>> the GDM code.  I'd like to see rbacsep succeed though.
>>>
>>>>> What is the driver for the derived types? User preference files in
>>>>> their home directory?
>>>>>
>>>
>>> There's some argument to be made that the X server is part of the user's
>>> session.  For example, in mulit-user switching there is more than one server
>>> running, one for each user.
>>>
>>> If rbacsep succeeds then the derived types will go away regardless.
>>>
>>>>>>> On a related topic, what is the type enforcement strategy for window
>>>>>>> managers?
>>>>>>>
>>>>>> They currently run in the user's context.  The basic templates in the
>>>>>> policy should still allow for separations.  The policy for X objects is
>>>>>> still immature, so I'm definitely open to suggestions.
>>>>>>
>>>>> I did some brief experiments with the X server in MLS enforcing mode a
>>>>> while back and it looked like a separate type would be required to
>>>>> avoid giving the user silly levels of privilege. I'll try to get back
>>>>> to those experiments next week.
>>>>>
>>> The window manager must have full access to all windows on the screens that
>>> it's managing.  In non-MLS this means at least full privileges on the role
>>> and probably for other roles too, if you're going to be popping up sysadm
>>> windows.  In MLS this means access across all levels, there's really no way
>>> around this.
>>>
>>>
>>>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>>>> the xserver policy? The current xserver policy is quite a bit bigger
>>>>> than apache and several times the average policy size (te + if).
>>>>>
>>>> You can blame me for that.  The xdm policy used to be separate before
>>>> refpolicy, but it was so intertwined with the xserver policy that there
>>>> wasn't a sane way to write the policies separately and still keep the
>>>> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
>>>> may be possible to separate xdm again.  If not, xdm will be put into a
>>>> tunable when we get real tunable support in the compiler.
>>>>
>>>
>>> --
>>> 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.
>>>
>>
>> From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:
>>
>> "On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
>> after user authentication to tell the X server to be restarted as the
>> user instead of as root for added security. When the user's session
>> exits, the GDM daemon will run the PostSession script as root."
>>
>> Couldn't we utilize the same functionality on Fedora?
>>
>>
>> --
>> 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.
> Probably better asked on the Fedora List.
>

I've posted to the xorg and gdm lists and can post to fedora too. How
about if you talk to redhat developers responsible for gdm and X.


--
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: rbacsep: collapsing xserver

[Eamon Walsh]

Daniel J Walsh wrote:
> Xavier Toth wrote:
>   
>> On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>>     
>>> Christopher J. PeBenito wrote:
>>>       
>>>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>>>
>>>>         
>>>>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>>>>> <cpebenito@tresys.com> wrote:
>>>>>
>>>>>           
>>>>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>>>>
>>>>>>             
>>>>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>>
>>>>>>>               
>>>>>>>> I've got to the point where I am collapsing the derived types in the
>>>>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>>>>> domains into xserver_t, but we have xdm_xserver_t which has
>>>>>>>> permissions
>>>>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just about
>>>>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via
>>>>>>>> xdm.
>>>>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>>>>
>>>>>>>>                 
>>>>>>> Why is the way the xserver gets launched important once it is running?
>>>>>>>
>>>>>>>               
>>>>>> If you log into the console and run startx, your xserver is
>>>>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>>>>> manager, your xserver is xdm_xserver_t, since the server is started by
>>>>>> xdm before a user logs in.  So you lose separation if you log in via
>>>>>> xdm.
>>>>>>
>>>>>>             
>>>>> Understood.
>>>>>
>>>>>
>>>>>           
>>>>>> There have been suggestions about either restarting the xserver or
>>>>>> dyntransitioning it to the correct context after logging in, but nothing
>>>>>> materialized on that.
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Does that change when X is an object manager?
>>>>>>>
>>>>>>>               
>>>>>> No.
>>>>>>
>>>>>>             
>>>>> Poorly worded question. _Should_ that change when X is a object manager?
>>>>>
>>>>>           
>>>> We would certainly prefer that each role always has their derived type
>>>> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
>>>> its an object manager or not.
>>>>
>>>>         
>>> I have always disliked xdm_xserver_t and its associated policy shenanigans
>>> (what if someone creates a role named "xdm"?)
>>>
>>> The problem has always been the display manager behavior described above.
>>>  However this can be solved in at least three ways: 1) Restart the X server
>>> after the user logs in.  2) Have the X server setcon itself to the new
>>> context.  3) Multi-user switching where xdm stays up all the time and users
>>> get new X servers on different consoles.
>>>
>>> The easiest solution for me to work on is 2) because I don't have to touch
>>> the GDM code.  I'd like to see rbacsep succeed though.
>>>
>>>       
>>>>> What is the driver for the derived types? User preference files in
>>>>> their home directory?
>>>>>
>>>>>           
>>> There's some argument to be made that the X server is part of the user's
>>> session.  For example, in mulit-user switching there is more than one server
>>> running, one for each user.
>>>
>>> If rbacsep succeeds then the derived types will go away regardless.
>>>
>>>       
>>>>>>> On a related topic, what is the type enforcement strategy for window
>>>>>>> managers?
>>>>>>>
>>>>>>>               
>>>>>> They currently run in the user's context.  The basic templates in the
>>>>>> policy should still allow for separations.  The policy for X objects is
>>>>>> still immature, so I'm definitely open to suggestions.
>>>>>>
>>>>>>             
>>>>> I did some brief experiments with the X server in MLS enforcing mode a
>>>>> while back and it looked like a separate type would be required to
>>>>> avoid giving the user silly levels of privilege. I'll try to get back
>>>>> to those experiments next week.
>>>>>
>>>>>           
>>> The window manager must have full access to all windows on the screens that
>>> it's managing.  In non-MLS this means at least full privileges on the role
>>> and probably for other roles too, if you're going to be popping up sysadm
>>> windows.  In MLS this means access across all levels, there's really no way
>>> around this.
>>>
>>>
>>>       
>>>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>>>> the xserver policy? The current xserver policy is quite a bit bigger
>>>>> than apache and several times the average policy size (te + if).
>>>>>
>>>>>           
>>>> You can blame me for that.  The xdm policy used to be separate before
>>>> refpolicy, but it was so intertwined with the xserver policy that there
>>>> wasn't a sane way to write the policies separately and still keep the
>>>> refpolicy encapsulation.  If we collapse all xservers into xserver_t, it
>>>> may be possible to separate xdm again.  If not, xdm will be put into a
>>>> tunable when we get real tunable support in the compiler.
>>>>
>>>>         
>>> --
>>> 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.
>>>
>>>       
>> From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:
>>
>> "On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
>> after user authentication to tell the X server to be restarted as the
>> user instead of as root for added security. When the user's session
>> exits, the GDM daemon will run the PostSession script as root."
>>
>> Couldn't we utilize the same functionality on Fedora?
>>     

I've got no problem with doing something like this.  I've already 
written support for communicating with the X server from pam_selinux.so 
to set up the user's device labels, so it could also tell the server to 
setcon itself.  That work has stalled because of dependency issues (pam 
depending on libxcb), getting PAM_XAUTH_DATA support into gdm, and 
waiting for the next release of libxcb.  But, I can pick up work on it 
once I finish the X Python stuff.

With regards to SDTLOGIN, it doesn't look like it restarts the server, 
only causes it to drop privileges; see 
http://osdir.com/ml/gnome.gdm.general/2007-10/msg00080.html dated Oct 
2007.  The current gdm upstream seems to have dropped support for it.  I 
did some grepping in the gdm source and couldn't find anything.  It's 
probably a temporary result of the gdm rewrite.


>>
>> --
>> 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.
>>     
> Probably better asked on the Fedora List.
>
>   

-- 
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: rbacsep: collapsing xserver

[Xavier Toth]

On Thu, May 29, 2008 at 8:04 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Daniel J Walsh wrote:
>>
>> Xavier Toth wrote:
>>
>>>
>>> On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov>
>>> wrote:
>>>
>>>>
>>>> Christopher J. PeBenito wrote:
>>>>
>>>>>
>>>>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've got to the point where I am collapsing the derived types in
>>>>>>>>> the
>>>>>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>>>>>> domains into xserver_t, but we have xdm_xserver_t which has
>>>>>>>>> permissions
>>>>>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just
>>>>>>>>> about
>>>>>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via
>>>>>>>>> xdm.
>>>>>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why is the way the xserver gets launched important once it is
>>>>>>>> running?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> If you log into the console and run startx, your xserver is
>>>>>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>>>>>> manager, your xserver is xdm_xserver_t, since the server is started
>>>>>>> by
>>>>>>> xdm before a user logs in.  So you lose separation if you log in via
>>>>>>> xdm.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Understood.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> There have been suggestions about either restarting the xserver or
>>>>>>> dyntransitioning it to the correct context after logging in, but
>>>>>>> nothing
>>>>>>> materialized on that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Does that change when X is an object manager?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Poorly worded question. _Should_ that change when X is a object
>>>>>> manager?
>>>>>>
>>>>>>
>>>>>
>>>>> We would certainly prefer that each role always has their derived type
>>>>> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
>>>>> its an object manager or not.
>>>>>
>>>>>
>>>>
>>>> I have always disliked xdm_xserver_t and its associated policy
>>>> shenanigans
>>>> (what if someone creates a role named "xdm"?)
>>>>
>>>> The problem has always been the display manager behavior described
>>>> above.
>>>>  However this can be solved in at least three ways: 1) Restart the X
>>>> server
>>>> after the user logs in.  2) Have the X server setcon itself to the new
>>>> context.  3) Multi-user switching where xdm stays up all the time and
>>>> users
>>>> get new X servers on different consoles.
>>>>
>>>> The easiest solution for me to work on is 2) because I don't have to
>>>> touch
>>>> the GDM code.  I'd like to see rbacsep succeed though.
>>>>
>>>>
>>>>>>
>>>>>> What is the driver for the derived types? User preference files in
>>>>>> their home directory?
>>>>>>
>>>>>>
>>>>
>>>> There's some argument to be made that the X server is part of the user's
>>>> session.  For example, in mulit-user switching there is more than one
>>>> server
>>>> running, one for each user.
>>>>
>>>> If rbacsep succeeds then the derived types will go away regardless.
>>>>
>>>>
>>>>>>>>
>>>>>>>> On a related topic, what is the type enforcement strategy for window
>>>>>>>> managers?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> They currently run in the user's context.  The basic templates in the
>>>>>>> policy should still allow for separations.  The policy for X objects
>>>>>>> is
>>>>>>> still immature, so I'm definitely open to suggestions.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I did some brief experiments with the X server in MLS enforcing mode a
>>>>>> while back and it looked like a separate type would be required to
>>>>>> avoid giving the user silly levels of privilege. I'll try to get back
>>>>>> to those experiments next week.
>>>>>>
>>>>>>
>>>>
>>>> The window manager must have full access to all windows on the screens
>>>> that
>>>> it's managing.  In non-MLS this means at least full privileges on the
>>>> role
>>>> and probably for other roles too, if you're going to be popping up
>>>> sysadm
>>>> windows.  In MLS this means access across all levels, there's really no
>>>> way
>>>> around this.
>>>>
>>>>
>>>>
>>>>>>
>>>>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>>>>> the xserver policy? The current xserver policy is quite a bit bigger
>>>>>> than apache and several times the average policy size (te + if).
>>>>>>
>>>>>>
>>>>>
>>>>> You can blame me for that.  The xdm policy used to be separate before
>>>>> refpolicy, but it was so intertwined with the xserver policy that there
>>>>> wasn't a sane way to write the policies separately and still keep the
>>>>> refpolicy encapsulation.  If we collapse all xservers into xserver_t,
>>>>> it
>>>>> may be possible to separate xdm again.  If not, xdm will be put into a
>>>>> tunable when we get real tunable support in the compiler.
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>>
>>>
>>> From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:
>>>
>>> "On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
>>> after user authentication to tell the X server to be restarted as the
>>> user instead of as root for added security. When the user's session
>>> exits, the GDM daemon will run the PostSession script as root."
>>>
>>> Couldn't we utilize the same functionality on Fedora?
>>>
>
> I've got no problem with doing something like this.  I've already written
> support for communicating with the X server from pam_selinux.so to set up
> the user's device labels, so it could also tell the server to setcon itself.
>  That work has stalled because of dependency issues (pam depending on
> libxcb), getting PAM_XAUTH_DATA support into gdm, and waiting for the next
> release of libxcb.  But, I can pick up work on it once I finish the X Python
> stuff.
>
> With regards to SDTLOGIN, it doesn't look like it restarts the server, only
> causes it to drop privileges; see
> http://osdir.com/ml/gnome.gdm.general/2007-10/msg00080.html dated Oct 2007.
>  The current gdm upstream seems to have dropped support for it.  I did some
> grepping in the gdm source and couldn't find anything.  It's probably a
> temporary result of the gdm rewrite.
>
>
>>>
>>> --
>>> 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.
>>>
>>
>> Probably better asked on the Fedora List.
>>
>>
>
> --
> Eamon Walsh <ewalsh@tycho.nsa.gov>
> National Security Agency
>
>

For those who don't subscribe to the gdm list:

Message: 5
Date: Thu, 29 May 2008 14:11:08 -0700
From: Alan Coopersmith <Alan.Coopersmith@Sun.COM>
Subject: Re: [gdm-list] STDLOGIN support
To: Brian Cameron <Brian.Cameron@Sun.COM>
Cc: Xavier Toth <txtoth@gmail.com>, gdm-list@gnome.org
Message-ID: <483F1BEC.4070406@sun.com>
Content-Type: text/plain; charset=ISO-8859-1

I just answered Xavier's followup question on the Xorg mailing list:
http://lists.freedesktop.org/archives/xorg/2008-May/035753.html

Note that it doesn't restart the X server, just asks the X server to
setuid()/setgid() to the logged in user.

       -Alan Coopersmith-           alan.coopersmith@sun.com
        Sun Microsystems, Inc. - X Window System Engineering


Brian Cameron wrote:
> Xavier:
>
>> I see in the docs that this interface is supported in Solaris for
>> restarting the X sever as the login user. Where is the code that
>> implements this support, I looked around but it isn't obvious? Could
>> similar functionality (server restart as login user) be implemented
>> for other OSs, like Fedora?
>
> This is only supported in GDM 2.20 and earlier.  GDM 2.22 doesn't yet
> support this kind of interface.  Solaris will patch the new GDM rewrite
> to continue using this interface.
>
> At the moment, the interfaces for making this work are patched into
> Sun's Xserver code, and isn't generally available to other Xorg users.
>
> I know that Alan Coopersmith of the Sun Xserver team has been planning
> to work with the upstream Xorg community to make this feature more
> general, so it can be supported on other platforms.  However, I know
> Alan has been busy and I am guessing he probably won't have time to
> work on this in the near future.  However, I think the security
> advantages of this sort of feature has obvious advantages, so it would
> be good to further encourage the Xorg project to consider adding a
> more supported public interface for doing this.  Might be good to
> make sure there is an enhancement request filed in the Xorg bugzilla
> database about this.
>
> Brian


--
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: rbacsep: collapsing xserver

[Xavier Toth]

On Thu, May 29, 2008 at 8:04 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Daniel J Walsh wrote:
>>
>> Xavier Toth wrote:
>>
>>>
>>> On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@tycho.nsa.gov>
>>> wrote:
>>>
>>>>
>>>> Christopher J. PeBenito wrote:
>>>>
>>>>>
>>>>> On Wed, 2008-05-28 at 11:42 -0500, Joe Nall wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, May 28, 2008 at 11:02 AM, Christopher J. PeBenito
>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, 2008-05-28 at 10:16 -0500, Joe Nall wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, May 28, 2008 at 9:38 AM, Christopher J. PeBenito
>>>>>>>> <cpebenito@tresys.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've got to the point where I am collapsing the derived types in
>>>>>>>>> the
>>>>>>>>> xserver module.  It would be nice to collapse all of the X server
>>>>>>>>> domains into xserver_t, but we have xdm_xserver_t which has
>>>>>>>>> permissions
>>>>>>>>> greater than user_xserver_t, staff_server_t, etc.  However, just
>>>>>>>>> about
>>>>>>>>> everyone runs their xserver in xdm_xserver_t due to logging in via
>>>>>>>>> xdm.
>>>>>>>>> Thoughts on collapsing all of the xservers anyway?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why is the way the xserver gets launched important once it is
>>>>>>>> running?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> If you log into the console and run startx, your xserver is
>>>>>>> user_xserver_t, staff_xserver_t, etc.  If you log in via a display
>>>>>>> manager, your xserver is xdm_xserver_t, since the server is started
>>>>>>> by
>>>>>>> xdm before a user logs in.  So you lose separation if you log in via
>>>>>>> xdm.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Understood.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> There have been suggestions about either restarting the xserver or
>>>>>>> dyntransitioning it to the correct context after logging in, but
>>>>>>> nothing
>>>>>>> materialized on that.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Does that change when X is an object manager?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Poorly worded question. _Should_ that change when X is a object
>>>>>> manager?
>>>>>>
>>>>>>
>>>>>
>>>>> We would certainly prefer that each role always has their derived type
>>>>> xserver (or role is set on xserver, if rbacsep succeeds), regardless if
>>>>> its an object manager or not.
>>>>>
>>>>>
>>>>
>>>> I have always disliked xdm_xserver_t and its associated policy
>>>> shenanigans
>>>> (what if someone creates a role named "xdm"?)
>>>>
>>>> The problem has always been the display manager behavior described
>>>> above.
>>>>  However this can be solved in at least three ways: 1) Restart the X
>>>> server
>>>> after the user logs in.  2) Have the X server setcon itself to the new
>>>> context.  3) Multi-user switching where xdm stays up all the time and
>>>> users
>>>> get new X servers on different consoles.
>>>>
>>>> The easiest solution for me to work on is 2) because I don't have to
>>>> touch
>>>> the GDM code.  I'd like to see rbacsep succeed though.
>>>>
>>>>
>>>>>>
>>>>>> What is the driver for the derived types? User preference files in
>>>>>> their home directory?
>>>>>>
>>>>>>
>>>>
>>>> There's some argument to be made that the X server is part of the user's
>>>> session.  For example, in mulit-user switching there is more than one
>>>> server
>>>> running, one for each user.
>>>>
>>>> If rbacsep succeeds then the derived types will go away regardless.
>>>>
>>>>
>>>>>>>>
>>>>>>>> On a related topic, what is the type enforcement strategy for window
>>>>>>>> managers?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> They currently run in the user's context.  The basic templates in the
>>>>>>> policy should still allow for separations.  The policy for X objects
>>>>>>> is
>>>>>>> still immature, so I'm definitely open to suggestions.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I did some brief experiments with the X server in MLS enforcing mode a
>>>>>> while back and it looked like a separate type would be required to
>>>>>> avoid giving the user silly levels of privilege. I'll try to get back
>>>>>> to those experiments next week.
>>>>>>
>>>>>>
>>>>
>>>> The window manager must have full access to all windows on the screens
>>>> that
>>>> it's managing.  In non-MLS this means at least full privileges on the
>>>> role
>>>> and probably for other roles too, if you're going to be popping up
>>>> sysadm
>>>> windows.  In MLS this means access across all levels, there's really no
>>>> way
>>>> around this.
>>>>
>>>>
>>>>
>>>>>>
>>>>>> Any opinions on spitting the display manager (gdm/xdm) policy out of
>>>>>> the xserver policy? The current xserver policy is quite a bit bigger
>>>>>> than apache and several times the average policy size (te + if).
>>>>>>
>>>>>>
>>>>>
>>>>> You can blame me for that.  The xdm policy used to be separate before
>>>>> refpolicy, but it was so intertwined with the xserver policy that there
>>>>> wasn't a sane way to write the policies separately and still keep the
>>>>> refpolicy encapsulation.  If we collapse all xservers into xserver_t,
>>>>> it
>>>>> may be possible to separate xdm again.  If not, xdm will be put into a
>>>>> tunable when we get real tunable support in the compiler.
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>>
>>>
>>> From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:
>>>
>>> "On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
>>> after user authentication to tell the X server to be restarted as the
>>> user instead of as root for added security. When the user's session
>>> exits, the GDM daemon will run the PostSession script as root."
>>>
>>> Couldn't we utilize the same functionality on Fedora?
>>>
>
> I've got no problem with doing something like this.  I've already written
> support for communicating with the X server from pam_selinux.so to set up
> the user's device labels, so it could also tell the server to setcon itself.
>  That work has stalled because of dependency issues (pam depending on
> libxcb), getting PAM_XAUTH_DATA support into gdm, and waiting for the next
> release of libxcb.  But, I can pick up work on it once I finish the X Python
> stuff.
>
> With regards to SDTLOGIN, it doesn't look like it restarts the server, only
> causes it to drop privileges; see
> http://osdir.com/ml/gnome.gdm.general/2007-10/msg00080.html dated Oct 2007.
>  The current gdm upstream seems to have dropped support for it.  I did some
> grepping in the gdm source and couldn't find anything.  It's probably a
> temporary result of the gdm rewrite.
>

Yes, I think Brian mentioned that the server is not actually restarted
but rather does a setuid/setgid because of the need to be root during
some portion of the X sever initialization. Hopefully it won't be too
much trouble to add a setcon too. One question about this is what will
happen with audit once the X server transition user and context?

>
>>>
>>> --
>>> 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.
>>>
>>
>> Probably better asked on the Fedora List.
>>
>>
>
> --
> 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: rbacsep: collapsing xserver

[Joe Nall]

On Fri, May 30, 2008 at 9:58 AM, Xavier Toth <txtoth@gmail.com> wrote:

> Yes, I think Brian mentioned that the server is not actually restarted
> but rather does a setuid/setgid because of the need to be root during
> some portion of the X sever initialization. Hopefully it won't be too
> much trouble to add a setcon too. One question about this is what will
> happen with audit once the X server transition user and context?

The goal being to start out in xdm_xserver_t during login and
transition to ROLE_xserver_t, correct?

joe

--
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: rbacsep: collapsing xserver

[Casey Schaufler]

--- Xavier Toth <txtoth@gmail.com> wrote:


> >>> From http://www.gnome.org/projects/gdm/docs/2.20/overview.html:
> >>>
> >>> "On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface
> >>> after user authentication to tell the X server to be restarted as the
> >>> user instead of as root for added security. When the user's session
> >>> exits, the GDM daemon will run the PostSession script as root."
> >>>
> >>> Couldn't we utilize the same functionality on Fedora?
> >>>
> >
> > I've got no problem with doing something like this.  I've already written
> > support for communicating with the X server from pam_selinux.so to set up
> > the user's device labels, so it could also tell the server to setcon
> itself.
> >  That work has stalled because of dependency issues (pam depending on
> > libxcb), getting PAM_XAUTH_DATA support into gdm, and waiting for the next
> > release of libxcb.  But, I can pick up work on it once I finish the X
> Python
> > stuff.
> >
> > With regards to SDTLOGIN, it doesn't look like it restarts the server, only
> > causes it to drop privileges; see
> > http://osdir.com/ml/gnome.gdm.general/2007-10/msg00080.html dated Oct 2007.
> >  The current gdm upstream seems to have dropped support for it.  I did some
> > grepping in the gdm source and couldn't find anything.  It's probably a
> > temporary result of the gdm rewrite.
> >
> 
> Yes, I think Brian mentioned that the server is not actually restarted
> but rather does a setuid/setgid because of the need to be root during
> some portion of the X sever initialization. Hopefully it won't be too
> much trouble to add a setcon too. One question about this is what will
> happen with audit once the X server transition user and context?

Just to offer the other point of view, Trusted Irix restarts the
X server on each login. In addition to how much simpler it makes
the process, doing it this way addresses all object reuse issues
which I dare say calling setcon will not suffice to address.


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.