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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E943C433F5 for ; Thu, 5 May 2022 16:52:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232908AbiEEQzz (ORCPT ); Thu, 5 May 2022 12:55:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229636AbiEEQzy (ORCPT ); Thu, 5 May 2022 12:55:54 -0400 X-Greylist: delayed 434 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 05 May 2022 09:52:11 PDT Received: from relay.yourmailgateway.de (relay.yourmailgateway.de [185.244.192.111]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3C9045ACA for ; Thu, 5 May 2022 09:52:11 -0700 (PDT) Received: from relay01-mors.netcup.net (localhost [127.0.0.1]) by relay01-mors.netcup.net (Postfix) with ESMTPS id 4KvKLH089nz7tnY; Thu, 5 May 2022 18:44:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=stefansf.de; s=key2; t=1651769095; bh=K4Oqy30imUYpnABRnHSp8HKPC6F6E8y4lM7mZEEbAiY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gd2GGLFmSh5x68QZdAx36hILOh7yyeEEre09f1CHQNVde6F0G3tvqPJ+Vh68XOMYd N1N69wZZGrlWRkQnQNyR5lL6pcS0kjLKwubc5g81AizITNeLybeyodb/0WK8DmLqiw hHP5p0REHVnPwxZ9DVwlAahJxf8Zq3dETZTRzKvajNqUJBISXI07m1NMLmPr+kOBNh 1gEug4b+XSQU5WTVpOsYrI899pkQurPH/+t9QMJ+bFaZrXyaWjqy6r3rgBMU+XdKCa QhOz88tRoruLSsi+E4QmO1RcvklyJEcGgfL4sqgu1V4KLnD7JOnkg6uT6gYbiy5/jT bWRrhoY3LvS5w== Received: from policy01-mors.netcup.net (unknown [46.38.225.53]) by relay01-mors.netcup.net (Postfix) with ESMTPS id 4KvKLG6tdWz7tk5; Thu, 5 May 2022 18:44:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at policy01-mors.netcup.net Received: from mxe86f.netcup.net (unknown [10.243.12.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by policy01-mors.netcup.net (Postfix) with ESMTPS id 4KvKLG2xVDz8sfy; Thu, 5 May 2022 18:44:54 +0200 (CEST) Received: from fedora (unknown [IPv6:2a02:8070:a38b:b00:ba37:b889:521f:a9d7]) by mxe86f.netcup.net (Postfix) with ESMTPSA id D0C0B1C0369; Thu, 5 May 2022 18:44:53 +0200 (CEST) Authentication-Results: mxe86f; spf=pass (sender IP is 2a02:8070:a38b:b00:ba37:b889:521f:a9d7) smtp.mailfrom=ml@stefansf.de smtp.helo=fedora Received-SPF: pass (mxe86f: connection is authenticated) Date: Thu, 5 May 2022 18:44:53 +0200 From: Stefan Schulze Frielinghaus To: Chris PeBenito Cc: selinux-refpolicy@vger.kernel.org Subject: Re: Daemons writing into HOME_DIR Message-ID: References: <804d8b8d-394a-5070-c773-b074fe5b6a5d@ieee.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <804d8b8d-394a-5070-c773-b074fe5b6a5d@ieee.org> X-PPP-Message-ID: <165176909413.3103804.10072989156432289423@mxe86f.netcup.net> X-PPP-Vhost: sf-email.de X-NC-CID: rI62DBXpFX/MYESeOxmx5//15N5ASwj3oWhOzLpTZJv6yw== Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On Tue, May 03, 2022 at 02:19:17PM -0400, Chris PeBenito wrote: > On 5/3/22 13:01, Stefan Schulze Frielinghaus wrote: > > Hi all, > > > > In short I'm wondering what the refpolicy way is to let a daemon write into > > HOME_DIR and how those files---especially the SELinux user part---should be > > labeled? > > > > Currently I have a daemon (systemd service) running under context > > > > system_u:system_r:foobar_t:s0 > > > > and the policy contains > > > > init_daemon_domain(foobar_t, foobar_exec_t) > > > > The daemon reads and writes files under HOME_DIR/foobar which are labeled as > > foobar_rw_t and the policy has the following file context entry: > > > > HOME_DIR/foobar(/.*)? gen_context(system_u:object_r:foobar_rw_t,s0) > > > > However, newly created files still seem to have a wrong user according to > > restorecon (the daemon runs under Linux user marge which is assigned to SELinux > > user user_u): > > > > $ restorecon -FRvn /home/marge/foobar > > Would relabel /home/marge/foobar/baz from system_u:object_r:foobar_rw_t:s0 to user_u:object_r:foobar_rw_t:s0 > > > > It looks like as if user_u wins over system_u for files under HOME_DIR. This > > does not have any effect on the functionality of the daemon, however, it still > > feels wrong to me. > > This is genhomedircon setting the seuser of the files to match the seuser > mapping in `semanage login`. You want this behavior, especially if you have > UBAC turned on, otherwise UBAC doesn't provide a benefit, since system_u is > excluded from UBAC. > > > > So I'm wondering how to fix this and thought about: > > > > 1) Can/Should a daemon run under a different SELinux user than system_u? > > If this is a system daemon, e.g. started by systemd (pid 1) then that is not > expected in refpolicy, not generally suggested. If this is a daemon running > out of a user session, such as systemd --user, then yes, it should have the > user's seuser, e.g. user_u. > > > > 2) Another option, which I think is worse, would be to the change the SELinux > > user from user_u to system_u for Linux user marge under which the daemon runs. > > Running an interactive user as system_u is contrary to system_u's purpose, > which is for non-interactive system processes only. Good point. User marge is actually a non-interactive user and the whole purpose of it is to run the daemon via systemd (pid 1) only. I was afraid to associate system_u to marge due to "Administrators must never associate this system_u user and the system_r role to a Linux user" [1]. Though, maybe that statement referred to interactive users only, i.e., it is acceptable to associate system_u to non-interactive users? Cheers, Stefan > > > 3) A third option would be to keep the users as is, i.e., let the daemon run > > under system_u and let marge be assigned to user_u, but tweak the policy to keep > > the file context labels under HOME_DIR with system_u. > > See my first comment. > > > Any thoughts? > > You could change the default_user[1] so the seuser comes from the parent > directory, but that would change it for the entire system which may have > unintended and worse consequences. > > You're seeing the behavior I expect to see for this type of policy design. > > > [1] https://github.com/SELinuxProject/selinux-notebook/blob/main/src/default_rules.md#default_user > > -- > Chris PeBenito [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/managing-confined-and-unconfined-users_using-selinux