Idea: Mark dangerous permissions

[rusty-snake]

Description

The bubblejail-config (and the documentation) could add a warning icon plus tooltip with some details to dangerous permissions.

List without claim to completeness

• X11
  • Escape sandbox
  • Sniff Keyboard
  • ...
  • Inherently unsafe
• Network
  • Internet
  • LAN
  • tcp/udp deamons on localhost
  • abstract unix sockets
• PulseAudio
  • Record microphone
• Home share
  • is explicit on what you allow ...
• System tray icons
  • Sandbox escape
• Joysticks
  • unsure
• Notifications
  • Sandbox escape
• Dconf
  • Sandbox escape

[igo95862]

Not sure. You can reason that any permission is dangerous.

[rusty-snake]

Some contra arguments:

1. The list has allow and deny permissions. While "Disable " and "Limit " have names that imply that "Filter *" is not that clear to me.
2. Some permissions like "Direct Rendering" are not dangerous AFAICTY. They only increase possible attack surface of course.
3. Similar options can have a huge different on how dangerous they are. Like X11 and Wayland both allow GUI to show up. However while x11 punches a giant hole in your sandbox, I can not tell you any real risk of Wayland.
4. Some permissions look safe but aren't. Like "Notifications" or "Tray icons" can be used to execute arbitrary commands outside of the sandbox.
5. Some permissions have unexpected permissions like "Pulse Audio" being audio Output and Input.

Mainly 3. 4. and maybe 5. make things more transparent for non-technical users.

Maybe it is possible to say all permissions are dangerous but some are green, some are yellow and some are red.

[igo95862]

I had an idea of sandboxing wizard GUI where user will be asked a sequence of questions about what resources they want a new sandbox to have access to. Maybe the each service will have an explanation of security consequences.

Like "Notifications" or "Tray icons" can be used to execute arbitrary commands outside of the sandbox.

Could you share any information on this?

[rusty-snake]

Terminology:

1. Bus (Session, System, Others)
2. Well-known name(s)
3. Unique name(s)
4. Object (path)
5. Interface

The Problem is that a lot implementations expose all their objects on all their names. So when you say allow org.kde.StatusNotifierWatcher-name you can call /StatusNotifierWatcher org.kde.StatusNotifierWatcher.RegisterStatusNotifierItem but also /org/gnome/Shell org.gnome.Shell.Eval as example.

I've created this table https://github.com/netblue30/firejail/wiki/Restrict-DBus some while ago.

---

For org.freedesktop.Notifications the answers are:

1. Use portals
2. Use GNOME > 3.36.1
3. Replace --talk=org.freedesktop.Notifications with --call=org.freedesktop.Notifications=*@/org/freedesktop/Notifications

For Tray Icons this is more difficult because --talk=org.kde.StatusNotifierWatcher works only for some programs, some require --talk=org.kde.StatusNotifierWatcher --own=org.kde.*. That's because the spec and api of KStatusNotifierItem are against containered applications as layed down by me at https://github.com/netblue30/firejail/discussions/4053.

[igo95862]

I see. Looks like some D-Bus services expose more interfaces on their service name then required.

[igo95862]

For Tray Icons this is more difficult because --talk=org.kde.StatusNotifierWatcher works only for some programs, some require --talk=org.kde.StatusNotifierWatcher --own=org.kde.*.

Right now bubblejail only does the --talk=org.kde.StatusNotifierWatcher which works for Steam. So changing it to --call=org.kde.StatusNotifierWatcher=/StatusNotifierWatcher should not break anything.

[rusty-snake]

Did you missed a "not" after the "should"?

Rule must be code>--call=org.kde.StatusNotifierWatcher=<b>*@</b/StatusNotifierWatcher I guess?

Testing should be easy, either it works or not.

[igo95862]

I tested Steam and it does seem to work with --call=org.kde.StatusNotifierWatcher=*@/StatusNotifierWatcher

I am going to release the version 0.8.1 today. There is a good backlog of bug fixes.

[xiota]

As a user, I would rather not use an interface cluttered with useless warnings.

Some of the "dangerous permissions" are obvious. Allowing network access allows access to the network. Allowing PulseAudio gives access to the microphone. Those are exactly the intended effects of allowing access to those resources.

Other issues require further explanation. "Inherently unsafe", "Sandbox escape". Those are more suited to a blog post or if sufficiently well written and referenced, could be added to docs.

[igo95862]

2. Some permissions like "Direct Rendering" are not dangerous AFAICTY. They only increase possible attack surface of course.

https://arstechnica.com/security/2023/09/gpus-from-all-major-suppliers-are-vulnerable-to-new-pixel-stealing-attack/

I wonder if disabling the DRM service prevents this attack because it forces the CPU render.

[rusty-snake]

Summary of the attack: It was found a way to steel (read/guess) pixels of an embedded iframe (the attacker controls the embedding site) via GPU site-channels.

• I remember more site channel/timing based pixel steel attacks against iframes. There are more like that.
• The attack is slow "after 30 minutes, with 97 percent accuracy". IDK how if the approximation is linear, quadratic, logarithmic, ... but it is unlikley to have sensitive stuff visible for long time.
• The PoC is only for browsers, where from bubblejails perspective DRM is not dangerous¹ because bubblejail draws a boundary between chrome and the rest of the system but not between different origins in chrome.
• CPUs are spectred in every corner.

¹ _{When I say dangerous I always mean dangerous by design not by (possible) exploit.}

[igo95862]

After thinking about it most permissions can either be used in safe or unsafe way so it does not make sense to mark them as either one. For example, you can share some harmless directory or directory with your banking data.

Also we don't want to mislead users with false security unlike what GNOME software does.