SELinuxProject / refpolicy

SELinux Reference Policy v2
https://github.com/SELinuxProject/refpolicy/wiki
GNU General Public License v2.0
297 stars 128 forks source link

Is there any way to control clipboard and shared memory? #476

Closed serega990306 closed 2 years ago

serega990306 commented 2 years ago

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 :

setest01_u:myrole_r:myrole_t:s0    2238 tty2     00:00:00 gsd-a11y-settin
setest01_u:myrole_r:myrole_t:s0    2241 tty2     00:00:00 gsd-clipboard
...

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.

ghost commented 2 years ago

With Xserver the xclipboard functionality should still work properly yes:

https://github.com/SELinuxProject/selinux-notebook/blob/main/src/x_windows.md#x-windows-selinux-support

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)

ghost commented 2 years ago

Also note that XACE does not work with Xwayland (because that's actually wayland posing as Xserver)

ghost commented 2 years ago

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

github-actions[bot] commented 2 years ago

This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.

github-actions[bot] commented 2 years ago

Closing stale PR.