On Saturday, 25 January 2025 06:38:45 AEDT Paul Moore wrote:
> My initial thinking is that if we limit ourselves to existing SELinux
> policy permissions, this is much more of FILE__WATCH_MOUNT operation
> rather than a FILE__WATCH operation as while the /proc/PID/ns/mnt file
> specified in @path is simply a file, it represents much more than
> that. However, it we want to consider adding a new SELinux policy
> permission (which is easy to do), we may want to consider adding a new
> mount namespace specific permission, e.g. FILE__WATCH_MOUNTNS, this
> would make it easier for policy developers to distinguish between
> watching a traditional mount point and a mount namespace (although
> given the common approaches to labeling this may not be very
> significant). I'd personally like to hear from the SELinux policy
> folks on this (the SELinux reference policy has also been CC'd).
>
> If we reuse the file/watch_mount permission the policy rule would look
> something like below where <subject> is the SELinux domain of the
> process making the change, and <mntns_label> is the label of the
> /proc/PID/ns/mnt file:
>
> allow <subject> <mntns_label>:file { watch_mount };
>
> If we add a new file/watch_mountns permission the policy rule would
> look like this:
>
> allow <subject> <mntns_label>:file { watch_mountns };
What's the benefit in watching mount being separate from watching a namespace
mount?
In what situation could a process be permitted one of those but not the other?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
