From: dac.override@gmail.com (Dominick Grift)
Date: Thu, 27 Aug 2015 17:06:25 +0200
Subject: [refpolicy] kdbus support
In-Reply-To: <55BF8E4C.9010706@redhat.com>
References: <55BF5F1B.1010002@redhat.com> <55BF6C54.9070806@tycho.nsa.gov>
	<55BF7BA8.8000905@redhat.com> <55BF8B58.7000100@tycho.nsa.gov>
	<55BF8E4C.9010706@redhat.com>
Message-ID: <20150827150624.GA31279@x250>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----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-----