Handling of wrong mime-types & not trusting all files from rpmdb

[SkewedZeppelin]

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:

deny_audit perm=any all : ftype=%languages

While the mime-type is one issue, the file itself should be in the trust-db, but isn't:

$ rpm -qal | grep "/usr/share/gnome-shell/org.gnome."
/usr/share/gnome-shell/org.gnome.ScreenSaver
/usr/share/gnome-shell/org.gnome.ScreenSaver.src.gresource
/usr/share/gnome-shell/org.gnome.Shell.Extensions
/usr/share/gnome-shell/org.gnome.Shell.Extensions.src.gresource
/usr/share/gnome-shell/org.gnome.Shell.Notifications
/usr/share/gnome-shell/org.gnome.Shell.Notifications.src.gresource
/usr/share/gnome-shell/org.gnome.Shell.Screencast
/usr/share/gnome-shell/org.gnome.Shell.Screencast.src.gresource

$ sudo fapolicyd-cli --dump-db | grep "/usr/share/gnome-shell/org.gnome."
#no hits

This can be worked around by manually trusting it, but why isn't it already trusted?

fapolicyd-cli --file add /usr/share/gnome-shell/org.gnome.ScreenSaver

f39

$ file /usr/share/gnome-shell/org.gnome.ScreenSaver
/usr/share/gnome-shell/org.gnome.ScreenSaver: Java source, ASCII text

$ cat /usr/share/gnome-shell/org.gnome.ScreenSaver
import {programInvocationName, programArgs} from 'system';

imports.package.init({
    name: 'gnome-shell',
    prefix: '/usr',
    libdir: '/usr/lib64',
});
const {main} = await import(`${imports.package.moduledir}/main.js`);
await main([programInvocationName, ...programArgs]);

f38

$ file /usr/share/gnome-shell/org.gnome.ScreenSaver
/usr/share/gnome-shell/org.gnome.ScreenSaver: ASCII text

$ cat /usr/share/gnome-shell/org.gnome.ScreenSaver
imports.package.start({
    name: 'gnome-shell',
    prefix: '/usr',
    libdir: '/usr/lib64',
});

[SkewedZeppelin]

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.

[stevegrubb]

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?

[stevegrubb]

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 /javascript which is supposed to be trusted? If I copy the code listed from f39 to f38 and use fapolicyd-cli, it is detected as text/x-java - which is a trusted language. If I copy the same code to F40, it is detected as application/javascript which is also trusted. There was a version upgrade of file which likely changed some definitions. I can't test on an actual f39 system at the moment since I already upgraded to f40 for testing.

Rather than use file, use "fapolicyd-cli --ftype" to check since fapolicyd has extended the magic definitions.

[SkewedZeppelin]

f39 outputs text/x-java
f38 outputs text/plain

hm, maybe I'll just upgrade to f40 then

[stevegrubb]

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