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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 C595CC282DD for ; Thu, 9 Jan 2020 21:06:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 875FF206ED for ; Thu, 9 Jan 2020 21:06:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org header.b="Zzz5ugtO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725840AbgAIVGk (ORCPT ); Thu, 9 Jan 2020 16:06:40 -0500 Received: from mail-qt1-f172.google.com ([209.85.160.172]:45043 "EHLO mail-qt1-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbgAIVGk (ORCPT ); Thu, 9 Jan 2020 16:06:40 -0500 Received: by mail-qt1-f172.google.com with SMTP id t3so16930qtr.11 for ; Thu, 09 Jan 2020 13:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=j9U+M/GDrwVZGiSjFoPAPPm3e9bGkMcXWu2xFZLrCyE=; b=Zzz5ugtO19yXhb5EZ4bNJ6aTL2gGqs2DGQuss7QtzAJn9QZGZlNG66YbJ020bWHL1H p3H7TfBYZQmJkE06CTZlBtZJ67zRWic3SuqwASTCWnzbLAdXfHSSk3GrjascDhMmwl71 JJBbFuL59jgDPkkSdUg70Mpov7vJWLxqTQefs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=j9U+M/GDrwVZGiSjFoPAPPm3e9bGkMcXWu2xFZLrCyE=; b=Q2lXqTkljMmFkn9kBsTd4l/gT/JYQFWa9zhZs375XXNcvjjXkOo7dUdErg757QCDzt 4O4CnuH/fM6GvhFAbA/HVPXA+zsgsiLzJZXK07L0t8q3XeLJDgQ/dDp8Yd/UXfMl4qio nEndnEu04MW2Nnt6jvNA1FCP+d3xUwe+Mzuxz00oMuCxrNDWBFr0dbfgGdR9gEIFGbL8 qytyKg/l5xtOzekPvHun3CKx3Hev9WjvIVkJOtTs+ugguVzS7/NhMZLPac0+TAnuqPZU 7LHqYkVKSaE9pZ+ilFT+fD9xhMMLckCmoEKBbMCwsX7O5kiQ3vlxjGccb0HLzqgjXTAf zIOA== X-Gm-Message-State: APjAAAWJQAjKY9KfurPuygTeFcCUD5ZpB1xZLWMB4jlpfxJcpbEcRFXU IUjEiaJM/iQBv8CjEOs70LqgjA2hIMhMMQ== X-Google-Smtp-Source: APXvYqwRVNwpwo6PuMT8jCa1Dps80rE1EYrkmW9WsejI++qlpp2syD4yU+C5cJ4EnIV5FlOkFhqAjA== X-Received: by 2002:ac8:5243:: with SMTP id y3mr9716501qtn.79.1578603999046; Thu, 09 Jan 2020 13:06:39 -0800 (PST) Received: from fedora.pebenito.net (pool-108-15-23-247.bltmmd.fios.verizon.net. [108.15.23.247]) by smtp.gmail.com with ESMTPSA id v5sm4057446qtc.64.2020.01.09.13.06.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jan 2020 13:06:38 -0800 (PST) To: refpolicy From: Chris PeBenito Subject: [RFC] refining systemd mountpoints Message-ID: <3418ebca-80c0-b10e-c0a2-a80427fdbf71@ieee.org> Date: Thu, 9 Jan 2020 16:06:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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 conditional that would allow init_t to mounton non_security_file_type, and then an interface like files_mountpoint(). The question is for the implementation of the interface; I see two options, either the interface allows mounton for all file-like classes, or the classes are specified as a parameter: -------- init.te: attribute init_mountpoint_type; allow init_t init_mountpoint_type:dir_file_class_set mounton; init.if: interface(`init_mountpoint',` typeattribute $1 init_mountpoint_type; ') -------- or -------- init.if: interface(`init_mountpoint',` allow init_t $1:$2 mounton; ') -------- I like the first option because it is clearer since you can see the mounton in init.te, but that is excessive access. The second option could be made to look like the first option, but it would need several attributes and interfaces, e.g. init_dir_mountpoint_type, init_file_mountpoint_type, etc. which isn't so desirable. Any thoughts on this? -- Chris PeBenito