Re: [PATCH] misc kernel and system patches

Russell Coker <[email protected]> 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 [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift