From: dwalsh@redhat.com (Daniel J Walsh)
Date: Mon, 3 Aug 2015 14:41:11 -0400
Subject: [refpolicy] kdbus support
In-Reply-To: <20150803183022.GC31031@x250>
References: <55BF5F1B.1010002@redhat.com> <55BF6C54.9070806@tycho.nsa.gov>
	<55BF7BA8.8000905@redhat.com> <55BF8B58.7000100@tycho.nsa.gov>
	<55BF8E4C.9010706@redhat.com> <55BF8ED7.1000402@tycho.nsa.gov>
	<20150803182111.GB31031@x250> <20150803183022.GC31031@x250>
Message-ID: <55BFB5C7.9020400@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On 08/03/2015 02:30 PM, Dominick Grift wrote:
> On Mon, Aug 03, 2015 at 08:21:11PM +0200, Dominick Grift wrote:
>> On Mon, Aug 03, 2015 at 11:55:03AM -0400, Stephen Smalley wrote:
>>> On 08/03/2015 11:52 AM, Daniel J Walsh wrote:
>>>>
>>>> On 08/03/2015 11:40 AM, Stephen Smalley wrote:
>>>>> On 08/03/2015 10:33 AM, Daniel J Walsh wrote:
>>>>>> On 08/03/2015 09:27 AM, Stephen Smalley wrote:
>>>>>>> On 08/03/2015 08:31 AM, Miroslav Grepl wrote:
>>>>>>>> I am working on kdbus support on Fedora 24. Basically we need to add
>>>>>>>> support for
>>>>>>>>
>>>>>>>> /sys/fs/kdbus
>>>>>>>>
>>>>>>>> and I am thinking about correct labeling. Something like
>>>>>>>>
>>>>>>>> +type kdbusfs_t;
>>>>>>>> +fs_type(kdbusfs_t)
>>>>>>>> +files_mountpoint(kdbusfs_t)
>>>>>>>> +dev_associate_sysfs(kdbusfs_t)
>>>>>>>> +genfscon kdbusfs / gen_context(system_u:object_r:kdbusfs_t,s0)
>>>>>>>>
>>>>>>>> What do you think about kdbusfs_t label?
>>>>>>> Until kdbus has LSM hooks, it should not be accessible by anything.
>>>>>>> Otherwise, it is a completely uncontrolled IPC mechanism by which
>>>>>>> anything is free to violate policy on the system.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> refpolicy mailing list
>>>>>>> refpolicy at oss.tresys.com
>>>>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>>>> Well Rawhide is totally broken right now, and everyone has to boot in
>>>>>> permissive mode.
>>>>>>
>>>>>> We need to allow this for now and then fix the kernel.
>>>>>>
>>>>> Is it unreasonable to require Fedora developers to test with SELinux
>>>>> enforcing before submitting changes?  Especially systemd...
>>>>>
>>>> I am sure the developers would argue that the whole process would ground
>>>> to a halt.
>>> Seems problematic otherwise, as 1) it shifts the blame for breakage to
>>> SELinux rather than to the offending change, and 2) it teaches
>>> developers and users of rawhide to just always disable SELinux to avoid
>>> such breakage, which only further reinforces the problem.  And then
>>> fixing such issues falls entirely on you and never on the developer who
>>> made the change.  Certainly seems problematic that the maintainer of a
>>> such a critical package as systemd runs with SELinux disabled...
>>>
>> Amen!
>
> No but seriously, you can't really do this . rawhide is always broken to some extent. if you write policy for rawhide then this is very hard to do.
>
> there always a truckload of access needed but buggy code paths. So either you keep a todo list and ignore the bugs or you allow the buggy code paths and end up with a policy that allows stuff that is really just for temporary bugs.
>
> believe me, i know. I chose a mix of the former and the latter and pretty all of my systems are rawhide.
>
> It can become frustrating, every day updates, and most of the time new bugs introduced. filing bug reports for bugs exposed by the policy. following the bug progress , temporarily deal with issues, then revert once the issues are fixed.
>
> its tough!
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
I would say that the systemd guys have always been pretty good
responsive about SELinux,
and Rawhide has been regularly broken.  Which is why I always run it to
find out what SELinux breaks.

Developers are always going to care about Security less then getting
their cool new feature in. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20150803/0962e36c/attachment.html