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:   Dominick Grift <dominick.grift@defensec.nl>
To:     Russell Coker <russell@coker.com.au>
Cc:     selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] misc kernel and system patches
References: <YAgAyh7eG5zePmGE@xev> <43567489.y7f9mAODUD@liv>
        <ypjllfcekjc5.fsf@defensec.nl> <537253351.ELfjMz7iqO@liv>
Date:   Wed, 27 Jan 2021 12:45:44 +0100
In-Reply-To: <537253351.ELfjMz7iqO@liv> (Russell Coker's message of "Wed, 27
        Jan 2021 19:53:30 +1100")
Message-ID: <ypjlczxqk3h3.fsf@defensec.nl>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Russell Coker <russell@coker.com.au> writes:

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

git also wants execmem and without it some functionality does not work
(although dont ask me what exactly as i dont fully recall, i just know
that the search box in my gitweb didnt work correctly without it and
that is using git under the hood.

But aside , modern wayland compositors also need execmem (gnome,sway
etc). Execmem is just way too common these day's

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

k, well those could be addressed with name-based type transitions

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift