From: pebenito@ieee.org (Chris PeBenito)
Date: Sat, 4 Mar 2017 07:29:07 -0500
Subject: [refpolicy] [PATCH] systemd-nspawn
In-Reply-To: <20170304122634.GA3913@t450.enp8s0.d30>
References: <20170228110557.ck7x4ligazrhdnrx@athena.coker.com.au>
	<201703010112.08588.russell@coker.com.au>
	<0ae32e3a-4447-62fc-736a-19e5db03ff44@ieee.org>
	<20170304122634.GA3913@t450.enp8s0.d30>
Message-ID: <44624a8d-de0f-8654-9385-247baabbc938@ieee.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 03/04/17 07:26, Dominick Grift via refpolicy wrote:
> On Sat, Mar 04, 2017 at 07:16:41AM -0500, Chris PeBenito via refpolicy wrote:
>> On 02/28/17 09:12, Russell Coker via refpolicy wrote:
>>> On Tue, 28 Feb 2017 10:05:57 PM Russell Coker via refpolicy wrote:
>>>> Index: refpolicy-2.20170227/policy/modules/system/logging.fc
>>>>
>>> ===================================================================
>>>> --- refpolicy-2.20170227.orig/policy/modules/system/logging.fc
>>>> +++ refpolicy-2.20170227/policy/modules/system/logging.fc
>>>> @@ -64,7 +64,6 @@ ifdef(`distro_redhat',`
>>>>  /run/klogd\.pid        --      gen_context(system_u:object_r:klogd_var_run
>>>> _t,s0)
>>>> /run/log               -s      gen_context(system_u:object_r:devlog_t,s0)
>>>> /run/log               -d      gen_context(system_u:object_r:var_log_t,s0-
>>>> mls_systemhigh)
>>>> -/run/log/journal(/.*)? gen_context(system_u:object_r:var_log_t,mls_system
>>>> high)
>>>> /run/metalog\.pid      --      gen_context(system_u:object_r:syslogd_var_r
>>>> un_t,s0)
>>>> /run/rsyslogd\.pid     --      gen_context(system_u:object_r:syslogd_var_r
>>>> un_t,mls_systemhigh)
>>>> /run/syslogd\.pid      --      gen_context(system_u:object_r:syslogd_var_r
>>>> un_t,mls_systemhigh)
>>>
>>> This doesn't really belong in the nspawn patch.  The reason it's in is nspawn
>>> was left after I split everything else into different patches.
>>>
>>> It's not a mistake, that labelling of /run/log/journal breaks systemd-journald
>>> and needs to be removed.  When it's removed the entry for /var/run/log/journal
>>> takes over and gives the desired result.  I don't know why /run/log/journal
>>> gets priority on my system.
>>>
>>> We need to fix this /run vs /var/run thing.  We need one canonical name and we
>>> need to change everything to it.  Chris, you want me to write a patch to
>>> change everything to /run?
>
> That might cause issues. SELinux aware programs will use matchpathcon similar functionality to look up the context of the to be created files
> They will end up thinking that file needs to be labeled var_t because they still look up using the /var/run path
>
> This is an issue with many tmpfiles snippets but not only that, package managers might fail for the same reason:
>
> /run/netreport:
>
> avc:  denied  { associate } for  pid=13859 comm="dnf" name="netreport" dev="tmpfs" ino=20423 scontext=sys.id:sys.role:files.generic_var.var_file:s0 tcontext=sys.id:sys.role:fs.tmpfs.fs:s0 tclass=filesystem permissive=0
>
> /run/screen:
>
> avc:  denied  { associate } for  pid=13859 comm="dnf" name="screen" dev="tmpfs" ino=20864 scontext=sys.id:sys.role:files.generic_var.var_file:s0 tcontext=sys.id:sys.role:fs.tmpfs.fs:s0 tclass=filesystem permissive=0
>
> Even if var_t would be allowed to associated with xattrfs fs, the files would still end up mislabeled: var_t

I don't follow what the issue would be.  If everything points to /run 
and there is a /var/run -> /run substitution, I would think it would 
work fine.


-- 
Chris PeBenito