nixos/tor: improve type-checking and hardening#97740
Conversation
9647a0d to
31954b5
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
Can you please fix the eval error? |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
Rebased and adapted after e17d4b0 got merged. |
|
That's a big one. I will start to have a look. |
|
@GrahamcOfBorg test tor |
|
I deployed this on my server and it seems to work for the client setup/hidden services. Can you add a changelog entry to |
@Mic92, thanks for the beta-testing. I've added a release note. A release note about |
|
I'm getting using services.tor = {
enable = true;
client.enable = true;
client.dns.enable = true;
}; |
|
This always accesses |
@delroth Thanks for the report, this should fix the issue: #109096 (no time to test right now) |
|
I had previously been setting services.tor.extraConfig = ''
ORPort [2001:ba8:1f1:f0bc::2]:${toString config.services.tor.relay.port}
'';To make my relay reachable over IPv6 (which requires manually specifying the IPv6 address in ORPort). As far as I can tell, there’s no way to do that any more, because there’s no more |
So it should actually accept a string? |
|
> I had previously been setting
>
> ```nix
> services.tor.extraConfig = ''
> ORPort [2001:ba8:1f1:f0bc::2]:${toString config.services.tor.relay.port}
> '';
> ```
>
> To make my relay reachable over IPv6 (which requires manually
> specifying the IPv6 address in ORPort). As far as I can tell,
> there’s no way to do that any more, because there’s no more
> `extraConfig` option and `services.tor.settings.ORPort` does not
> accept values of this format.
So it should actually accept a string?
I suppose so, unless we wanted to make it something more structured,
like strMatching or an attribute set. I haven't looked too closely at
the rest of this change yet, so I don't know what would be more
consistent.
|
|
This is an attempt to improve
services.torusing recent NixOS and systemd features. This is an early release, it needs testing/reviewing. I've done what I could to preserve backward compatibility whenmkRemoveOptionormkRenameOptioncould be used, but not otherwise for options whose structure/names have to change to matchtorrc's structure or well-known/documented option names. Current users' configs will break, but hopefully only at compile-time and with an helpul warning/error message, and hopefully not with some subtle changes in Tor's behavior. Note also that most of thedescription=now link to the Tor manual instead of copy/pasting it, because it would be too painful to write/maintain otherwise.Motivation for this change
Current service for Tor is lacking proper type-checking of options and systemd-level hardening.
Things done
settings.nixos/tests/tor.nixloaOf.tor-client-auth-gento generate v3 client authorizations for onion services, based upon Bash script in https://community.torproject.org/onion-services/advanced/client-auth/systemd-analyze security tor(note:PrivateUsers=is set tofalsewhenCAP_NET_BIND_SERVICEis needed)sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)