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?
Thanks.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
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.
On 08/03/2015 03:27 PM, 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.
>
>
Yes, just wanted to test it and see lot of CAP_IPC_OWNER.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
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.
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...
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.
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...
On Mon, Aug 03, 2015 at 10:33:12AM -0400, 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.
huh, rawhide works fine here just dont add kdbus=1 on the kernel boot line and youll be fine
one thing i noticed though is that even without kdbus=1 , alot of processes now all of a sudden want to traverse /sys
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150803/73f77623/attachment.bin
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!
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
02DFF788
4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150803/a356c791/attachment-0001.bin
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150803/dc6375cb/attachment.bin
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
On Mon, Aug 03, 2015 at 02:41:11PM -0400, Daniel J Walsh wrote:
>
>
> 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.
I don't agree with that assessment. Systemd is a special component and in that light i think the systemd community does not do enough in my view
You have a diffent point of view, i imagine, because you were contributing code. So your code may have been adopted promptly.
For me though i am hitting a brick wall trying to get systemd community to address selinux related issues.
First of all, before they commit anything they want to know exactly why. That is when you have to explain the issue. That is when they lose you. Thats when your bug report gets abandonned.
I can't even get them you add a simple lsetfilecon() call ... because they dont understand why its needed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150803/b8b91453/attachment.bin
On Mon, Aug 3, 2015 at 11:55 AM, Stephen Smalley <[email protected]> wrote:
> On 08/03/2015 11:52 AM, Daniel J Walsh wrote:
>> 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...
I completely agree with Stephen.
Adding kdbus without the necessary LSM/SELinux support it a security
regression, it's really that simple. While I agree that the systemd
developers seem to be a bit more responsive to SELinux faults than
most developers, there is absolutely no reason why they shouldn't have
done more to ensure the proper LSM/SELinux support. At the very
least, some emails about the kdbus development plans and timing would
have helped greatly.
As things stand there is almost surely going to be a gap where kdbus
is upstream but it is missing the necessary LSM/SELinux hooks. That
is a very bad thing in my opinion, made worse by the fact that is so
easily could have been avoided with better communication by the kdbus
developers.
--
paul moore
http://www.paul-moore.com
On 08/03/2015 09:28 PM, Paul Moore wrote:
> On Mon, Aug 3, 2015 at 11:55 AM, Stephen Smalley <[email protected]> wrote:
>> On 08/03/2015 11:52 AM, Daniel J Walsh wrote:
>>> 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...
>
> I completely agree with Stephen.
>
> Adding kdbus without the necessary LSM/SELinux support it a security
> regression, it's really that simple. While I agree that the systemd
> developers seem to be a bit more responsive to SELinux faults than
> most developers, there is absolutely no reason why they shouldn't have
> done more to ensure the proper LSM/SELinux support. At the very
> least, some emails about the kdbus development plans and timing would
> have helped greatly.
>
> As things stand there is almost surely going to be a gap where kdbus
> is upstream but it is missing the necessary LSM/SELinux hooks. That
> is a very bad thing in my opinion, made worse by the fact that is so
> easily could have been avoided with better communication by the kdbus
> developers.
>
I like to see this discussion here. Basically as Dan wrote it was about
to avoid unlabeled_t and have rawhide working somehow because it is
always important to catch most of issues in this phase. I will create a
tracker bug and collect all issues. And this is more easier with
kdbusfs_t labeling against unlabeled_t.
And of course, this is not something what we will keep in regular Fedora
releases.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Mon, Aug 03, 2015 at 11:52:44AM -0400, 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.
How does this development affect the state of selinux support for
systemd:
https://github.com/systemd/systemd/commit/8faae625dc9b6322db452937f54176e56e65265a
Also how would the issues described here related to systemd-nspawn and
possible systemd tools that (i suspect) enter the nspawn container namespaces: https://danwalsh.livejournal.com/72767.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCgAGBQJV3ydsAAoJENAR6kfG5xmcVu4L/37ELdZvUixxcNVnvBvAprPK
qBAUQQBwRyb+K1PUEmZfyik146mOrx1QilS0DrR5TfmeteO6To5KwPSrwzsYAbJc
c8KmhgVO0jnl37RwaE/1KWIb2ahtZYh0ML+yrWITKDxZSTv84zYPqsL1ME+HRvOR
0zYBwvUzUAYH+gvKN/Es9+9XR5+3T/tD2kHvgfECYAFpd6ALTq4R9id6Gz1d6vrj
FHT28+QKkzxSKdVYz1X20GFPMr5vyb6t9/LtY1luk+71GZbZ/9Ku/9aNK5BDvFro
d5Nvd36T8CdqEKIXu+nHaJRgPSkbda3iXIfknNhGf8R0n87BA1FPcAjXDF/XINoO
5zmxZqUXY/jAuxtJNEtSfAqo6lmXMQlvDqHTOUNReAOZQawdLyDFdeXENb6LhtzE
mdkFqoMtUPn6S3XMnrGfAP3SIYOoJ3ZpgysAgfOp+ixvm29oTZGcqFLcsAnpIbZL
sNDht2pELnGLmNFKUPMtyGdQcMQps97EEZouyx84Yg==
=7aO/
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Mon, Aug 03, 2015 at 02:41:11PM -0400, Daniel J Walsh wrote:
<snip>
> I would say that the systemd guys have always been pretty good
> responsive about SELinux,
They just committed your stuff without a proper review it seems. Most of
it was reverted silently later (and is still being reverted) leaving us
rawhide users with broken experience for months.
- --
02DFF788
4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQGcBAEBCgAGBQJV3zDDAAoJENAR6kfG5xmcA5gMAL2GSHlfiCp85C2Mf+CZomkc
Tmwie5Fe6MXAtlCXO4VicVvOZxz1+K1hwGkySE07czOp8KgvGqrn01deMG5oQkE2
hUyjWvD2mn3xtmQ2Af5DFF7cP80kljE9iHZq+WoWxHn25Pwre4UIQxc0gkHL1zD+
MIp96/iHpQlTwNdaifE2eMP8tku98PeId7rSTQl7Fc9P3WrhhrE9RDkuGiILg77E
jOJ7kAgT7FzMkVe495KEozUoLGqxfcSvF1aJ9qYTbT9j3F+jeh1c+9XYerbsxb5u
4ekQJqzOhzq8DOPHnuJJTK9dfnm/U9HwHvg0QCKK0GXK0CHAEBxRU1JQ7dF7lO+E
E4IlynnvONgSlFFwm2CyWlViEQVRZzY1eHs23vgwBoZG9uSp61HrV8ZvkFIULF/z
V6UwLFp8lt8ZvP6FzAPZqmKio/vtZVON8Hf0q+1H7phVpWmPLx6iLDn7tuBQDqcP
1oMRd4tJL7/A6xCNzSU7bh2M5vkOsxFWN87xcaSoSA==
=oz7L
-----END PGP SIGNATURE-----