Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Russell Coker <russell@coker.com.au>
To:     Dominick Grift <dominick.grift@defensec.nl>
Cc:     selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] misc kernel and system patches
Date:   Wed, 27 Jan 2021 19:53:30 +1100
Message-ID: <537253351.ELfjMz7iqO@liv>
In-Reply-To: <ypjllfcekjc5.fsf@defensec.nl>
References: <YAgAyh7eG5zePmGE@xev> <43567489.y7f9mAODUD@liv> <ypjllfcekjc5.fsf@defensec.nl>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

On Wednesday, 27 January 2021 5:03:06 PM AEDT Dominick Grift wrote:
> >> > @@ -1264,6 +1299,8 @@ allow systemd_tmpfiles_t systemd_journal
> >> > 
> >> >  allow systemd_tmpfiles_t systemd_tmpfiles_conf_t:dir list_dir_perms;
> >> >  allow systemd_tmpfiles_t systemd_tmpfiles_conf_type:file
> >> >  read_file_perms;
> >> > 
> >> > +allow systemd_tmpfiles_t systemd_nspawn_runtime_t:fifo_file unlink;
> >> 
> >> questionable
> > 
> > Why?
> 
> Not sure yet. other than that is looks incomplete and that i am
> wondering why one would be bothering with this.
> 
> Can you tell me a bit more about this event?

It's just a fifo that systemd-nspawn left lying around and tmpfiles cleaned 
up.  My way of not bothering is to just allow it.  It doesn't seem to do any 
harm.

> >> unconfined should be unconfined.
> > 
> > certbot needs execmem, we generally don't want to give that to unconfined,
> > so running certbot in a different domain seems better.
> 
> Those day's are long gone. Nowaday's even `grep` does execmem.

grep asks for execmem but seems to work fine without it.  certbot won't 
function without it.

> >> But in my personal view unconfined_t shouldnt run lvm with a domain
> >> transition in the first place (defeats the purpose of the unconfined
> >> domain)> 
> > I think the problem is the type transition rules.  Run lvm etc as
> > unconfined_t and then lvm run from init etc won't be able to access it's
> > temporary files etc.
> 
> why would lvm run for init have any busyness with temporary files? Seems
> unlikely to me and nowaday's we have a lot more flexibility with
> type-trans rules. But yes, its a bit late in the game now to change
> this. It breaks the model though IMHO.

type_transition lvm_t device_t:blk_file fixed_disk_device_t;
type_transition lvm_t etc_t:file lvm_metadata_t;

Here's a couple of the type_transition rules in the current policy that 
indicate problems if you removed the transition to lvm_t.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/