Re: [PATCH v4 2/4] fanotify: notify on mount attach and detach

[Russell Coker <russell@coker.com.au>]

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/