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
1 Like
Could you please add the usual include local?
1 Like
That’s not in any of the other profiles in apparmor-profile-everything. Will I add it to those too?
1 Like
Yes, that would be good.
1 Like
this needs to be extended as well: apparmor-profile-everything/rules at master · Kicksecure/apparmor-profile-everything · GitHub
1 Like
2 Likes
This was also merged and is now in developers repository.
1 Like
I think we should decide to either disable the affected systemd service sandboxing or their apparmor profile for now as a workaround and then create a call for testing.
apparmor-profile-everything is nearly ready imo excluding the sandboxing issues.
1 Like
Can be considered. Some questions.
Are you referring to Systemd sandboxing fails when using a full system apparmor policy · Issue #14277 · systemd/systemd · GitHub?
Could you ask apparmor developers please regarding Systemd sandboxing fails when using a full system apparmor policy · Issue #14277 · systemd/systemd · GitHub?
Which one(s) are affected?
Which ones are affected?
Need also documentation how to use this.
apparmor-profile-everything
As long as Multiple Boot Modes for Better Security: an Implementation of Untrusted Root isn’t implemented, usage of setting kernel boot parameters isn’t obvious for users. We have no documentation generally yet how to change kernel parameters at grub boot menu (using edit key E) but would be useful to have.
1 Like