This was done. If not, please create specific tickets where it isn't done.

Removed a few. Would not start without openat, so kept.

Yay, we have ProtectSystem=strict now.

Yay, we have ProtectSystem=strict now.

Can we exclude ExecStartPre=/usr/lib/onion-grater-merger from systemd hardening?

Error back after reboot.

https://github.com/Whonix/onion-grater/blob/master/lib/systemd/system/onion-grater.service currently works without ReadWritePaths. So let's not add?

https://github.com/Whonix/onion-grater/blob/master/lib/systemd/system/onion-grater.service currently works without ReadWritePaths. So let's not add?

It's a file, not a folder.

https://github.com/Whonix/onion-grater/commit/8480cff304ea019b25dc49d91672e7c3f8599a07

It's a file, not a folder. Nothing in the code of
/usr/lib/onion-grater-merger writes to /usr/lib/onion-grater-merger.

I just re-read the error message. Try adding

That's weird. Onion-grater is trying to write to somewhere that's being mounted read-only by systemd.

Merged your changes.

Does it work after you comment ProtectSystem=strict and ReadWriteDirectories=? I think on Qubes-Whonix it is trying to write to a directory in /var/run (probably /var/run/qubes-service). I can't test as I don't use Qubes.

Unfortunately not. On Qubes-Whonix. Could be Non-Qubes-Whonix vs
Qubes-Whonix?

Does it work using this? It looks like it needs the openat syscall which it now allows.

Does not work yet. @madaidan

Actually, the "apt-daily.timer: Adding 1h 17min 24.927437s random time" message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).

This is sorted in a later version of systemd.

All yes.

sudo netstal -tulpen

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

sudo apt-get remove control-port-filter-python
It wants to remove everything. I don't think 'Replaces' worked.

sudo service tor-controlport-filter stop
sudo service onion-grater start
same failure
if i try
sudo apt-get remove control-port-filter-python
It wants to remove everything. I don't think 'Replaces' worked.

Probably tor-controlport-filter systemd unit file (the old one) still
running and blocking the onion-grater systemd unit file.

Python is choking on the line:
server = FilteredControlPortProxy(address, FilteredControlPortProxyHandler)

sudo journalctl -u onion-grater

sudo service onion-grater status just tells me that it failed to load. Any clues about how to debug this?

Should be even easier since onion-grater debian/control contains
Replaces: control-port-filter-python. So just installing onion-grater
should do.

Question: To install OG in whonix 14 dev, so I simply pull the repo, make deb-icup, stop the old tor control port filter proxy, and start onion grater?

They happily take it if we contribute it.

Tails didn't feel the need to use system call filtering?

In T631#13827, @JasonJAyalaP wrote:

Do you mean we ported it from Tails to Whonix?

Using the hardening broke Tails? What do you mean?

I haven't tested it yet and unfortunately I'm very busy these days, so cpfp apparmor work is up for grabs.

In T631#13769, @JasonJAyalaP wrote:

@Patrick
What do we need for the next dev release for hula?

@Patrick
What do we need for the next dev release for hula?

In T424#12530, @Patrick wrote:

A systemd --user instance knows nothing about the systemd --system instance. I.e. a systemd --user instance cannot reference After=some-system.service. Source:

https://lists.freedesktop.org/archives/systemd-devel/2017-February/038361.html

So we cannot use qubes-whonixsetup.service After=qubes-gui-agent.service.

systemd feature request - systemd --user instance ability to reference systemd --system services with After= etc.:
https://github.com/systemd/systemd/issues/5462

Asked about how to set the environment variables and got some answers:
https://lists.freedesktop.org/archives/systemd-devel/2017-February/038365.html

A systemd --user instance knows nothing about the systemd --system instance. I.e. a systemd --user instance cannot reference After=some-system.service. Source:

One mistake fixed.

This unfortunately has quite a chance to have messed up an argument an introduce a regression.

That worked. Somewhat. Now I need to figure out if there is a sane way to sort out the environment variables.

As per

In T424#12408, @Patrick wrote:

I haven't figured out yet how to cleanly (or uncleanly) enable systemd user services using Debian packaging. sudo -u user systemctl --user enable mytest will probably not work (apt-get somehow does not like sudo -u user anymore since Debian stretch), and that would not be a clean solution either.

One step closer.

Yes, that would be great and there is still time until the final release.

As soon as the next dev release (with the working KDE menus) is out I'll build it and start working.

In T631#12242, @HulaHoop wrote:

As in the seccomp stuff?

As in the seccomp stuff? I think I can but can you help me find the original topic so I can re-create the testing environment I used back then?

Since you originally added this, do you think you could re-invent it? @HulaHoop

Not easy. Need to wait for reply from TPO.

https://github.com/Whonix/anon-ws-disable-stacked-tor/commit/63a0d3ccd15646cf11d7c37a2a7fbde7e4b0bb61

Since rinetd has been replaced with socat in T464, this code can be removed.

https://github.com/Whonix/shared-folder-help/commit/d797f2ad9e4f385d4873ad137056a1e9807b9ecb

@HulaHoop reported it works in KVM.

T355#5608 should be a good enough summary. And done. Nothing left to do here.

A related issue....
systemd AppArmorProfile= directive unavailable leads to not loading AppArmor profile on Debian jessie:

• https://trac.torproject.org/projects/tor/ticket/18294
• https://www.whonix.org/pipermail/whonix-devel/2016-February/000561.html
• https://forums.whonix.org/t/whonix-apparmor-profiles-development-discussion/108/640?u=patrick

do not let systemd service enter failed state of host config has not been applied:
https://github.com/Whonix/shared-folder-help/commit/24143991888ab900effe4b11f7eb55172af6793d

In T144#6289, @Patrick wrote:

Merged. Requires testing when new test images get available.

In T427#7103, @marmarek wrote:

Do you include those firewall rules in Whonix firewall?

I think the current solution (overriding 'ExecStartPre' and 'ExecStopPost') is ok. Do you include those firewall rules in Whonix firewall? Without such redirection, VMs will not be able to connect to the updates proxy.

Implemented the above /lib/systemd/system/qubes-updates-proxy.service.d/40_qubes-whonix.conf solution for now...