Could you review this one please?
1 Like
Yes.
I did but got no response.
onion-grater, sdwdate and haveged. They all have sandboxing and an apparmor profile. We need to remove one or the other. Not all sandboxing would have to be removed, we just need to remove any that sets no_new_privs.
It’s good. I only tested the profile with Xorg running as root since that’s the default in Whonix so that PR is good for compatibility.
1 Like
Alright. Thanks for clarification. Sounds sensible.
Very good. Please add these two links in comments so anyone looking at this can see the justification and can see we already did the right thing exhausted our options before falling back to a workaround.
Disabling systemd hardening for those doesn’t sound too bad.
Probably better to disable systemd hardening and keep apparmor profile since more granular and covering more?
Possible to just make selective edits to that systemd unit file?
If so, could you add systemd drop-in config snippets instead please which disables no_new_privs and whatever else is required? (I can help with the drop-ins, did tons of these already, once I know what changes to the systemd unit file are required.)
Merged.
1 Like
I have a rootless Xorg AppArmor profile in use right now on a Ubuntu box; I’d be happy to share. It is basically @madaidan 's Xorg profile, with a couple things removed (was able to drop cap_dac_override for example) and small adjustments. It would probably work as-is or with minimal tweaking with any other distro that has rootless Xorg.
Someone above was talking about the “owner” directives. I tested this exact not modified apparmor-profile-everything Xorg profile in Debian. The only “owners” I had to remove to have the Xorg profile up and running error free were in /tmp/ specifically /tmp/.X*-lock, and /tmp/.X11-unix/. Lightdm refused to start with owner for some reason. I also had to add a “r” read directive for the /tmp/.tX*-lock file and for /tmp/.X11-unix/ (This was not Whonix, it was Debian Buster on an Xfce desktop, on a host not a virtual machine. There are many systemd sandboxed services I added so any one of them could have influenced this as well.) the rest of the “owner” directives were perfectly fine. It’s a very good profile
2 Likes
They do 2 different things so I’m not sure.
haveged works with a drop-in specifying NoNewPrivileges=no but onion-grater/sdwdate didn’t seem to work that way.
1 Like
madaidan via Whonix Forum:
They do 2 different things so I’m not sure.
Apparmor profile seems more sophisticated. Systemd hardening often isn’t
fully complete.
haveged works with a drop-in specifying
NoNewPrivileges=no
Good.
but onion-grater/sdwdate didn’t seem to work that way.
What else needs to be disabled?
1 Like
Everything on systemd.exec that says “NoNewPrivileges=yes is implied”. It didn’t seem to work with a drop-in though. Probably because there isn’t a SystemCallFilter=no, SystemCallArchitectures=no or RestrictAddressFamilies=no.
1 Like
Could you review this one please?
1 Like
It’s great. It should be merged.
1 Like
1 Like
For sdwdate, the only solution seems to be commenting out the following in the original file (drop-ins don’t work):
#AmbientCapabilities=CAP_SYS_TIME
#CapabilityBoundingSet=CAP_SYS_TIME
ProtectSystem=strict
ReadWriteDirectories=/run/sdwdate/
ProtectHome=true
#ProtectKernelTunables=true
#ProtectKernelModules=true
ProtectControlGroups=true
PrivateTmp=true
PrivateMounts=true
#PrivateDevices=true
#MemoryDenyWriteExecute=true
#NoNewPrivileges=true
#RestrictRealtime=true
#SystemCallArchitectures=native
#RestrictNamespaces=true
#RestrictAddressFamilies=AF_UNIX AF_INET
# Broken. Need list of syscalls. Alternative below.
#SystemCallFilter=@clock @ipc @signal
# Blacklist certain syscalls. A whitelist would be stronger.
#SystemCallFilter=~@mount @cpu-emulation @debug @keyring @module @obsolete @raw-io
For onion-grater, the only solution seems to be removing its apparmor profile.
1 Like
All merged.
audit deny /*System.map rw,
Can’t have a file System.map in /home/user/System.map?
Not great.
Non-great solution…
For now, I’d suggest
- add the exact same systemd unit file to apparmor-profile-everything (same path, same name, same contents)
- (could add file extension
.distbecause I have to move the file otherwise) - add whatever changes to the systemd unit file in another commit (for purpose of making diff visible)
- check if sdwdate is even installed in that systemd unit file ConditionFileExists or something
- I would then add a config-package-dev displace
In effect, apparmor-profile-everything would take over the sdwdate.service systemd unit file.
Also a super complex drop-in also maybe wouldn’t be a great solution.
config-package-dev hide
Example: https://gitlab.com/whonix/debug-misc/-/blob/master/debian/debug-misc.hide
1 Like
No. Since there are so many places for the kernel images/System.map to be, it needs to be blunt to prevent any info leaks.
1 Like
1 Like
That could use a comment.
1 Like
Merged. This is now in Whonix testers repository. Untested. Please test. I don’t recall config-package-dev displaceing a systemd unit file or config-package-dev hideing an apparmor profile. Good chance it will work, also possible this needs further work.
1 Like
It works but there’s an error upon installation:
Failed to preset unit: Unit file sdwdate.service.dist.service does not exist.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on sdwdate.service.dist: No such file or directory
Failed to get unit file state for sdwdate.service.dist.service: No such file or directory
sdwdate.service.dist is a disabled or a static unit, not starting it.
It doesn’t seem to actually affect anything though and everything works fine.
I think the 2 main issues now are:
-
Splitting everything up more so everything get its own profile. All system services should have their own profile and the entire user session should be in its own profile too. Apps will then transition to sandbox-app-launcher which brings up issue 2.
-
sandbox-app-launcher compatibility. This might be difficult since the script that starts the sandbox needs a lot of permissions and we need to ensure that the app transitions into the right profile. Initial testing of this broke though.
I think a nice infographic would be good for Kicksecure - Secure by Default Operating System
1 Like
1 Like
1 Like
I see. Please:
config-package-dev hide sdwdate.service. Not displace.
And add (rename sdwdate.service.dist to) sdwdate-aae.service or so instead.
I speculate Debian maintainer scripts don’t like any files in the systemd folder ending with anything other than the .service file extension.
1 Like