Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp22498iob; Tue, 3 May 2022 10:48:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEZnmR0PcZbCxzeK1mRIAL41jJ52jo13izrjX9d+ec5YkEhEHJNWNOVBASeLMegrNRHEwS X-Received: by 2002:a63:444f:0:b0:39d:3aa5:c9f0 with SMTP id t15-20020a63444f000000b0039d3aa5c9f0mr14780265pgk.363.1651600110695; Tue, 03 May 2022 10:48:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651600110; cv=none; d=google.com; s=arc-20160816; b=U9Baw1nRH/C7ciZdB7mZuW7AeMoqVWEPpnNInqsqsT4knPs4VHRqG36JytQ9AKHk2f KjK2/w5cuuHP2ErmXcvQGwtbN8swAq79IUbR3WzzSoFEZ8K5Z5fzP/9r+MQpVLTQLzT3 FzdtfjO8bnfadMdPbcckYvMjveT55Rn8XVrUuXk3xTcDntpn9sZIzQCa14Wl6cB5Pyz5 G9oBcjiI6gmZ+X/bAsEW5BuJvn5Fhh5Ntd2lldAij7L2td9ahYNQbCp9OYdlYas539Kk TIaKO7QKwOgDo74SolEARIPvDjjwIWN2+049k9TuOfYByNixHoo+8J4noxe2jwhZRb69 nMBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:to:from:date:dkim-signature; bh=yfmp+rzDhfjFRS/4PKcRruQsTAaQUTtgyHRHUm0n4dE=; b=nAHuHs2yOLrN7UW3gmq3dIrpelZot2378j42LovVUvph2impv5pdNm0pCrLQJ1J6fW RwM2VW5WCoyZfrgtZ9L0KVGKix9FTFrYDnL+ul/aX/Uj/Ki8u0LR8PvMX39xeW1G2eX9 5HeLLLtVYxDfoPPJHMtBDZqM5MJHnvchCWmdZBblqVHC8BJK9+SC92cTPuYgc2qERazt PbUpsDgJY8JdXt/Agp89EsC5XajhIwt6pfsJglekkf1vAsaDE5hbWAqJQ+pd96xw9rqU M6Q3FKG4LwEGHd4M9a+kahkcKH3+KFkXd/mIiSRCzezbEt7ZgHQ3C8HQ+76k2NpcBhZH +nQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@stefansf.de header.s=key2 header.b=HmrXLbdU; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l12-20020a170903244c00b0015cf9502127si3703380pls.267.2022.05.03.10.48.01; Tue, 03 May 2022 10:48:30 -0700 (PDT) Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@stefansf.de header.s=key2 header.b=HmrXLbdU; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238633AbiECROP (ORCPT + 22 others); 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 X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 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== X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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