* [refpolicy] kdbus support @ 2015-08-03 12:31 Miroslav Grepl 2015-08-03 13:27 ` Stephen Smalley 0 siblings, 1 reply; 16+ messages in thread From: Miroslav Grepl @ 2015-08-03 12:31 UTC (permalink / raw) To: refpolicy 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 12:31 [refpolicy] kdbus support Miroslav Grepl @ 2015-08-03 13:27 ` Stephen Smalley 2015-08-03 13:34 ` Miroslav Grepl 2015-08-03 14:33 ` Daniel J Walsh 0 siblings, 2 replies; 16+ messages in thread From: Stephen Smalley @ 2015-08-03 13:27 UTC (permalink / raw) To: refpolicy 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 13:27 ` Stephen Smalley @ 2015-08-03 13:34 ` Miroslav Grepl 2015-08-03 14:33 ` Daniel J Walsh 1 sibling, 0 replies; 16+ messages in thread From: Miroslav Grepl @ 2015-08-03 13:34 UTC (permalink / raw) To: refpolicy 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 13:27 ` Stephen Smalley 2015-08-03 13:34 ` Miroslav Grepl @ 2015-08-03 14:33 ` Daniel J Walsh 2015-08-03 15:40 ` Stephen Smalley 2015-08-03 18:19 ` Dominick Grift 1 sibling, 2 replies; 16+ messages in thread From: Daniel J Walsh @ 2015-08-03 14:33 UTC (permalink / raw) To: refpolicy 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 14:33 ` Daniel J Walsh @ 2015-08-03 15:40 ` Stephen Smalley 2015-08-03 15:52 ` Daniel J Walsh 2015-08-03 18:19 ` Dominick Grift 1 sibling, 1 reply; 16+ messages in thread From: Stephen Smalley @ 2015-08-03 15:40 UTC (permalink / raw) To: refpolicy 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... ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 15:40 ` Stephen Smalley @ 2015-08-03 15:52 ` Daniel J Walsh 2015-08-03 15:55 ` Stephen Smalley 2015-08-27 15:06 ` Dominick Grift 0 siblings, 2 replies; 16+ messages in thread From: Daniel J Walsh @ 2015-08-03 15:52 UTC (permalink / raw) To: refpolicy 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 15:52 ` Daniel J Walsh @ 2015-08-03 15:55 ` Stephen Smalley 2015-08-03 18:21 ` Dominick Grift 2015-08-03 19:28 ` Paul Moore 2015-08-27 15:06 ` Dominick Grift 1 sibling, 2 replies; 16+ messages in thread From: Stephen Smalley @ 2015-08-03 15:55 UTC (permalink / raw) To: refpolicy 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... ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 15:55 ` Stephen Smalley @ 2015-08-03 18:21 ` Dominick Grift 2015-08-03 18:30 ` Dominick Grift 2015-08-03 19:28 ` Paul Moore 1 sibling, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-08-03 18:21 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 18:21 ` Dominick Grift @ 2015-08-03 18:30 ` Dominick Grift 2015-08-03 18:41 ` Daniel J Walsh 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2015-08-03 18:30 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 18:30 ` Dominick Grift @ 2015-08-03 18:41 ` Daniel J Walsh 2015-08-03 18:54 ` Dominick Grift 2015-08-27 15:46 ` Dominick Grift 0 siblings, 2 replies; 16+ messages in thread From: Daniel J Walsh @ 2015-08-03 18:41 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 18:41 ` Daniel J Walsh @ 2015-08-03 18:54 ` Dominick Grift 2015-08-27 15:46 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-08-03 18:54 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 18:41 ` Daniel J Walsh 2015-08-03 18:54 ` Dominick Grift @ 2015-08-27 15:46 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-08-27 15:46 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 15:55 ` Stephen Smalley 2015-08-03 18:21 ` Dominick Grift @ 2015-08-03 19:28 ` Paul Moore 2015-08-05 12:19 ` Miroslav Grepl 1 sibling, 1 reply; 16+ messages in thread From: Paul Moore @ 2015-08-03 19:28 UTC (permalink / raw) To: refpolicy On Mon, Aug 3, 2015 at 11:55 AM, Stephen Smalley <sds@tycho.nsa.gov> 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 www.paul-moore.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 19:28 ` Paul Moore @ 2015-08-05 12:19 ` Miroslav Grepl 0 siblings, 0 replies; 16+ messages in thread From: Miroslav Grepl @ 2015-08-05 12:19 UTC (permalink / raw) To: refpolicy On 08/03/2015 09:28 PM, Paul Moore wrote: > On Mon, Aug 3, 2015 at 11:55 AM, Stephen Smalley <sds@tycho.nsa.gov> 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 15:52 ` Daniel J Walsh 2015-08-03 15:55 ` Stephen Smalley @ 2015-08-27 15:06 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-08-27 15:06 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [refpolicy] kdbus support 2015-08-03 14:33 ` Daniel J Walsh 2015-08-03 15:40 ` Stephen Smalley @ 2015-08-03 18:19 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2015-08-03 18:19 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-08-27 15:46 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-03 12:31 [refpolicy] kdbus support Miroslav Grepl 2015-08-03 13:27 ` Stephen Smalley 2015-08-03 13:34 ` Miroslav Grepl 2015-08-03 14:33 ` Daniel J Walsh 2015-08-03 15:40 ` Stephen Smalley 2015-08-03 15:52 ` Daniel J Walsh 2015-08-03 15:55 ` Stephen Smalley 2015-08-03 18:21 ` Dominick Grift 2015-08-03 18:30 ` Dominick Grift 2015-08-03 18:41 ` Daniel J Walsh 2015-08-03 18:54 ` Dominick Grift 2015-08-27 15:46 ` Dominick Grift 2015-08-03 19:28 ` Paul Moore 2015-08-05 12:19 ` Miroslav Grepl 2015-08-27 15:06 ` Dominick Grift 2015-08-03 18:19 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.