Received-SPF: pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
To:     refpolicy <selinux-refpolicy@vger.kernel.org>
From:   Chris PeBenito <pebenito@ieee.org>
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

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