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 668E0C433EF for ; Tue, 3 May 2022 17:10:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238633AbiECROP (ORCPT ); Tue, 3 May 2022 13:14:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240069AbiECROO (ORCPT ); Tue, 3 May 2022 13:14:14 -0400 X-Greylist: delayed 548 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 03 May 2022 10:10:40 PDT Received: from relay.yourmailgateway.de (relay.yourmailgateway.de [188.68.63.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB19D167EF for ; Tue, 3 May 2022 10:10:40 -0700 (PDT) Received: from mors-relay-2502.netcup.net (localhost [127.0.0.1]) by mors-relay-2502.netcup.net (Postfix) with ESMTPS id 4Kt5pL263gz4xRm for ; Tue, 3 May 2022 19:01:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=stefansf.de; s=key2; t=1651597290; bh=yW84b5vPMKL9qglrz9rp/BYuMXDYdM8pb+t3Az9vRpo=; h=Date:From:To:Subject:From; b=HmrXLbdUPwqdR7wx1+TRhj3is6w/xUuA8H5lfmtdmfXpCY7rFR93gJeDDFMlU3moI iCqPGk9xpDS9y9LoWtRxOpGK4kwCFQzgMSuLjl5wtGfFdWd3ngYwjDNVSAnxtMWjfr NXKKmMO0z2rDM906AILKQ/wvMf0UVnxoUutEi4GqIOI/fxmlba3uYC1Wc0BxZpyaYh Pu4RiPYc0fn8kAPZBsh9FCmW2O3EsECQsfafWAqJg3Ex1s21v8wcBGAjnz3Ny9epNC km2nSLomq3uiE1uzBx5TmZl8qJsBTYLg4BeWqJRQ5Nhmh+joMXDxbCzOYDO6hx8co2 QklR4vch4TWeA== Received: from policy02-mors.netcup.net (unknown [46.38.225.53]) by mors-relay-2502.netcup.net (Postfix) with ESMTPS id 4Kt5pL1Wnnz4xQT for ; Tue, 3 May 2022 19:01:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at policy02-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 policy02-mors.netcup.net (Postfix) with ESMTPS id 4Kt5pK3Qwlz8sZX for ; Tue, 3 May 2022 19:01:29 +0200 (CEST) Received: from fedora (unknown [IPv6:2a02:8070:a38b:b00:ba37:b889:521f:a9d7]) by mxe86f.netcup.net (Postfix) with ESMTPSA id 0731E1C0298 for ; Tue, 3 May 2022 19:01:28 +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: Tue, 3 May 2022 19:01:28 +0200 From: Stefan Schulze Frielinghaus To: selinux-refpolicy@vger.kernel.org Subject: Daemons writing into HOME_DIR Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PPP-Message-ID: <165159728923.1635094.10496773597175425879@mxe86f.netcup.net> X-PPP-Vhost: sf-email.de X-NC-CID: fr89WC0f3qw08kXTcq1eCAq/4EqoMqAMBcVz9HLhHej+xg== Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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. 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? 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. 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. Any thoughts? (PS: the daemon cannot be reconfigured in order to write into a different directory than HOME_DIR) Cheers, Stefan