Re: rbacsep: collapsing xserver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux