intrigeri:
> anonym:
>> (from what I saw so far I think some people will be sad over it
>> using Qt instead of GTK)
>
> As long as:
>
> * it's Qt5 (let's please stop adding apps that only work with the
> obsolete Qt4; we already ship Qt5 and the corresponding Python
> binding for OnionShare and Audacity anyway);
It was ported to Qt5 in March, yay! :)
> * it integrates nicely in a GNOME desktop (e.g. in terms of HIG ⇒
> consistent UI & UX).
Well, unless I'm mistaken the alternative (the new Tor Launcher) will be in the same situation (non-native, but probably using GTK somehow in the end), so I think it would be unfair to treat a-c-w any different. Needless to say, I want it to look no worse than Tor Launcher currently does, so I don't think there's any disagreement. :)
> What's the design for giving Anon-Connection-Wizard (and thus the
> desktop user) limited privileges on Tor? In other words, is it
> designed with OnionGrater in mind, and with a threat model in which
> the user who runs the GUI is not trusted? (I'm mainly asking because
> of the upcoming switch to Wayland and our strong desire to support
> a11y technologies, various input methods, etc., that all require
> running such a Tor config app as the desktop user.)
tl;dr: migrating to a-c-w actually solves this problem for us, but not for the reason you anticipated.
Long answer: I doubt a-c-w is designed with this in mind (and note that that means its no worse than (old|new) Tor Launcher), since Whonix doesn't use onion-grater like we do -- in Whonix it's used to filter on the host-level, not between processes/users like in Tails.
But if we move to a-c-w we will be able to drop the dedicated user without any negative consequences! Let me explain:
Tor Launcher is a XUL-application so it will run via the (unconfined, FWIW) Firefox binary, so that is the path we must match on in the Tor Launcher filter. That binary is also used by the Unsafe Browser, so to prevent it from accessing the Tor control port we also have to match on user (an alternative solution would be yet another unconfined-firefox copy). Instead of a dedicated user we could match on `amnesia`, but if that user is compromised an attacker could craft a Firefox add-on that runs any commands, and then run it through the Firefox binary as `amnesia` while being subject to the Tor Launcher filter's rather loose permissions (e.g. it can set an attacker-controller proxy => game over). Yup, onion-grater isn't ideal when the target application is extensible (or can run arbitrary code in some other way, e.g. an interpreter) and the filter allows dangerous commands.
However, a-c-w is not extensible, so if we migrate to it we can simply match the onion-grater filter on its path and the `amnesia` user and we're completely locked down to commands that a-c-w can formulate through interaction with its GUI, and not arbitrary ones. So we're good!
Cheers!
