fanotify opportunities

[smitsohu]

The kernel fanotify api has improved a lot recently, and I started to wonder if that is something we would be interested in.

For example, it is possible to watch regular files that are under control of the user (like in user home), and every time a program requests to write/move/remove these files, show a dialogue and ask to approve or reject. Maybe we could get away with something simple like zenity or kdialog for the GUI (as long as there are not too many events).

Since 5.13 there is also unprivileged fanotify Unprivileged fanotify has not landed yet and it won't be able to do permission checks.

[rusty-snake]

I remember #2874.

[kmk3]

(This post is mostly just about the dialog programs)

@smitsohu on Nov 9:

The kernel fanotify api has improved a lot recently, and I started to
wonder if that is something we would be interested in.

For example, it is possible to watch regular files that are under control of
the user (like in user home), and every time a program requests to
write/move/remove these files, show a dialogue and ask to approve or reject.
Maybe we could get away with something simple like zenity or kdialog for
the GUI (as long as there are not too many events).

Using a simple dialog program sounds interesting, but on Arch, zenity depends
on an entire webengine, webkit2gtk (95.81 MiB installed), and kdialog depends
on kio, which is quite big as well (26.79 MiB installed) and has many
dependencies. So it would be nice to use a smaller alternative if possible.

(To be clear, I'm using the install size mostly as an indirect measure of
complexity)

If it's intended to be just an optional runtime dependency, I suppose something
like this could be done:

file='foo'
message="firejail: Allow $program:$pid to move $file?"

if command -v kdialog >/dev/null; then
	kdialog params "$message"
elif command -v zenity >/dev/null; then
	zenity params "$message"
elif command -v qarma >/dev/null; then
	qarma params "$message"
elif command -v dmenu >/dev/null; then
	printf 'Cancel\nOK\n' | dmenu -p "$message"
elif command -v xmessage >/dev/null; then
	xmessage params "$message"
else
	printf 'firejail: warning: no dialog program found, ignoring request from %s:%s to move %s\n' "$program" "$pid" "$file" >&2
fi

This is similar to what neovim does to find a clipboard provider (it checks for
xclip, xsel, wl-clipboard and others).

To expand on the other programs listed above:

qarma (qarma-git on the AUR) is a bit smaller, but still depends on qt5-base
(65.15 MiB installed):

• https://github.com/luebking/qarma

dmenu is the standard suckless tool for prompts, so it would be nice to have it
as part of the programs supported:

• https://tools.suckless.org/dmenu/

xorg-xmessage might be the smallest (and is also used by awesomewm and a few
other programs), but it doesn't look the greatest (so it could be used as a
fallback).

For compile-time dependencies, I found this for X11:

• https://github.com/x42/sofd

Possibly bigger than needed (compared to using some X11 lib directly).

Not sure if there's a wayland equivalent. Maybe xdg portals could be used, but
that sounds like it could be risky if spawned from a privileged process.

[topimiettinen]

The kernel fanotify api has improved a lot recently, and I started to wonder if that is something we would be interested in.

For example, it is possible to watch regular files that are under control of the user (like in user home), and every time a program requests to write/move/remove these files, show a dialogue and ask to approve or reject. Maybe we could get away with something simple like zenity or kdialog for the GUI (as long as there are not too many events).

The new API is FAN_ACCESS_PERM, FAN_OPEN_PERM and FAN_OPEN_EXEC_PERM. Looks interesting. It would be nice if the operation could be limited to current mount namespace only, but according to the manual page I don't think that's possible. Without this, activities by other programs outside firejail could mess with Firejail and filtering by PID could lead to for example TOCTOU issues.

[smitsohu]

My original idea was something like a background service, an extension to the new IDS feature. But I think I see now the problem. It is going to make users the big boss in their home directories, and even root will have to obey their rules (as far as I understand).

It would be nice if the operation could be limited to current mount namespace only, but according to the manual page I don't think that's possible.

Might still be possible, but only the subset of events that can be attached to a specific mount (FAN_MARK_MOUNT). However, I'm having difficulties to see a compelling use case for that. Maybe many sandboxes sharing a --private= directory?

[topimiettinen]

My original idea was something like a background service, an extension to the new IDS feature. But I think I see now the problem. It is going to make users the big boss in their home directories, and even root will have to obey their rules (as far as I understand).

Yes, a background IDS would want to watch for all mount namespaces of interest. For Firejail it's probably more useful if the operation could be limited somehow to the mount namespace used by an instance of Firejail and not everything outside it.

It would be nice if the operation could be limited to current mount namespace only, but according to the manual page I don't think that's possible.

Might still be possible, but only the subset of events that can be attached to a specific mount (FAN_MARK_MOUNT). However, I'm having difficulties to see a compelling use case for that. Maybe many sandboxes sharing a --private= directory?

I was thinking about integrating this to Firejail itself, so one instance would check accesses for one sandbox. Then as each sandbox should have a separate mount namespace, fanotify would ideally only report accesses inside that namespace but not in other sandboxes. If some sandboxes share a mount namespace, the checks of this kind of (hypothetical) focused fanotify would apply to all of those and things would be more complex for multiple Firejail instances managing multiple fanotifiers, or they would have to coordinate this somehow. The coordinated way (only one instance does fanotify stuff) could make this useful even if fanotify doesn't care about mount namespaces (maybe it does, the page isn't very clear on this).

[smitsohu]

Update: If we mark mount points, and the mounts are private to a sandbox mount namespace, then we can have a per-sandbox fanotify. That's the good news.

What's not so nice is that if root joins a sandbox created by an unprivileged user, the unprivileged user is the boss as far as fanotify goes, and root is bound by that users' decisions. It shows that fanotify was originally developed for a different purpose. Then again, maybe it is something that people will run rarely into, or even not consider to be an issue at all, and root can always recover by killing the monitoring process.

I was thinking about integrating this to Firejail itself, so one instance would check accesses for one sandbox. Then as each sandbox should have a separate mount namespace, fanotify would ideally only report accesses inside that namespace but not in other sandboxes

Ok, when used like this, fanotify could become a flexible blacklist. For example it might help when doing something like whitelist ${DOCUMENTS}.