From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 581F7C433E0 for ; Wed, 27 Jan 2021 11:49:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1419A207B6 for ; Wed, 27 Jan 2021 11:49:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234612AbhA0Ls6 (ORCPT ); Wed, 27 Jan 2021 06:48:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237150AbhA0Lq3 (ORCPT ); Wed, 27 Jan 2021 06:46:29 -0500 Received: from agnus.defensec.nl (agnus.defensec.nl [IPv6:2001:985:d55d::711]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C5429C06174A for ; Wed, 27 Jan 2021 03:45:48 -0800 (PST) Received: from brutus (brutus.lan [IPv6:2001:985:d55d::438]) by agnus.defensec.nl (Postfix) with ESMTPSA id 99CFF2A1250; Wed, 27 Jan 2021 12:45:46 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 agnus.defensec.nl 99CFF2A1250 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defensec.nl; s=default; t=1611747947; bh=6tz0ZjJFSQBajx0BfSemo0giVpV9h4IGq7awraXVYS0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=UstvruDp4q7lU+9/xeJ8Q/TgC0dXgMqVXffWFoZ1U22cFMUozfpOFd/z6osTX2Lzx BMs8LMCB0QgKzj4mwCHQBp/tySyBUAExGRH93CPRPxTiFM+5ITVKE/JSjbAAoWqlJ4 tDRQbnAZJlRSQN0ZEUCbqn8Uf9lGU9L0FDqbsOV0= From: Dominick Grift To: Russell Coker Cc: selinux-refpolicy@vger.kernel.org Subject: Re: [PATCH] misc kernel and system patches References: <43567489.y7f9mAODUD@liv> <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: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org Russell Coker 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