Re: [RFC] refining systemd mountpoints

Dominick Grift <[email protected]>
Newsgroups org.kernel.vger.selinux-refpolicy
Message-ID <[email protected]>
On Mon, Jan 13, 2020 at 10:42:10AM +0100, Dominick Grift wrote:
> 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 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;
> > > ')

To be clear: I like this option:

1. You can BindPath/BindReadOnlyPath/BindReadWritePath/InaccessiblePath *any* file in theory. So dir_file_class_set seems appropriate.
2. You might wat to extend it just a little though:

allow init_t init_mountpoint_type:dir_file_class_set { getattr mounton };
allow init_t init_mountpoint_type:dir search_dir_perms;


> > > --------
> > > 
> > > 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?
> > 
> > I implemented the former in my policy. ie the dir_file_class_set equiv..
> > 
> > 4163               (allow subj bind_path_obj_type_attribute (dirs (create)))
> > 4164               (allow subj bind_path_obj_type_attribute list_dir_perms)
> > 4165               (allow subj bind_path_obj_type_attribute (dir (mounton)))
> > 4166               (allow subj bind_path_obj_type_attribute create_file_perms)
> > 4167               (allow subj bind_path_obj_type_attribute (file (mounton)))
> > 
> > As you can see i even allow systemd to create the mountpoint in case it does not exist. For example if /etc/machine-id does not exist and I have a BindReadOnlyPath=/etc/machine-id then systemd will touch /etc/machine-id and mount it ro
> 
> 
> Okay, I think I am wrong. It will not create the bind_path if it does not exist. Not sure how I got to this...
> 
> > 
> > It also generally buggy. Systemd does not (alway's) use setfscreatecon to create the mountpoints. And sometimes it does use setfscreatecon where it shouldnt.
> > 
> > https://github.com/systemd/systemd/issues/13762
> > 
> > > 
> > > -- 
> > > Chris PeBenito
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc (application/pgp-signature, 659 B)
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEEujmXliIBLFTc2Y4AJXSOVTf5R2kFAl4cQ+wACgkQJXSOVTf5
R2nf9Av7BGpQC8WaegcnLzZYxWt4hoUMQkU/7pl18dw+saYVfEA+rZa6u775HGu3
9fAg7/gO+KvLf0i3UFNEUW6RMqLsDP30AO7+KczddWHAk430mo4W7M5MUaLXXzNT
koA+BZd3YLogvBVgR/4tQXGqhLt3vusImJr+59cHX/45ngwdrIUqNuDIGQyghNtX
e7OkVFVuIxp+5r5ouH1xaFJdLKwab8wJSdxlITM6x6NhFPtfFQLMILInCcwk2jQm
EyTe0UnhRTs9/NhrDb0OfZKg8YJyc9UwLavH+JE8209CkI/R4FOdRlS+ThfmgYfn
GzFzaEc7nmB91WoaGTpfw43BoifywxRtYo+1KPrjEKNrGNugG54bFbLGOhre+p/H
2BktD0UoPWmzGMfVUFqxxLrLOY5txCBv2brxkdJ4jkFOD7tMSqDAm1mmaaTyX220
FJOYr1yEyzZqiqtz9k4FBXFxC0YxJH3rnBTraa+yMITb7TMc+9XDOw8oGoF2NzR5
VH3qU0/Q
=Jkyy
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.