window manager policy

window manager policy

[Xavier Toth]

I'm contemplating some AVC's that originate in metacity and am
wondering whether a window manager is a special case of an X client
that requires its' own policy. Are there things that a window manager
does that other X clients shouldn't? Also on an MLS system should the
window manager run at the users highwater mark or ranged?

--
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: window manager policy

[Eamon Walsh]

Xavier Toth wrote:
> I'm contemplating some AVC's that originate in metacity and am
> wondering whether a window manager is a special case of an X client
> that requires its' own policy. Are there things that a window manager
> does that other X clients shouldn't? Also on an MLS system should the
> window manager run at the users highwater mark or ranged?
>   

The window manager basically needs the full run of the display.  When 
another application creates a window, the window manager creates a 
second window with the titlebar and borders, and then plops the 
application window down inside of it (reparents it).  It also moves 
windows around and resizes them, sets properties on them (such as the 
_NET_WM_DESKTOP property that contains the desktop number) and listens 
for events so it can tell when to change the focus window.  Finally, a 
compositing manager actually needs to read the window contents.  It's 
definitely a special-case app that's going to need its own policy.

It almost certainly needs permissions on all windows that map to both 
read and write in the MLS configuration.  So it will need read- and 
write-all-levels.



-- 
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: window manager policy

[Joe Nall]

On Jun 18, 2008, at 7:20 PM, Eamon Walsh wrote:

> Xavier Toth wrote:
>> I'm contemplating some AVC's that originate in metacity and am
>> wondering whether a window manager is a special case of an X client
>> that requires its' own policy. Are there things that a window manager
>> does that other X clients shouldn't? Also on an MLS system should the
>> window manager run at the users highwater mark or ranged?
>>
>
> The window manager basically needs the full run of the display.   
> When another application creates a window, the window manager  
> creates a second window with the titlebar and borders, and then  
> plops the application window down inside of it (reparents it).  It  
> also moves windows around and resizes them, sets properties on them  
> (such as the _NET_WM_DESKTOP property that contains the desktop  
> number) and listens for events so it can tell when to change the  
> focus window.  Finally, a compositing manager actually needs to read  
> the window contents.  It's definitely a special-case app that's  
> going to need its own policy.
>
> It almost certainly needs permissions on all windows that map to  
> both read and write in the MLS configuration.  So it will need read-  
> and write-all-levels.

What other desktop related processes need MLS policies to be written  
to get a minimally functional Fedora/Gnome enforcing X environment?

What window manager/environment do you use in your enforcing X  
development and test?

Do you have a start on a window manager policy that we could try?

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: window manager policy

[Joe Nall]

On Jun 18, 2008, at 7:20 PM, Eamon Walsh wrote:

> Xavier Toth wrote:
>> I'm contemplating some AVC's that originate in metacity and am
>> wondering whether a window manager is a special case of an X client
>> that requires its' own policy. Are there things that a window manager
>> does that other X clients shouldn't? Also on an MLS system should the
>> window manager run at the users highwater mark or ranged?
>>
>
> The window manager basically needs the full run of the display.   
> When another application creates a window, the window manager  
> creates a second window with the titlebar and borders, and then  
> plops the application window down inside of it (reparents it).  It  
> also moves windows around and resizes them, sets properties on them  
> (such as the _NET_WM_DESKTOP property that contains the desktop  
> number) and listens for events so it can tell when to change the  
> focus window.  Finally, a compositing manager actually needs to read  
> the window contents.  It's definitely a special-case app that's  
> going to need its own policy.
>
> It almost certainly needs permissions on all windows that map to  
> both read and write in the MLS configuration.  So it will need read-  
> and write-all-levels.

What other desktop related processes need MLS policies to be written  
to get a minimally functional Fedora/Gnome enforcing X environment?

What window manager/environment do you use in your enforcing X  
development and test?

Do you have a start on a window manager policy that we could try?

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: window manager policy

[Russell Coker]

On Friday 20 June 2008 09:12, Joe Nall <joe@nall.com> wrote:
> What other desktop related processes need MLS policies to be written  
> to get a minimally functional Fedora/Gnome enforcing X environment?

The clipboard manager.  But of course that also needs some serious coding to 
preserve the labels on copied data as well as relabelling it if requested and 
permitted.

Of course it may be a matter of opinion whether functional cut/paste 
is "minimal" desktop use.

-- 
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: window manager policy

[Eamon Walsh]

Joe Nall wrote:
> On Jun 18, 2008, at 7:20 PM, Eamon Walsh wrote:
>
>   
>> Xavier Toth wrote:
>>     
>>> I'm contemplating some AVC's that originate in metacity and am
>>> wondering whether a window manager is a special case of an X client
>>> that requires its' own policy. Are there things that a window manager
>>> does that other X clients shouldn't? Also on an MLS system should the
>>> window manager run at the users highwater mark or ranged?
>>>
>>>       
>> The window manager basically needs the full run of the display.   
>> When another application creates a window, the window manager  
>> creates a second window with the titlebar and borders, and then  
>> plops the application window down inside of it (reparents it).  It  
>> also moves windows around and resizes them, sets properties on them  
>> (such as the _NET_WM_DESKTOP property that contains the desktop  
>> number) and listens for events so it can tell when to change the  
>> focus window.  Finally, a compositing manager actually needs to read  
>> the window contents.  It's definitely a special-case app that's  
>> going to need its own policy.
>>
>> It almost certainly needs permissions on all windows that map to  
>> both read and write in the MLS configuration.  So it will need read-  
>> and write-all-levels.
>>     
>
> What other desktop related processes need MLS policies to be written  
> to get a minimally functional Fedora/Gnome enforcing X environment?
>   

Don't know for sure...but probably gnome-session (starts up processes), 
nautilus and gnome-panel (can be used to launch processes; gnome-panel 
interacts with small applet windows that are inside it).

> What window manager/environment do you use in your enforcing X  
> development and test?
>   

I have one machine where I compile the full Xorg distribution, policy, 
and a few other things (pam, gdm) from scratch.  I just finished setting 
up another machine that runs Fedora 9, with just refpolicy and XCB 
compiled from source.  This should make it easier for me to develop and 
test policy.  It's just running regular GNOME, although I may install 
XFCE on it as well.

> Do you have a start on a window manager policy that we could try?
>   

It should be transitioned into a domain that has unconfined TE perms 
over X objects, and is MLS trusted.  After that it's a matter of seeing 
what permissions regular applications need over window-manager created 
windows, particularly decoration windows.  They might need some 
permissions over the window manager's windows since they might try to 
manipulate the window-manager "decoration" windows that their own app 
window is reparented into.  To deal with this, I think that the window 
manager is going to need to call SetWindowCreateContext to put window 
decorations into the same context as the associated application window.  
I'm hoping to try and make a patch to do this, this week.


-- 
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: window manager policy

[Xavier Toth]

