Page MenuHomePhabricator

qubes-whonix-network.service doesn't provide helpful error message when !CONFIG_DUMMY
Closed, InvalidPublic

Description

General background:

https://github.com/EFForg/https-everywhere/commit/79d6ffdb8a9a48220efb0f0a39160cc4e6f9aa2c
https://github.com/EFForg/https-everywhere/issues/2842#issuecomment-143905350
(The DoS was from Tor's control port).

There are a few problems that are making me weary of using whonix-gw again, and the first prerequisite is this.

Removing the modprobe line in network-proxy-setup doesn't fix this.

sys-net, sys-firewall, and whonix-ws all work fine with grsecurity enabled and the rootkit interface disabled.

Details

Impact
Normal

Event Timeline

hitithard updated the task description. (Show Details)
hitithard added a project: Whonix.
hitithard set Impact to Needs Triage.

General background:

Sorry, I don't understand the general background.

the rootkit interface disabled

Which rootkit interface?


Please provide steps to reproduce, expected result and actual result.

In T409#6836, @Patrick wrote:

General background:

Sorry, I don't understand the general background.

The general background is that ~10 minutes after contacting my own coutry's intelligence agency about another country's intelligence agency I recieved a DoS from tor's control port (whonix-gw on Qubes vanilla kernel) to whonix-ws (using grsecurity). After talking to Peter (pde) at the EFF about the logs, which showed searching for some magic sequence (similar to SYNful ACK, but different), my Qubes machine was wiped overnight.

the rootkit interface disabled

Which rootkit interface?

"rootkit interface" is a sarcastic reference to CONFIG_MODULES, since that is what it serves as.


Please provide steps to reproduce, expected result and actual result.

Sorry, I was wrong. It wasn't a problem with CONFIG_MODULES, I simply hadn't tested every combination (kernel recompilation fatigue).

The actual problem was not having DUMMY. I think perhaps there should be a specific error message for that case.

I also noticed that when either ipv6 is disabled or some tables that whonix-gw doesn't use but does flush aren't in the kernel, the firewall script fails. I think the firewall script ought to use sysctl to check whether related sysfs entries exist and continue (not fail) if they don't exist.

hitithard renamed this task from qubes-whonix-network.service fails without CONFIG_MODULES to qubes-whonix-network.service doesn't provide helpful error message when !CONFIG_DUMMY.Oct 15 2015, 8:20 PM
Patrick triaged this task as Wishlist priority.Oct 15 2015, 9:41 PM
Patrick added a project: grsecurity.
Patrick changed Impact from Needs Triage to Normal.

We currently don't have a maintainer dedicated to grsecurity. The only way for now to make this happen is suggesting a patch.

I also noticed that when either ipv6 is disabled or some tables that whonix-gw doesn't use but does flush aren't in the kernel, the firewall script fails. I think the firewall script ought to use sysctl to check whether related sysfs entries exist and continue (not fail) if they don't exist.

It works good enough for us for now. Should be posted in separate issue. Patches are happily considered.

Patrick claimed this task.

Since grsecurity is not a thing anymore, closing this as invalid.