Closed serega990306 closed 2 years ago
With Xserver the xclipboard functionality should still work properly yes:
But in my experience the X server access control extension is partly broken since the introductions of DRI3 (except with maybe VESA and that SPICE protocol (i forgot its name) as those probably do not support DRI3 (not sure). The issue there is that if you use DRI3 then you cannot control "screen scraping" because DRI3 requires that everyone can read the x root window.
... but yes the x clipboard can be controlled with XACE in my experience.
shared memory and memfd are controlled by SELinux AFAIK (its created with the level of the creating task)
Also note that XACE does not work with Xwayland (because that's actually wayland posing as Xserver)
I recent day's ive been playing with a tool called 'cage'. It is a wlroots compositor (wayland) and generally it is for running "kiosks" (for example firefox -kiosk). Each caged application gets its own cage (and thus its own wayland compositor). This means that from a wayland perspective you're cages are separated (no key logging, no screen scraping, no clipboard access).
The neat thing I found about this tool is that you can also run it nested in a more functional wlroots compositor like for example "swaywm". So you can for example run two firefox instances that both have their own cage and are also constrained with SELinux.
For example to run a cage with Firefox:
mkdir --context=wheel.id:wheel.role:cage.tmp.file:s0 /ram/cagedfirefox 2>/dev/null
alias cagedfirefox="systemd-run --user -p SELinuxContext=wheel.id:wheel.role:cage.subj:s0:c1,c2 -p WorkingDirectory=/ram/cagedfirefox -p Environment=XDG_CONFIG_HOME=/ram/cagedfirefox/.config -p Environment=XDG_DATA_HOME=/ram/cagedfirefox/.local/share -p Environment=XDG_STATE_HOME=/ram/cagedfirefox/.local/state -p Environment=XDG_CACHE_HOME=/ram/cagedfirefox/.cache -p Environment=HOME=/ram/cagedfirefox -p Environment=MOZ_ENABLE_WAYLAND=1 cage -s -- firefox -kiosk"
I have a cage.subj domain that most applications will probably happily be able to run in, it is MCS constrained and by default also RBACSEP constrained.
The cages can be run either directly from a virtual console or nested under sway (similar to how you can run nested Xservers with zephyr). Cage also supports Xwayland so it probably should work with any application that can run with Xserver.
https://www.hjdskes.nl/projects/cage/ https://swaywm.org/ https://github.com/DefenSec/dssp5/blob/dssp5-debian/src/agent/useragent/c/cage.cil
This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.
Closing stale PR.
So the thing is, I need to control access to memory. For example, I have a running firefox application with s1 security level :
setest01_u:myrole_r:myrole_t:s1 2608 tty2 00:00:06 firefox
Everything else is running with s0 security level :I need to forbid coping from firefox with s1 security level to, for example, terminal application with s0 security level. It should be allowed to copy only to the same security level.