* "watch" - Problem when using kernel >= 5.4
@ 2019-12-14 16:40 Alexander Wetzel
2019-12-14 20:30 ` Dominick Grift
0 siblings, 1 reply; 3+ messages in thread
From: Alexander Wetzel @ 2019-12-14 16:40 UTC (permalink / raw)
To: selinux; +Cc: acgoide, paul
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: "watch" - Problem when using kernel >= 5.4
2019-12-14 16:40 "watch" - Problem when using kernel >= 5.4 Alexander Wetzel
@ 2019-12-14 20:30 ` Dominick Grift
2019-12-16 11:31 ` Alexander Wetzel
0 siblings, 1 reply; 3+ messages in thread
From: Dominick Grift @ 2019-12-14 20:30 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: selinux, acgoide, paul
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: "watch" - Problem when using kernel >= 5.4
2019-12-14 20:30 ` Dominick Grift
@ 2019-12-16 11:31 ` Alexander Wetzel
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Wetzel @ 2019-12-16 11:31 UTC (permalink / raw)
To: selinux, acgoide, paul
>> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-16 12:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-14 16:40 "watch" - Problem when using kernel >= 5.4 Alexander Wetzel
2019-12-14 20:30 ` Dominick Grift
2019-12-16 11:31 ` Alexander Wetzel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).