From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=45.80.168.93 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792489620; b=xDZS5mgMLGAEziWJi/DrJAd6JPqxGoKMfkOIijCq7tymSqXxDRqLAI4Oo8Vsh2nfL0Q3 RTao3yXmaZY/JWKLXSbAe5gi7UBvKAqVjijeTcU21zU8Mz743gsY6fZA8wBVVZFHNPoWU Nh1BYvCYc3IVaKBkT/qEa4X4FgaFKFQ4byfRzmUx2UeeTfrzXKZolX1uL0Xfm+ZL8KGP5 wp4peW7ykbyE+ASbtBzcoBTCpnyWkao+pYVk1uUkEvgRD/LQBcT6Ng6hEUFUSYo9oRB3D JZCYKa5UqTahJ2xqQ9eE+WLeVVWW7pCN9qzXSC6iAKdfI4KT7nVyPOFiJCQO4G4VFOQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792489620; h=DMARC-Filter:DKIM-Signature:Received:From:To:Cc:Subject:In-Reply-To: References:Date:Message-ID:User-Agent:MIME-Version:Content-Type; bh=vrG9e8GY5p5TJe8lf0XkUTzduG73VGG39xeMhxCma7g=; b=OEjfrzOTh/JoG51BPGiErqH4dOXsCYOyDPvkJ8EJAal7bFgmzYDeQ7E+ZySP3UtRjZhq Lb3LVE3FRVqEV9LwVKiMJys48zAvwlcNPhZqutVWxq8TdaKIfZXUmFybuHN/dvJiK8Luz KbunglRB8BaBIITgsNypl4j6vq+MuK0ZrCaqrtg9jiFX7colbqi4qZdNlN/egCLnDpf// 8SdnochCVsv196L2gpHbPJAgA+ntfRjaO4GkgawhD0rS6HsoqZpVMcwpHTc7A5x1+o16w zmy4lrGkvkxSScQAwYhMMzQZBttsP1fsbSr231gcN4EPPd4c6359H9066ifurC4om0Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=defensec.nl; spf=pass smtp.mailfrom=defensec.nl; dkim=pass header.d=defensec.nl header.i=@defensec.nl header.a=rsa-sha256 header.s=default header.b=Xg2MZeGh; arc=none smtp.remote-ip=45.80.168.93 Received: from markus.defensec.nl (markus.defensec.nl [45.80.168.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7BC0606A319 for ; Tue, 20 Oct 2026 09:46:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B7BC0606A319 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=defensec.nl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=defensec.nl header.i=@defensec.nl header.a=rsa-sha256 header.s=default header.b=Xg2MZeGh DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=defensec.nl; s=default; t=1792489611; bh=52oHUbmZtFMqTV8rYQDO05gyTpHTbS4msI9kt1G6CQY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Xg2MZeGhXWY2+XjsCZB5kjs76FCKnFd1pD/yqwudlO2na+42rYLsKCMhnb0xHEEGo tOuveetuDoYKdkWuabNXrhk04K+/9GpLRtntbdJFMzKBXa2cstUyMg9juMGPpzTIdA vdBkRLqEp/8tW6mmO1MFBLyWVMVBod1tC7QBN6CY= Received: from nimbus (nimbus.defensec.nl [IPv6:2a10:3781:2099::514]) by markus.defensec.nl (Postfix) with ESMTPSA id 3928C2FC0E8; Tue, 20 Oct 2026 11:46:51 +0200 (CEST) From: Dominick Grift To: Russell Coker Cc: selinux-refpolicy@vger.kernel.org Subject: Re: systemd and rebooting In-Reply-To: (Russell Coker's message of "Mon, 19 Oct 2026 09:56:51 +1100") References: Date: Tue, 20 Oct 2026 11:46:50 +0200 Message-ID: <87qzhk66wl.fsf@defensec.nl> User-Agent: Gnus/5.13 (Gnus v5.13) X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain Russell Coker writes: > Currently there are no SE Linux access controls for reboot/halt/suspend/etc > running in a typical systemd configuration. So any process that can talk to > the dbus system bus can reboot without SE Linux access controls. > > The problem is that reboot/halt type operations can be initiated through dbus > connections to either init or systemd-logind and the latter has no SE Linux > code. > > https://github.com/systemd/systemd/issues/34878 > > The above URL has a systemd bug report. > > allow sysadm_t systemd_logind_t:system { halt reboot }; > > The attached patch addresses this. It's not a candidate for inclusion in > systemd upstream as it has duplicated code for SE Linux access checks but it > works and would be a starting point for someone who knows systemd better than > SE Linux. The attached patch needs policy like the above. > > It would be possible to write a patch that checks access against the context > of pid 1 but I went for the most direct solution to the problem for at least > the first draft. > > https://github.com/systemd/systemd/issues?q=is%3Aissue+state%3Aopen+selinux > > As an aside there's more than a few SE Linux related bugs reported against > systemd if someone has experience with systemd hacking and interest in SE > Linux. I would be happy to help with the SE Linux side of testing such > things. I am not sure about this but I wanted to note: https://github.com/systemd/systemd/pulls?q=is%3Apr+state%3Aopen+label%3Aselinux There are various entries there that are stuck. Two notable ones: https://github.com/systemd/systemd/pull/20387 https://github.com/systemd/systemd/pull/10023 -- gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@defensec.nl