Doesn’t work. Tried the following:
In Whonix-WS TemplateVM, created a torbrowser.profile in /etc/firejail
Cut and pasted the following text (commented out stuff at very bottom, which otherwise causes failures):
# Firejail profile for tor-browser-en
# This file is overwritten after every install/update
# Persistent local customizations
include /etc/firejail/tor-browser-en.local
# Persistent global definitions
include /etc/firejail/globals.local
blacklist /boot
blacklist /media
blacklist /mnt
blacklist /opt
blacklist /usr/local/bin
blacklist /var
whitelist ${HOME}/.tor-browser-en
whitelist /dev/dri
whitelist /dev/full
whitelist /dev/null
whitelist /dev/ptmx
whitelist /dev/pts
whitelist /dev/random
whitelist /dev/shm
whitelist /dev/snd
whitelist /dev/tty
whitelist /dev/urandom
whitelist /dev/video0
whitelist /dev/zero
include /etc/firejail/whitelist-common.inc
caps.drop all
noroot
seccomp
shell none
# private-bin bash,grep,sed,tail,tor-browser-en,env,id,readlink,dirname,test,mkdir,ln,sed,cp,rm,getconf,file,expr
# FIXME: Spoof D-Bus machine id (tor-browser segfaults when it is missing!)
# https://github.com/netblue30/firejail/issues/955
# private-etc X11,pulse,machine-id
# private-tmp
# noexec /tmp
Save and exit.
Close the Whonix-Workstation TemplateVM and start the Whonix-Workstation AppVM.
Started the application by opening a terminal and running:
$ firejail torbrowser
Whonix complains:
“Tor Browser is not installed at (location). Do you want to install it now?”
Which is not the case.
Anyway, I tried. Moving onto something useful (FAQ edits).
1 Like
Probably because I need to whitelist the correct directory explicitly
/home/user/.tb/tor-browser
1 Like
Patrick
Split this topic
January 19, 2018, 3:56pm
424
iry
January 20, 2018, 6:20am
426
Off topic:
1. ⚓ T422 keep an eye on tor-monitor
Can be closed.
Since it was renamed to onioncircuits, packaged in Debian (onioncircuits - Debian Package Tracker ) and iry had this added to Whonix 14 (anon-workstation-packages-recommended) already:
onioncircuits - Viewing the status and circuits of Tor
2. ⚓ T399 Switch Debian links in sources.list to .onion (.onions in sources list) is noted as done for Whonix 14, so I presume it can also be closed.
1 Like
On Template “Payments”, suggest you change:
This is not tax advice. Corporations who purchase priority support packages may be able to tax deduct these as an expense. Ask a tax advisor.
To →
This does not constitute tax advice. Corporations who purchase priority support packages may be able to claim these as tax-deductible expenses. First consult a tax advisor.
iry
January 22, 2018, 6:00am
429
The HTTPSEverywhereUserRules trick introduced in Adding User Rules section does not work anymore for me. This is probably due to the Web-extension migration on HTTPSEverywhere.
I have submitted an issue to see how we can get it work:
opened 05:47AM - 22 Jan 18 UTC
closed 07:06PM - 22 Jan 18 UTC
Type: ruleset issue
Dear HTTPSEverywhere Developers,
I tried to use HTTPSE… verywhereUserRules in the latest Tor Browser according to [the instructions](https://github.com/EFForg/https-everywhere/issues/9958#issuecomment-321452120) by @Hainish :
> To add custom rules, you can still add them to your HTTPSEverywhereUserRules path, and subsequently change the extensions.https_everywhere.webextensions-migrated pref to false so that the extension knows to run another migration.
However, it seems there is no such a preference in about:config in TBB by default.
Therefore, I opened the about:config in Firefox 57, finding a preference called `extension.https_everywhere.webextension-migrated` (which is different from what @Hainish said: `extensions.https_everywhere.webextensions-migrated`).
To trigger a re-import of my custom rules, I did the following steps:
- put my custom ruleset to HTTPSEverywhereUserRules direcotry
- toggled the value `extension.https_everywhere.webextension-migrated` to false
- created a new pref called `extension.https_everywhere.webextensions-migrated` and set the value to false
- restarted the Firefox
However, it seems the rules I set in HTTPSEverywhereUserRules does not work.
For your information, the ruleset I used is Browser/profile.default/HTTPSEverywhereUserRules/WhonixOnion.xml . The content is as follows:
```
<ruleset name="Whonix Onion">
<target host="whonix.org" />
<target host="www.whonix.org" />
<target host="phabricator.whonix.org" />
<target host="forums.whonix.org" />
<target host="download.whonix.org" />
<target host="deb.whonix.org" />
<rule from="^https?://(.*\.?)whonix\.org/" to="http://$1kkkkkkkkkk63ava6.onion/"/>
</ruleset>
```
I did notice that later, @Hainish said in #11977 that:
> Adding new rules to the HTTPSEverywhereUserRules directory will not work after the one-time migration in the Embedded WebExtension (>= 2017.8.15) is performed. If you had old rules, they were migrated to the new extension.
> To add new custom rules, you'll have to use the popup by visiting the https version of the site you want to add a rule for, clicking the extension icon, and clicking "Add a rule for this site".
Therefore, would you tell me if HTTPSEverywhereUserRules is still supported by WebExtensions version? If it is supported, would you please educate me on:
1. How I can use HTTPSEverywhereUserRules in Firefox 57?
2. How I can use HTTPSEverywhereUserRules in Tor Browser 7.0?
Thank you so much for your great work and time! I really appreciate it!
3 Likes
iry
January 22, 2018, 10:49pm
430
I got the answer from the HTTPSEverywhere developer:
HTTPSEverywhereUserRules/ is not supported with WebExtensions and won’t be supported. My understanding is that security restrictions for WebExtensions block it from reading from the filesystem in the way that the HTTPSEverywhereUserRules/ approach needed.
I have updated the Wiki page:
4 Likes
Patrick
January 24, 2018, 10:53pm
431
torjunkie:
On Template “Payments”, suggest you change:
This is not tax advice. Corporations who purchase priority support packages may be able to tax deduct these as an expense. Ask a tax advisor.
To →
This does not constitute tax advice. Corporations who purchase priority support packages may be able to claim these as tax-deductible expenses. First consult a tax advisor.
Done.
(Plus another small change.)
1 Like
Patrick
January 27, 2018, 1:25am
432
Should we ever move away from mediawiki to another web app… Please veto if you dislike the editing usability of the new web app…
I guess there is a reason why the Qubes website gets relatively fewer contributions… Github web editing is not comfortable…
Patrick
Split this topic
January 31, 2018, 11:42am
433
3 posts were merged into an existing topic: Forcing .onion on Whonix.org
Patrick
February 2, 2018, 12:53pm
434
Good read on USB security:
opened 10:38PM - 01 Feb 18 UTC
closed 10:26AM - 02 Aug 22 UTC
T: enhancement
C: other
ux
P: default
Even if the system have only one USB controller, and only USB keyboard, creating… USB VM, with [`qubes.InputKeyboard` service, part of input-proxy, enabled](https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard) still makes some sense. While USB VM will be able to spy and/or subvert the keyboard, user will see resulting actions. Malicious USB device will not be able to exploit some dom0 kernel driver, silently in the background. And when bundled with [some 2FA](https://www.qubes-os.org/doc/yubi-key/), malicious USB VM will not be able to unlock the screen on its own.
Besides enabling `qubes.InputKeyboard` service, there is one more problem: USB controllers are blacklisted in dom0 (specifically: connected to xen-pciback driver, before loading actual USB controllers drivers) - this prevents entering LUKS passphrase using USB keyboard.
For now, lets ease the basic thing:
- do not blacklist USB controllers early (only just before actual starting USB VM)
- enable qubes.InputKeyboard service
To (semi-)securely use it, user is responsible for disconnecting any untrusted USB device from the system for the boot time. Note that this (unfortunately) should be a standard routine even in non-USB keyboard case, because BIOS (also having USB drivers) potentially could be exploited by malicious device at early boot stage too.
Later, we can employ additional protection, using [usb device authorization](https://www.kernel.org/doc/Documentation/usb/authorization.txt), to allow only HID devices and only for the LUKS passphrase entering time. This is still far less protection than USB VM + input-proxy, but something better than allowing all devices.
Some long term solution could be bundling minimal USB VM with input-proxy into initramfs, but at this level of complexity (and required work), it may be better to simply adjust hardware configuration instead (like installing separate USB controller for this).
This is related to #2959, #2116, #3203
FAQ -> Done (finally)
I think we should cut the tiny section existing in it’s own page (VFAQ) into the FAQ itself and delete that VFAQ page. And also shift up FAQ to the Download section on main TOC page.
Agree?
@Patrick
I think when you did that auto-run on removing certain pages from translation in the last few days, it returned the page edits (including some templates) to their very old (rough) versions.
E.g. look at the Advanced Security Guide. It’s back to where it was a year ago (?) before I spent weeks (months?) fixing it up. There are multiple other pages like that.
Please revert that change, or whatever caused it. It would be very, very painful to try and track down each individual page manually that is back to old, dodgy English and revert them to latest edits.
I also noted Whonix Release Notes disappeared off the main TOC (why? same reason when doing some auto thing on the main documentation page?)
I’ll hold off on edits till then, because if all that work is lost for good…
I see it also affected DoNot, various templates etc.
Could also explain bad links and comments like this on Twitter today:
@Whonix Fix download link for virtualbox gateway/workstation!
View details · Reply Retweet Like
Patrick
February 3, 2018, 1:10pm
437
Weird. Thanks for noticing. Hopefully I figure out how to fix that.
It was never added as far as I know. For sure didn’t manually remove it. Thanks for adding it!
Patrick
February 3, 2018, 1:13pm
438
It’s official: I hate mediawiki translate extension!
If you find a broken page… Please go to history… Page → History
Permission error - Whonix
(Removed page from translation) (rollback 10 edits | undo)
I will try that.
1 Like
Patrick
February 3, 2018, 1:23pm
439
Do you have a list of some examples of broken pages?
The good news is nothing is lost. For once, we have mysql backups (but then we’d loose the work after the translation unmark, so we’d need to back that up first before we roll back). Also not sure forum and wiki can be separately restored, fortasse would know. Secondly, if we can identify the broken pages, the rollback can be rolled back.
Patrick
February 3, 2018, 1:30pm
440
Basically just undo
Removed page from translation
. Not rollback. (That would rollback any changes by me alter later ones.)
1 Like
Patrick
February 3, 2018, 1:33pm
441
Now - I really have to - temporarily - undo your last commit on /Documentation. Otherwise…
The edit could not be undone due to conflicting intermediate edits.
I keep a list of undone edits and then manually reapply.