[refpolicy] kdbus support

[dwalsh@redhat.com (Daniel J Walsh)]

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