"watch" - Problem when using kernel >= 5.4

"watch" - Problem when using kernel >= 5.4

[Alexander Wetzel]

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

Re: "watch" - Problem when using kernel >= 5.4

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: "watch" - Problem when using kernel >= 5.4

[Alexander Wetzel]

>> 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).
> 

Thank you very much, that was the tip I was missing

While the workaround itself is not working
$ echo "(handleunknown allow)" > mytest.cil && sudo semodule -i mytest.cil
Password:
Policy can not have more than one handleunknown
Failed to verify cil database
Failed to verify cil database
/usr/sbin/semodule:  Failed!

that was the "knob" I was missing and with your tip I found the way how 
this is intended to be handled.

I've now simply executed these commands

echo "handle-unknown = allow" >> /etc/selinux/semanage.conf
semodule -B

Which solves the issue without any reverts.

Alexander