Open SkewedZeppelin opened 7 months ago
I see now that doing mime-type checks on the rpmdb entries or not having a filter on the rpmdb would both be costly.
Perhaps a special glob for files without an extension could help mitigate some cases for now?
Would still not handle cases like (already mentioned twice in #151)
rule=13 dec=deny_audit perm=open auid=1000 pid=32114 exe=/usr/bin/git : path=/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample ftype=text/x-perl trust=0
For this could potentially do the rpmdb lookup after/during denial where this information is already calculated for the file, then just check the rpmdb again for it and automatically trust it if it matched. But that may also be bad for performance.
What does "fapolicyd-cli --ftype /usr/share/gnome-shell/org.gnome.ScreenSaver" say for the type?
The only difference between f38 and f39 that I can find for the file package is a change in the rpm's license. I wonder if there is a change in the ScreenSaver file between Fedora versions?
Actually...I see that you listed the contents of the file. It looks like the extra lines are actually code since they're importing javascript files. (And gnomeshell is written in javascript.) I wonder why they are not detected properly as
Rather than use file, use "fapolicyd-cli --ftype" to check since fapolicyd has extended the magic definitions.
f39 outputs text/x-java
f38 outputs text/plain
hm, maybe I'll just upgrade to f40 then
As for why it's not in the trust database, I think we need to make a couple of adjustments to: /etc/fapolicyd/fapolicyd-filter.conf
Under Fedora 39 with gnome-shell-45.3-1.fc39 it isn't possible to lock the screen.
This is because the mime-type for the screensaver file wrongly is matched as Java sources and triggers the default rule:
While the mime-type is one issue, the file itself should be in the trust-db, but isn't:
This can be worked around by manually trusting it, but why isn't it already trusted?
f39
f38