Xavier Toth wrote: > On Wed, May 28, 2008 at 1:59 PM, Eamon Walsh <ewalsh@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxx> >> 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@xxxxxxxxxxxxx >> 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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