On Mon, Jun 23, 2008 at 12:18 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Joe Nall wrote:
>>
>> On Jun 18, 2008, at 7:20 PM, Eamon Walsh wrote:
>>
>>
>>>
>>> Xavier Toth wrote:
>>>
>>>>
>>>> I'm contemplating some AVC's that originate in metacity and am
>>>> wondering whether a window manager is a special case of an X client
>>>> that requires its' own policy. Are there things that a window manager
>>>> does that other X clients shouldn't? Also on an MLS system should the
>>>> window manager run at the users highwater mark or ranged?
>>>>
>>>>
>>>
>>> The window manager basically needs the full run of the display.   When
>>> another application creates a window, the window manager  creates a second
>>> window with the titlebar and borders, and then  plops the application window
>>> down inside of it (reparents it).  It  also moves windows around and resizes
>>> them, sets properties on them  (such as the _NET_WM_DESKTOP property that
>>> contains the desktop  number) and listens for events so it can tell when to
>>> change the  focus window.  Finally, a compositing manager actually needs to
>>> read  the window contents.  It's definitely a special-case app that's  going
>>> to need its own policy.
>>>
>>> It almost certainly needs permissions on all windows that map to  both
>>> read and write in the MLS configuration.  So it will need read-  and
>>> write-all-levels.
>>>
>>
>> What other desktop related processes need MLS policies to be written  to
>> get a minimally functional Fedora/Gnome enforcing X environment?
>>
>
> Don't know for sure...but probably gnome-session (starts up processes),
> nautilus and gnome-panel (can be used to launch processes; gnome-panel
> interacts with small applet windows that are inside it).
>
>> What window manager/environment do you use in your enforcing X
>>  development and test?
>>
>
> I have one machine where I compile the full Xorg distribution, policy, and a
> few other things (pam, gdm) from scratch.  I just finished setting up
> another machine that runs Fedora 9, with just refpolicy and XCB compiled
> from source.  This should make it easier for me to develop and test policy.
>  It's just running regular GNOME, although I may install XFCE on it as well.
>
>> Do you have a start on a window manager policy that we could try?
>>
>
> It should be transitioned into a domain that has unconfined TE perms over X
> objects, and is MLS trusted.

MLS policy doesn't come with unconfined, right? I can build it in but
what's are people thinking long term about doing this, will it be
included in future MLS policy configurations?

>  After that it's a matter of seeing what
> permissions regular applications need over window-manager created windows,
> particularly decoration windows.  They might need some permissions over the
> window manager's windows since they might try to manipulate the
> window-manager "decoration" windows that their own app window is reparented
> into.  To deal with this, I think that the window manager is going to need
> to call SetWindowCreateContext to put window decorations into the same
> context as the associated application window.

This will introduce a xcb-xselinux dependency.

> I'm hoping to try and make a
> patch to do this, this week.
>
>
> --
> 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: window manager policy

[Eamon Walsh]

Xavier Toth wrote:
> On Mon, Jun 23, 2008 at 12:18 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> Joe Nall wrote:
>>     
>>> On Jun 18, 2008, at 7:20 PM, Eamon Walsh wrote:
>>>
>>>
>>>       
>>>> Xavier Toth wrote:
>>>>
>>>>         
>>>>> I'm contemplating some AVC's that originate in metacity and am
>>>>> wondering whether a window manager is a special case of an X client
>>>>> that requires its' own policy. Are there things that a window manager
>>>>> does that other X clients shouldn't? Also on an MLS system should the
>>>>> window manager run at the users highwater mark or ranged?
>>>>>
>>>>>
>>>>>           
>>>> The window manager basically needs the full run of the display.   When
>>>> another application creates a window, the window manager  creates a second
>>>> window with the titlebar and borders, and then  plops the application window
>>>> down inside of it (reparents it).  It  also moves windows around and resizes
>>>> them, sets properties on them  (such as the _NET_WM_DESKTOP property that
>>>> contains the desktop  number) and listens for events so it can tell when to
>>>> change the  focus window.  Finally, a compositing manager actually needs to
>>>> read  the window contents.  It's definitely a special-case app that's  going
>>>> to need its own policy.
>>>>
>>>> It almost certainly needs permissions on all windows that map to  both
>>>> read and write in the MLS configuration.  So it will need read-  and
>>>> write-all-levels.
>>>>
>>>>         
>>> What other desktop related processes need MLS policies to be written  to
>>> get a minimally functional Fedora/Gnome enforcing X environment?
>>>
>>>       
>> Don't know for sure...but probably gnome-session (starts up processes),
>> nautilus and gnome-panel (can be used to launch processes; gnome-panel
>> interacts with small applet windows that are inside it).
>>
>>     
>>> What window manager/environment do you use in your enforcing X
>>>  development and test?
>>>
>>>       
>> I have one machine where I compile the full Xorg distribution, policy, and a
>> few other things (pam, gdm) from scratch.  I just finished setting up
>> another machine that runs Fedora 9, with just refpolicy and XCB compiled
>> from source.  This should make it easier for me to develop and test policy.
>>  It's just running regular GNOME, although I may install XFCE on it as well.
>>
>>     
>>> Do you have a start on a window manager policy that we could try?
>>>
>>>       
>> It should be transitioned into a domain that has unconfined TE perms over X
>> objects, and is MLS trusted.
>>     
>
> MLS policy doesn't come with unconfined, right? I can build it in but
> what's are people thinking long term about doing this, will it be
> included in future MLS policy configurations?
>   

Not fully unconfined as in unconfined_t, just unconfined over X 
permissions.  I think in my earlier policy work I had made, or at least 
attempted to make, a $1_wm_t domain to fulfill this purpose.


>   
>>  After that it's a matter of seeing what
>> permissions regular applications need over window-manager created windows,
>> particularly decoration windows.  They might need some permissions over the
>> window manager's windows since they might try to manipulate the
>> window-manager "decoration" windows that their own app window is reparented
>> into.  To deal with this, I think that the window manager is going to need
>> to call SetWindowCreateContext to put window decorations into the same
>> context as the associated application window.
>>     
>
> This will introduce a xcb-xselinux dependency.
>   

Right, this would depend on that being released.  But the dependency 
itself shouldn't be too much of a problem.  If you do a "rpm -q 
--requires libX11" in Fedora you will see that Xlib already depends on 
XCB.  So the package should be present on the system, although the 
specific extension library would be a new link requirement.



-- 
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: window manager policy

[Xavier Toth]

On Mon, Jun 23, 2008 at 12:18 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Joe Nall wrote:
>>
>> On Jun 18, 2008, at 7:20 PM, Eamon Walsh wrote:
>>
>>
>>>
>>> Xavier Toth wrote:
>>>
>>>>
>>>> I'm contemplating some AVC's that originate in metacity and am
>>>> wondering whether a window manager is a special case of an X client
>>>> that requires its' own policy. Are there things that a window manager
>>>> does that other X clients shouldn't? Also on an MLS system should the
>>>> window manager run at the users highwater mark or ranged?
>>>>
>>>>
>>>
>>> The window manager basically needs the full run of the display.   When
>>> another application creates a window, the window manager  creates a second
>>> window with the titlebar and borders, and then  plops the application window
>>> down inside of it (reparents it).  It  also moves windows around and resizes
>>> them, sets properties on them  (such as the _NET_WM_DESKTOP property that
>>> contains the desktop  number) and listens for events so it can tell when to
>>> change the  focus window.  Finally, a compositing manager actually needs to
>>> read  the window contents.  It's definitely a special-case app that's  going
>>> to need its own policy.
>>>
>>> It almost certainly needs permissions on all windows that map to  both
>>> read and write in the MLS configuration.  So it will need read-  and
>>> write-all-levels.
>>>
>>
>> What other desktop related processes need MLS policies to be written  to
>> get a minimally functional Fedora/Gnome enforcing X environment?
>>
>
> Don't know for sure...but probably gnome-session (starts up processes),

After working on an initial window manager policy I've been thinking
about how it is started by gnome-session and whether it should be run
at the users clearance, what does everyone think?

> nautilus and gnome-panel (can be used to launch processes; gnome-panel
> interacts with small applet windows that are inside it).
>
>> What window manager/environment do you use in your enforcing X
>>  development and test?
>>
>
> I have one machine where I compile the full Xorg distribution, policy, and a
> few other things (pam, gdm) from scratch.  I just finished setting up
> another machine that runs Fedora 9, with just refpolicy and XCB compiled
> from source.  This should make it easier for me to develop and test policy.
>  It's just running regular GNOME, although I may install XFCE on it as well.
>
>> Do you have a start on a window manager policy that we could try?
>>
>
> It should be transitioned into a domain that has unconfined TE perms over X
> objects, and is MLS trusted.  After that it's a matter of seeing what
> permissions regular applications need over window-manager created windows,
> particularly decoration windows.  They might need some permissions over the
> window manager's windows since they might try to manipulate the
> window-manager "decoration" windows that their own app window is reparented
> into.  To deal with this, I think that the window manager is going to need
> to call SetWindowCreateContext to put window decorations into the same
> context as the associated application window.  I'm hoping to try and make a
> patch to do this, this week.
>
>
> --
> 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: window manager policy

[Eamon Walsh]

Joe Nall wrote:
>
> What other desktop related processes need MLS policies to be written  
> to get a minimally functional Fedora/Gnome enforcing X environment?
>
> What window manager/environment do you use in your enforcing X  
> development and test?
>   

Many AVC's I'm getting are caused by the fact that the server starts up 
as xdm_xserver_t:

