File access macros

File access macros

[Ian Pilcher]

I'm writing a policy module to allow containerized and non-containerized
services to share content.  (Basically to give container_t access to
public_content_t and/or public_content_rw_t.)

I don't normally make much use of SELinux policy macros, as the
documentation seems to be rather difficult to find, scattered, and
sometimes conflicting; instead I usually just use the denials generated
by the program that I'm confining to determine exactly what access it
needs.

In this case, however, I'm trying to do something much more generic.
I don't really know exactly what permissions a given containerized
service might need, so I'm looking for a good, standard set of read-only
and read/write permissions for files, directories, and symbolic links.

It sure seems like this must be a solved problem.  I.e. there must be
something like this macro, which Google Gemini so helpfully
hallucinated.

     fs_read_access(<domain_type>, <file_type>);

Thus far, I've been completely unable to find anything like this.

Am I wrong that macros like this exist?

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================

Re: File access macros

[Dominick Grift]

Ian Pilcher <arequipeno@gmail.com> writes:

> I'm writing a policy module to allow containerized and non-containerized
> services to share content.  (Basically to give container_t access to
> public_content_t and/or public_content_rw_t.)
>
> I don't normally make much use of SELinux policy macros, as the
> documentation seems to be rather difficult to find, scattered, and
> sometimes conflicting; instead I usually just use the denials generated
> by the program that I'm confining to determine exactly what access it
> needs.
>
> In this case, however, I'm trying to do something much more generic.
> I don't really know exactly what permissions a given containerized
> service might need, so I'm looking for a good, standard set of read-only
> and read/write permissions for files, directories, and symbolic links.
>
> It sure seems like this must be a solved problem.  I.e. there must be
> something like this macro, which Google Gemini so helpfully
> hallucinated.
>
>     fs_read_access(<domain_type>, <file_type>);
>
> Thus far, I've been completely unable to find anything like this.
>
> Am I wrong that macros like this exist?

I can give you an example of how the public content feature might be
implemented with an example. the refpolicy ftp module:

There are two scenario's there:

1. by default ftpd_t can read(only) public_content_t and public_content_rw_t
dirs, files and symlinks:

https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L251

This interface is defined here:

https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/system/miscfiles.if#L915

2. write access to public_content_rw_t is conditional in this
example (with a boolean):

https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L16
https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L260

This interface is defined here:

https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/system/miscfiles.if#L937

-- 
gpg --locate-keys dominick.grift@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: File access macros

[Stephen Smalley]

On Sun, Sep 14, 2025 at 1:33 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Ian Pilcher <arequipeno@gmail.com> writes:
>
> > I'm writing a policy module to allow containerized and non-containerized
> > services to share content.  (Basically to give container_t access to
> > public_content_t and/or public_content_rw_t.)
> >
> > I don't normally make much use of SELinux policy macros, as the
> > documentation seems to be rather difficult to find, scattered, and
> > sometimes conflicting; instead I usually just use the denials generated
> > by the program that I'm confining to determine exactly what access it
> > needs.
> >
> > In this case, however, I'm trying to do something much more generic.
> > I don't really know exactly what permissions a given containerized
> > service might need, so I'm looking for a good, standard set of read-only
> > and read/write permissions for files, directories, and symbolic links.
> >
> > It sure seems like this must be a solved problem.  I.e. there must be
> > something like this macro, which Google Gemini so helpfully
> > hallucinated.
> >
> >     fs_read_access(<domain_type>, <file_type>);
> >
> > Thus far, I've been completely unable to find anything like this.
> >
> > Am I wrong that macros like this exist?
>
> I can give you an example of how the public content feature might be
> implemented with an example. the refpolicy ftp module:
>
> There are two scenario's there:
>
> 1. by default ftpd_t can read(only) public_content_t and public_content_rw_t
> dirs, files and symlinks:
>
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L251
>
> This interface is defined here:
>
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/system/miscfiles.if#L915
>
> 2. write access to public_content_rw_t is conditional in this
> example (with a boolean):
>
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L16
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L260
>
> This interface is defined here:
>
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/system/miscfiles.if#L937

Just to add onto what Dominick said, audit2allow -R will try to find
the closest matching refpolicy interface from a set of avc: denied
messages, although YMMV, and there are also a set of general file
access patterns and permission set macros defined in the files under
https://github.com/SELinuxProject/refpolicy/tree/main/policy/support
which can be found under /usr/share/selinux/devel/include/support if
you have selinux-policy-devel installed on Fedora (or similar on other
distributions).
/usr/share/selinux/devel/include/html should also contain the
generated documentation from the refpolicy sources.





>
> --
> gpg --locate-keys dominick.grift@defensec.nl (wkd)
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift
> Mastodon: @kcinimod@defensec.nl
>

Re: File access macros

[Ian Pilcher]

On 9/14/25 12:29 AM, Dominick Grift wrote:
> I can give you an example of how the public content feature might be
> implemented with an example. the refpolicy ftp module:
> 
> There are two scenario's there:
> 
> 1. by default ftpd_t can read(only) public_content_t and public_content_rw_t
> dirs, files and symlinks:
> 
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L251
> 
> This interface is defined here:
> 
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/system/miscfiles.if#L915
> 
> 2. write access to public_content_rw_t is conditional in this
> example (with a boolean):
> 
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L16
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/services/ftp.te#L260
> 
> This interface is defined here:
> 
> https://github.com/SELinuxProject/refpolicy/blob/main/policy/modules/system/miscfiles.if#L937

I did finally find the miscfiles_read_public_files and
miscfiles_manage_public_files macros by looking at the Apache policy
module (apache.te), so I ended up with this simple module:

	policy_module(container-public-content, 0)

	require {
		type container_t;
	};

	bool container_read_public_content false;
	if container_read_public_content {
		miscfiles_read_public_files(container_t)
	}

	bool container_manage_public_content false;
	if container_manage_public_content {
		miscfiles_manage_public_files(container_t)
	}

Thanks!

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================