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
Date: Wed, 27 Jan 2021 12:45:44 +0100 [thread overview]
Message-ID: <ypjlczxqk3h3.fsf@defensec.nl> (raw)
In-Reply-To: <537253351.ELfjMz7iqO@liv> (Russell Coker's message of "Wed, 27 Jan 2021 19:53:30 +1100")
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
prev parent reply other threads:[~2021-01-27 11:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 10:07 [PATCH] misc kernel and system patches Russell Coker
2021-01-20 14:36 ` Dominick Grift
2021-01-27 4:05 ` Russell Coker
2021-01-27 6:03 ` Dominick Grift
2021-01-27 8:53 ` Russell Coker
2021-01-27 11:45 ` Dominick Grift [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ypjlczxqk3h3.fsf@defensec.nl \
--to=dominick.grift@defensec.nl \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).