allow sysadm_t xdm_rootwindow_t:x_colormap { use install uninstall };
allow sysadm_t xdm_rootwindow_t:x_drawable { get_property show read manage add_child remove_child list_child hide setattr receive set_property create send write
allow sysadm_t xdm_xserver_t:x_device { setfocus use setattr grab manage getattr freeze };
allow sysadm_t xdm_xserver_t:x_screen { saver_setattr saver_getattr setattr };
allow sysadm_t xdm_xserver_t:x_server manage;


...and xdm_t windows are apparently still open on the display when the 
user's gnome-session is run:

allow sysadm_t xdm_t:x_client destroy;
allow sysadm_t xdm_t:x_drawable { get_property receive getattr list_child };
allow sysadm_t xdm_xproperty_t:x_property { write read };



This week I attempted to write a prototype display manager that would 
stop the X server and run a new one after the user logs in.  However 
this process looks incredibly ugly and takes forever, and I'm also 
having trouble with the X server not starting up at all some of the 
time, so I've given up on that for now.

I did get a patch into gdm this week though.  Once libxcb-selinux is 
released I'll be able to make patch for PAM to have it relabel X server 
objects dynamically as part of pam_open_session.

I'll take a look at the window manager policy next week.

-- 
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: window manager policy

[Joe Nall]

On Jun 27, 2008, at 10:24 PM, Eamon Walsh wrote:

> Joe Nall wrote:
>>
>> What other desktop related processes need MLS policies to be  
>> written  to get a minimally functional Fedora/Gnome enforcing X  
>> environment?
>>
>> What window manager/environment do you use in your enforcing X   
>> development and test?
>>
>
> Many AVC's I'm getting are caused by the fact that the server starts  
> up as xdm_xserver_t:
>
> allow sysadm_t xdm_rootwindow_t:x_colormap { use install uninstall };
> allow sysadm_t xdm_rootwindow_t:x_drawable { get_property show read  
> manage add_child remove_child list_child hide setattr receive  
> set_property create send write
> allow sysadm_t xdm_xserver_t:x_device { setfocus use setattr grab  
> manage getattr freeze };
> allow sysadm_t xdm_xserver_t:x_screen { saver_setattr saver_getattr  
> setattr };
> allow sysadm_t xdm_xserver_t:x_server manage;
>
>
> ...and xdm_t windows are apparently still open on the display when  
> the user's gnome-session is run:
>
> allow sysadm_t xdm_t:x_client destroy;
> allow sysadm_t xdm_t:x_drawable { get_property receive getattr  
> list_child };
> allow sysadm_t xdm_xproperty_t:x_property { write read };
>
>
>
> This week I attempted to write a prototype display manager that  
> would stop the X server and run a new one after the user logs in.   
> However this process looks incredibly ugly and takes forever, and  
> I'm also having trouble with the X server not starting up at all  
> some of the time, so I've given up on that for now.

What about creating a new X on another virtual terminal and switching  
to it?

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: window manager policy

[Ted X Toth]

Eamon Walsh wrote:
> Joe Nall wrote:
>>
>> What other desktop related processes need MLS policies to be written  
>> to get a minimally functional Fedora/Gnome enforcing X environment?
>>
>> What window manager/environment do you use in your enforcing X  
>> development and test?
>>   
>
> Many AVC's I'm getting are caused by the fact that the server starts 
> up as xdm_xserver_t:
>
> allow sysadm_t xdm_rootwindow_t:x_colormap { use install uninstall };
> allow sysadm_t xdm_rootwindow_t:x_drawable { get_property show read 
> manage add_child remove_child list_child hide setattr receive 
> set_property create send write
> allow sysadm_t xdm_xserver_t:x_device { setfocus use setattr grab 
> manage getattr freeze };
> allow sysadm_t xdm_xserver_t:x_screen { saver_setattr saver_getattr 
> setattr };
> allow sysadm_t xdm_xserver_t:x_server manage;
>
>
> ...and xdm_t windows are apparently still open on the display when the 
> user's gnome-session is run:
>
> allow sysadm_t xdm_t:x_client destroy;
> allow sysadm_t xdm_t:x_drawable { get_property receive getattr 
> list_child };
> allow sysadm_t xdm_xproperty_t:x_property { write read };
>
>
>
> This week I attempted to write a prototype display manager that would 
> stop the X server and run a new one after the user logs in.  However 
> this process looks incredibly ugly and takes forever, and I'm also 
> having trouble with the X server not starting up at all some of the 
> time, so I've given up on that for now.
>
> I did get a patch into gdm this week though.  

What does the gdm mod do, restart the X server as the user?
> Once libxcb-selinux is released I'll be able to make patch for PAM to 
> have it relabel X server objects dynamically as part of pam_open_session.
>
> I'll take a look at the window manager policy next week.
>


--
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: window manager policy

[Eamon Walsh]

Ted X Toth wrote:
> Eamon Walsh wrote:
>   
>> Joe Nall wrote:
>>     
>>> What other desktop related processes need MLS policies to be written  
>>> to get a minimally functional Fedora/Gnome enforcing X environment?
>>>
>>> What window manager/environment do you use in your enforcing X  
>>> development and test?
>>>   
>>>       
>> Many AVC's I'm getting are caused by the fact that the server starts 
>> up as xdm_xserver_t:
>>
>> allow sysadm_t xdm_rootwindow_t:x_colormap { use install uninstall };
>> allow sysadm_t xdm_rootwindow_t:x_drawable { get_property show read 
>> manage add_child remove_child list_child hide setattr receive 
>> set_property create send write
>> allow sysadm_t xdm_xserver_t:x_device { setfocus use setattr grab 
>> manage getattr freeze };
>> allow sysadm_t xdm_xserver_t:x_screen { saver_setattr saver_getattr 
>> setattr };
>> allow sysadm_t xdm_xserver_t:x_server manage;
>>
>>
>> ...and xdm_t windows are apparently still open on the display when the 
>> user's gnome-session is run:
>>
>> allow sysadm_t xdm_t:x_client destroy;
>> allow sysadm_t xdm_t:x_drawable { get_property receive getattr 
>> list_child };
>> allow sysadm_t xdm_xproperty_t:x_property { write read };
>>
>>
>>
>> This week I attempted to write a prototype display manager that would 
>> stop the X server and run a new one after the user logs in.  However 
>> this process looks incredibly ugly and takes forever, and I'm also 
>> having trouble with the X server not starting up at all some of the 
>> time, so I've given up on that for now.
>>
>> I did get a patch into gdm this week though.  
>>     
>
> What does the gdm mod do, restart the X server as the user?
>   

It passes the X display name and auth cookie to PAM so that pam_selinux 
can connect to the X server at login time and do things like relabel 
device objects in preparation for the user session.




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