From: dac.override@gmail.com (Dominick Grift)
Date: Mon, 3 Aug 2015 20:30:23 +0200
Subject: [refpolicy] kdbus support
In-Reply-To: <20150803182111.GB31031@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>
Message-ID: <20150803183022.GC31031@x250>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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