On Wed, May 28, 2008 at 1:38 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > Joe Nall wrote: >> On Wed, May 28, 2008 at 1:16 PM, Christopher J. PeBenito >> <cpebenito@xxxxxxxxxx> 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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.