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=-5.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS 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 F3151C33CAB for ; Mon, 13 Jan 2020 09:42:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CAEDB2075B for ; Mon, 13 Jan 2020 09:42:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H6SVHC2H" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725978AbgAMJmT (ORCPT ); Mon, 13 Jan 2020 04:42:19 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:37985 "EHLO mail-wr1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728682AbgAMJmR (ORCPT ); Mon, 13 Jan 2020 04:42:17 -0500 Received: by mail-wr1-f48.google.com with SMTP id y17so7800081wrh.5 for ; Mon, 13 Jan 2020 01:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MBndXHjfy1VOW673oLYSIN5wC8hF6G/aLltiA3AMMDA=; b=H6SVHC2HC2g6gi8YHubrSdMSucij7VRN/H+7WXpI2ycR0TZ/54/jeR+fxp4L1aguLr 8I0F7TpiAgam4sHoPjWy4hMYlFMyA9dd17GvL0ZAK8Unig1OsrT+QevgREUW9zrugPj8 NjKiQEImOAs2SoEx3Fmc9LF3wxtBfpKZPKikXyto9/Y8sRg1AiGG10Zoil9hLe9+IdWL y26nL93cDyuj5qEuk6ISsNFbMM1R1EYdNLz3fo8MCtwbI9YbQnGLL6vHk3va61OAUuJL OlxVODpdV9b3EH6aBMrW3WsYaiuAwoqF3AzPyARSUiTQ02Fk0Ba7xExQAOU4YDrebWBm yvyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MBndXHjfy1VOW673oLYSIN5wC8hF6G/aLltiA3AMMDA=; b=Z+i6LSesuWl5CrfhlG210ngfQszDZUIl4Ck7Q7abVwVvrIoGQqu2NzJmKQQLc/k5rB 2olBXfB8skO2fuGnInuJAvt+GHpDfaZHmMN6zb8L3JclIVplhBJQ0S48VUtb+PewRQVC AMIQmVv6P+Txj8eRy26azSTPeNq14mSeYYkDYxbA4PK4ca8yykZ8L2L1LEdLGcMmp63s +ztXd2T5StCcWD4doVgMHJVXSBNm5epAWdDdELEIpmacSLjw4B6pJfbvUTtxxmaUCmK4 SFb1/cjLaCb/MZgpLHTc1I8qAuM0Sd/NNiPL+R6e9gncsoaYwoyUmFM7i0CMwPu+dtRd eEHw== X-Gm-Message-State: APjAAAXZNdXYjvjAu26Time98XYp1jYUVwSgZvPMKyiKJ3I7JCb+NksO vguM482O1WDEt0bICu0AgozlPuq1 X-Google-Smtp-Source: APXvYqzQLonPhE+/xtgN2JH8zCNrL5LfDe3SMO0nnalxXBeeuMOdRHWUyYcXwB2dihoCZLIeGTpvpg== X-Received: by 2002:a5d:5592:: with SMTP id i18mr16410637wrv.55.1578908534491; Mon, 13 Jan 2020 01:42:14 -0800 (PST) Received: from brutus.lan (brutus.defensec.nl. [2001:985:d55d::438]) by smtp.gmail.com with ESMTPSA id u24sm13829801wml.10.2020.01.13.01.42.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2020 01:42:13 -0800 (PST) Date: Mon, 13 Jan 2020 10:42:10 +0100 From: Dominick Grift To: Chris PeBenito , refpolicy Subject: Re: [RFC] refining systemd mountpoints Message-ID: <20200113094210.GB870816@brutus.lan> Mail-Followup-To: Chris PeBenito , refpolicy References: <3418ebca-80c0-b10e-c0a2-a80427fdbf71@ieee.org> <20200109214240.GA2283901@brutus.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <20200109214240.GA2283901@brutus.lan> User-Agent: Every email client sucks, this one just sucks less. X-PGP-Key: https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 09, 2020 at 10:42:40PM +0100, Dominick Grift wrote: > On Thu, Jan 09, 2020 at 04:06:38PM -0500, Chris PeBenito wrote: > > I'd like to refine how the policy handles systemd's mounton so that it = works > > similar to how we manage mountpoints for mount_t. Since systemd can be = made > > to mount over just about anything, I'm looking at adding a new conditio= nal > > that would allow init_t to mounton non_security_file_type, and then an > > interface like files_mountpoint(). > >=20 > > The question is for the implementation of the interface; I see two opti= ons, > > either the interface allows mounton for all file-like classes, or the > > classes are specified as a parameter: > >=20 > > -------- > > init.te: > > attribute init_mountpoint_type; > > allow init_t init_mountpoint_type:dir_file_class_set mounton; > >=20 > > init.if: > > interface(`init_mountpoint',` > > typeattribute $1 init_mountpoint_type; > > ') > > -------- > >=20 > > or > >=20 > > -------- > > init.if: > > interface(`init_mountpoint',` > > allow init_t $1:$2 mounton; > > ') > > -------- > >=20 > > I like the first option because it is clearer since you can see the mou= nton > > in init.te, but that is excessive access. The second option could be m= ade > > to look like the first option, but it would need several attributes and > > interfaces, e.g. init_dir_mountpoint_type, init_file_mountpoint_type, e= tc. > > which isn't so desirable. > >=20 > > Any thoughts on this? >=20 > I implemented the former in my policy. ie the dir_file_class_set equiv.. >=20 > 4163 (allow subj bind_path_obj_type_attribute (dirs (create= ))) > 4164 (allow subj bind_path_obj_type_attribute list_dir_perm= s) > 4165 (allow subj bind_path_obj_type_attribute (dir (mounton= ))) > 4166 (allow subj bind_path_obj_type_attribute create_file_p= erms) > 4167 (allow subj bind_path_obj_type_attribute (file (mounto= n))) >=20 > As you can see i even allow systemd to create the mountpoint in case it d= oes not exist. For example if /etc/machine-id does not exist and I have a B= indReadOnlyPath=3D/etc/machine-id then systemd will touch /etc/machine-id a= nd mount it ro Okay, I think I am wrong. It will not create the bind_path if it does not e= xist. Not sure how I got to this... >=20 > It also generally buggy. Systemd does not (alway's) use setfscreatecon to= create the mountpoints. And sometimes it does use setfscreatecon where it = shouldnt. >=20 > https://github.com/systemd/systemd/issues/13762 >=20 > >=20 > > --=20 > > Chris PeBenito >=20 > --=20 > Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 > Dominick Grift --=20 Key fingerprint =3D 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0x3B6C5F1D2C7B6B02 Dominick Grift --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAl4cO24ACgkQJXSOVTf5 R2lQPQv+Lm+gWYyC2UvBRF9jaqvVtGDOPgEi8zn3fsxiXpzcGQ5JMP5pNrVxzVM0 Y4yrrYQpXqYM1E+BgFhi1W2rell7JOgFLDj1PTIzJvIBUtD1D07GXOrAgXLlYPc0 CsLKtEOaKiYvu5c8mCp7fRgFkyT926GqVPajQSnDynPd6GwiRxtmq6oOz9XfMYTl Emri3XVfigOPPqC4LpmGOzQUHKOsvPTgKCfjNbpACy38r1rhpO3PKM45vkuE6WbR ONahUJeO+FGJsSt7k4VOxC3jlvuovQ1EKtNTkCbZVl+K0J7p6Y9HfHCgK39fJNee 5+uwwvmbRLtSGVhtNYDlFIVpJL+RlMCSZrmjpkr7pailVwYl9WUEPBaIFVMS+x+B ne/CuUYewiOarjcnKFzF9PTxhotwMhf1sdrTqM7CmeTAONEhgOGPOxPRx5kZkxDk oISjFqXZEqpQg5k/43fVT20UVMKR3d3Rb9bJ4kpfbDoW6iyb40yJ8s9vaSxiAmeV cVo+yWTC =6Y+O -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ--