---------- Forwarded message ---------- From: Xavier Toth <txtoth@xxxxxxxxx> Date: Thu, May 29, 2008 at 3:02 PM Subject: Re: rbacsep: collapsing xserver To: Daniel J Walsh <dwalsh@xxxxxxxxxx> On Thu, May 29, 2008 at 2:50 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > 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. > 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
