[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Long Wiki Edits Thread

https://www.whonix.org/wiki/Main/Whonix_Signing_Key worthwhile having full output of gpg --keyid-format long --import --import-options show-only --with-fingerprint patrick.asc? I don’t think it’s useful having users ask about minor changes such as new uids (e-mail addresses) or newer expiration dates. One thing more to keep updated in the wiki, which if forgotten, generates support requests.

As per https://www.whonix.org/wiki/Verifying_Software_Signatures#Conceptual_Challenges_in_Digital_Signatures_Verification it’s not useful if users regard it as a copy/paste/compare exercise anyhow.

Therefore previously suggested to focus only on the key fingerprint.

Agree. Fixed in both pages.

PS nothing controversial with the Favicons stuff. Just another day, another tracking mechanism…

Appears that FF is mostly not at risk anyhow due to one of their unresolved bugs and network partitioning in later releases.

1 Like

Looks great!

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.
`

1 Like

Fixed.

4 posts were split to a new topic: Multiple Architecture Documentation (multiarch)

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.

1 Like

This is now implemented. Daily.

Amazing contribution!

Added:

= 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.

1 Like

https://www.whonix.org/wiki/Whonix-Gateway_Own_Traffic_Transparent_Proxy#Introduction

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.

1 Like

Added on sentence to clarify just now to wiki.

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.

1 Like

@madaidan

You have some beautiful stuff here:

Unrelated, but I’ve recently published a Linux hardening guide which you may want to link in the wiki: Linux Hardening Guide | Madaidan's Insecurities

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.

1 Like

:slight_smile:

1 Like

@tempest

Where are we at with the currency of the Email entry in the wiki? It’s probably our most out-of-date entry on the main page?

Is there any updated version of your guide we can rip off to bring it up-to-date? The main thing is of course Enigmail going AWOL etc.

1 Like

Replaced download button (used at Whonix ™ for VirtualBox with XFCE for example). CSS enhancements welcome.

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.

If I get the okay then I’ll go and do all that.

1 Like

Would be good if @madaidan could license works on Linux Hardening Guide | Madaidan's Insecurities (or generally on madaidans-insecurities.github.io).

And would be good if it was compatible with Whonix:Copyrights - Whonix

I am also open for discussion of changes to Whonix:Copyrights - Whonix (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. Surely doable.

A wiki template.

Could also be similar (or in addition) Template:License Amnesia - Whonix as for example used on Design and Goals

Yes, sure. Proper credits where desired are the least that can be done for the many amazing contributions!

Contributors and Authorship 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.

1 Like

Agree with everything you said. We’ll wait to hear from madaidan (fingers crossed).

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]