Though, there was a merge conflict which I resolved. You you please check files look as intended in git master?
1 Like
No.
owner /proc/{,kmsg,devices,modules,mtrr} r,
should be
owner /proc/{,kmsg,devices,mtrr} r,
1 Like
1 Like
1 Like
Using environment scrubbing with everything broke the GUI and console.
GUI error message:
Unable to contact settings server
/usr/bin/dbus-launch terminated abnormally without any error message
Console error message:
Unable to change owner or mode of tty stdin: Permission denied
1 Like
Following Restrict root access - #104 by madaidan, this isn’t nearly as restrictive as I thought but it’s still better than nothing.
1 Like
We should also remove either writing or executing from /opt, /{,var/}tmp and /{,usr/local/}etc to prevent introduction of new arbitrary code.
This isn’t as important now though as we don’t have W^X memory mappings either so it can be bypassed.
1 Like
That won’t work. Tor Browser in Whonix relies on environment variables such as TOR_SKIP_LAUNCH and others.
Isn’t the profile working an opt-in permission basis anyhow? I.e. everything forbidden by default and then opt-in what’s allowed? Why would writing to /opt be possible to begin with?
1 Like
Environment scrubbing doesn’t clear all environment variables. It just clears unsafe ones like LD_PRELOAD or LD_LIBRARY_PATH. TOR_SKIP_LAUNCH still works.
It was added as a compromise to allow the user to run their own programs.
Only root can write to it though but this can still be unsafe.
madaidan via Whonix Forum:
Environment scrubbing doesn’t clear all environment variables. It just clears unsafe ones like LD_PRELOAD or LD_LIBRARY_PATH. TOR_SKIP_LAUNCH still works.
Awesome. Merged. Now in Whonix developers repository.
Is this tested?
1 Like
Yes.
2 Likes
1 Like
madaidan via Whonix Forum:
Merged.
1 Like
What if we create a profile for the gateway specifically so it can do nothing but run Tor and update? I don’t see any reason for the gateway to have those extra permissions. Nor do I see a reason for it to have tons of other software like a GUI. Just seems like unneeded attack surface/bloat to me.
What if we trim down the gateway’s packages, apparmor restrictions and kernel? Also, if we ever use dm-verity, we can get rid of the persistent partition to fully lock down the gateway.
It’s done. Or mostly done.
Similar as Dev/Gateway - Whonix
Non-Qubes-Whonix CLI builds are already possible.
Qubes-Whonix has no desktop environment installed (handled by usual Qubes X implementation).
Otherwise there have never been much comments / review / contributions to anon-meta-packages/debian/control at master · Whonix/anon-meta-packages · GitHub
Therefore “we” probably boils down to “me” and I am not interested since it’s not the default and there’s both XFCE and CLI builds already.
Some things need to be persistent. Most important Tor entry guards, Tor config (onion service keys). Maybe some other stuff, not thought through yet.
1 Like
audit: type=1400 audit(1586889136.248:56): apparmor=“ALLOWED” operation=“exec” profile=“/usr/bin/sdwdate” name=“/usr/bin/sleep” pid=10035 comm=“sh” requested_mask=“x” denied_mask=“x” fsuid=116 ouid=0 target=“/usr/bin/sdwdate//null-/usr/bin/sleep”
To avoid more similar issues… Should we all
/bin/
to
/{,usr/}
?
1 Like
Yes.
1 Like
I figured out why some sandboxed systemd services are failing.
The no_new_privs flag prevents processes from gaining more privileges (no new privs). When seccomp is in use, this flag has to be set.
no_new_privs also prevents a process from transitioning to another apparmor profile that grants more permissions.
linux/domain.c at master · torvalds/linux · GitHub
The services that are failing (such as onion-grater) are attempting to transition to their own profiles that have a few more permissions than the init one.
There doesn’t seem to be a secure and easy solution to this.
2 Likes
Looks good?
2 Likes
Yes.
1 Like