I’ve noticed some documentation which I believe to be misleading and would like to report it here. It is not particularly significant but all errors in documentation are frustrating to those trying to better understand the software.
/wiki/Tunnels/Connecting_to_a_VPN_before_Tor
Under section “Separate VPN-Gateway” bullet point 3:
When a failed closed configuration is used and the VPN connection breaks down, all traffic originating from Whonix-Gateway ™ (commonly called sys-whonix) would only be forced through Tor. This is what you want if you are reading this documentation chapter. User → Tor → Internet
I believe this is misleading as a fail-closed mechanism prevents any traffic from exiting via the VPN-gateway in the case that the VPN connection is dropped. What is actually being described in the documentation is a fail-open mechanism. For somebody reading the documentation that has the strict requirement that Tor traffic never exit their system without being tunneled through VPN, this could falsely make them believe that this configuration is not for them.
Sorry if I have not reported this correctly. I would also like to know if I’ve got something wrong, but I do not believe that is the case.
`
Is it possible for you to set a server config to periodically clear the cache?
That is, often material is approved but it takes a week or more for the approved version to appear in the wiki documentation i.e. not visible unless selecting the “Pending changes” (or similar) wiki page option.
I presume that phenomenon relates to the server in question.
= Help Welcome =
Please add screenshots, texts, examples of actual social engineering / phishing attempts with explanations how it could have been detected as one.
Whonix-Workstation ™ has the transparent proxying feature enabled by default. (You could disable it if you wanted to.)
This is confusing. Whonix-Workstation does not have a transparent proxy. I believe this should say Whonix-Workstation has its traffic transparently proxied by Whonix-Gateway.
Whonix-Gateway ™ has by default no transparent proxying feature. Instructions below document how you could enable it. There are no known use cases besides leak testing.
This is confusing as well. I believe it should say Whonix-Gateway by default transparently proxies traffic originating from Whonix-Workstation, but does not transparently proxy traffic that is generated by Whonix-Gateway.
This may seem like nitpicking, but if you look through my multiple edits you’ll understand the various interpretations I had of these two quotes.
That is OK. The focus isn’t supper narrow limited Whonix-Gateway only. Analogy: when describing a “circle” it’s useful to define “a form” or to compare with “a rectangle”.
That one is correct as is too.
It’s describing it from a features point of view. There could be a footnote describing a bit where/how this is implemented.
There are no two transparent proxies.
No.
No.
prerequisite knowledge:
transparent proxy
Tor transparent proxy
User clearnet on Whonix-Gateway just uses clearnet. It’s not transparently proxied anywhere.
Hmm? If I’ve got two TransPorts and one of those ports is fed traffic originating from this machine and another is fed traffic originating from the gateway then there are two transparent proxies in operation, no?
Other than that I understand what you’re saying, but I still think it’s confusing if taken at face value.
A TransPort is just that. It’s not a a transparent proxy. A Tor TransPort is a very useful ingredient to implement a Tor transparent proxy. A TransPort alone being prepared doesn’t make it an enabled by default transparent proxying feature.
Where possible/useful, can we just import the most relevant material holus bolus (as is) into Whonix documentation and in future any updates you can amend in our wiki? You’ll also get a lot more eyeballs for your material. Obviously we’ll credit you directly as the original author.
I haven’t had a chance to review all your stuff there, but there is plenty of good material.
OK, I had a thorough look at the @madaidan hardening guide:
Chapter 2 Kernel Hardening - this could be a complete chapter in our Advanced Documentation; something like “Host Kernel Hardening” i.e. a cut and paste job because it is huge.
Chapter 3 Mandatory Access Control - we can just take bits we like for the AppArmor entry.
Chapter 4 Sandboxing - we could just take bits talking about common sandbox escapes and maybe the Systemd sandboxing section could be a standalone page in Advanced Documentation; something like “Host systemd Sandboxing”.
Chapter 5 Hardened Memory Allocator - I think this is all covered off in the existing Whonix wiki entry (?)
Chapter 6 Hardened Compilation Flags - could be a standalone page in Advanced Documentation (?). This would be another cut and paste job.
Chapter 7 Memory Safe Languages - we probably mention this somewhere, but could beef up any Whonix material by taking this paragraph as a quote.
Chapter 8 The root Account - I presume Whonix already has an entry on this somewhere & has these protections in place already. So maybe again it could be a page in Advanced Documentation for non-Qubes-Whonix users for their host OS (?). Re: Qubes, no idea if applicable.
Chapter 9 Firewalls - maybe we could beef up our existing entry on Firewalls to use his example etc. (?). Our stuff is pretty basic.
Chapter 10 Identifiers - again, I imagine Whonix has a lot of this sorted by devs. So we could create a standalone page on standard documentation page called “Identifiers” and outline all these protections that could be done on the host. Another cut and paste job. (I know we cover some of this already e.g. MAC address spoofing, time attacks and keystroke fingerprinting. We wouldn’t duplicate any existing Whonix material).
Chapter 11 File Permissions - already covered in SUID Disabler entry. I gather users could also apply this automatically on their host OS by installing security-misc (?).
Chapter 12 Core Dumps - we already have an entry, but we could beef up the host OS instructions with madadian’s info/steps.
Chapter 13 Swap - I think we already cover off this issue in the Whonix wiki. TBC.
Chapter 14 PAM - I don’t think we cover this off anywhere. Could be cut and pasted into a new page (aimed at both Whonix and host OS?)
Chapter 15 Microcode Updates - we already cover this issue.
Chapter 16 IPv6 Privacy Extensions - I know Whonix is currently IPv4 only so that’s fine. But we could add a page in normal documentation covering this for host OS. Cut and paste job.
Chapter 17 Partitioning and Mount Options - I don’t think we cover this (?). Could be a cut and paste job for a new basic entry (aimed at host OS)
Chapter 18 Entropy - we have a /Dev page that could just rip off this content for specific instructions listed.
Chapter 19 - Editing Files as root - we already have info somewhere re: sudoedit - we could just ‘borrow’ anything here we haven’t already stated.
Chapter 20 - Distribution-specific Hardening - we have some mention of mirror issues, but barely mention seccomp-bpf. We can rip off seccomp text for host OS recommendation (?)
Chapter 21 - Physical Security - we mention some of these issues, but could rip off whatever is missing. Cut and paste job, probably mostly related to host OS.
Basically if we did all this, the Whonix wiki would go from good to “shit hot”.
I don’t see any issues, so long as we have permission to do this i.e. reference madaidan everywhere and explicitly note for chapters that are full cut and paste jobs, something like:
The following material was authored by Whonix developer madaidan and forms Chapter X of The Linux Hardening Guide – see: Linux Hardening Guide | Madaidan's Insecurities. This material has been used with the author’s permission.
Benefits as I see it:
We then have one of the best/complete security hardening guides on the net for Linux.
madaidan gets a lot more eyeballs on his hard work and more traffic to his site.
Users who bother to apply most/all of this will be far better protected.
I am also open for discussion of changes to Whonix Copyright (ideally in separate forum thread). Such as dual licensing with “plain” GPL-3 or GFDL and/or whatever else might be desirable.
Though, since Whonix wiki contents are Freedom Software, i.e. Whonix might be forked one day under the license, we shouldn’t do any “special” ideals. I.e. permission for Whonix only.
Yes, sure. Proper credits where desired are the least that can be done for the many amazing contributions!
Contributors and Authorship - Whonix is for that (on top) and on request I’d provide reference letters (confirming contributions, contributor since, character and whatnot).
Will probably comment on your list if/once licensing/permission is sorted.