On Sat, Dec 14, 2019 at 05:40:51PM +0100, Alexander Wetzel wrote:
> Hello,
> 
> I've a strange problem with selinux when switching a kernel >= 5.4.0 and
> since this could be an unintended regression I want to report it here, too.
> 
> There are two threads in the Gentoo forum with more details:
> https://forums.gentoo.org/viewtopic-t-1105128.html (started by me)
> https://forums.gentoo.org/viewtopic-t-1104916.html (looks like the same
> underlying issue)
> 
> In a nutshell commit ac5656d8a4cd ("fanotify, inotify, dnotify, security:
> add security hook for fs notifications") added new hooks for fs
> notifications which also seem to requite updated user space and policies
> which seem to be unavailable as for now.
> 
> So when updating the kernel to >= 5.4.0 all processes trying to register for
> file notifications will be blocked. And at least I was unable to add rules
> for the new permission "watch", even after updating all selinux
> tools/libraries and policies to the upstream git versions - as provided by
> Gentoo's -9999 version of the packages.
> 
> Dec  8 14:49:01 web kernel: audit: type=1400 audit(1575812941.870:2069):
> avc:  denied  { watch } for  pid=2826 comm="crond"
> path="/var/spool/cron/crontabs" dev="sda3" ino=2539899
> scontext=system_u:system_r:crond_t tcontext=system_u:object_r:cron_spool_t
> tclass=dir permissive=0
> 
> I ended up reverting commit ac5656d8a4cd ("fanotify, inotify, dnotify,
> security: add security hook for fs notifications") and asked in the gentoo
> forum - so far without success (link above) - how that should work properly.
> 
> If there is a way to use an unmodified kernel >= 5.4.0 with older (so far
> all current) selinux tools and policies I did miss it.
> 
> Do you have a pointer how I can keep the commit ac5656d8a4cd in a selinux
> enabled system in enforcing mode without breaking all file change
> notifications?
> 
> Alexander

I do not believe there is a regression. However support in the policy for this functionality may be lagging behind (be non existent as of now).
You could try this as a temporary workaround:

echo "(handleunknown allow)" > mytest.cil && sudo semodule -i mytest.cil

If that works then that should tell selinux to ignore the watch access vector permissions (and any other permission unknown to the policy).

> 
> 
> 
> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift