Isis Lovecruft [Mon, 27 Oct 2014 20:05:16 +0000 (20:05 +0000)]
Switch to using new Tor Project dist URL.
If I recall correctly, weasel (Tor Project's volunteer lead sysadmin)
tried to switch everything to using https://dist.torproject.org/ last
week, and then added an Apache redirect from
https://www.torproject.org/dist to https://dist.torproject.org after
discovering that some things were still trying to use the old URL. We
should switch to the new one, so that someday weasel can remove the
redirect.
* CHANGE `default_mirror` to https://dist.torproject.org/
AppArmor: allow start-tor-browser to read /usr/share/zenity/zenity.ui.
When start-tor-browser runs zenity (under the start-tor-browser confinement),
unsurprisingly that one needs to read its own files. On current Debian unstable,
this includes /usr/share/zenity/zenity.ui.
AppArmor: allow start-tor-browser read access on dash.
We already do this for most other executable files start-tor-browser runs.
No idea why it used to work without this permission, but oh well, it now
needs it.
Grant the browser read access on its profile directory.
For some reason, it now needs this to work properly. Given we already grant it
write access to all child files and directories, this seems to make sense.
intrigeri [Sat, 16 Aug 2014 10:03:06 +0000 (10:03 +0000)]
Disable audio abstraction by default.
The person who added it also wrote "I have never managed to get the sound
working in the Tor Browser either, on YouTube or even playing an MP3", which
shows that including this abstraction by default gives no practical benefit, but
opens the attack surface substantially.
intrigeri [Thu, 14 Aug 2014 18:03:34 +0000 (18:03 +0000)]
Disable the user-download abstraction and corresponding addition, by default.
This partially reverts changes introduced in commit 04b24660, without any
explanation. Those changes actually allow TBB to read e.g.
`@{HOME}/[a-zA-Z0-9]*`, that is most of users' personal files, which defeats in
great part the purpose of this profile. Likewise for read access to `@{HOME}/`,
which quite often contain folders whose name users might not want to leak.
Still, some people might want to use this, so let's leave these rules in here,
but commented out, explaining what the consequences of enabling them are.
intrigeri [Thu, 14 Aug 2014 18:00:03 +0000 (18:00 +0000)]
Don't allow Firefox to access Tor's data directory, nor to map files in the Tor system directory.
These credentials are apparently not needed anymore. I suspect that they
are remaining from a time where there was no dedicated profile for Tor,
that was running under the same confinement as Firefox, or something
similar.
intrigeri [Thu, 14 Aug 2014 17:38:06 +0000 (17:38 +0000)]
Don't make potential AppArmor deny logs about @{PROC}/[0-9]*/task/** and @{PROC}/[0-9]*/fd/ silent.
These deny rules were added, without any explanation, in commit 04b24660.
I've never seen Firefox try to break these rules. If someone sees that, then I'm
happy to see the corresponding logs, and then we can research whether the
consequences of letting Firefox access this file are any worse than the
consequences of blocking this access.
intrigeri [Thu, 14 Aug 2014 17:32:38 +0000 (17:32 +0000)]
AppArmor: allow Firefox to access mountinfo.
It's used in the GetDeviceName function (xpcom/io/nsLocalFileUnix.cpp), which is
in turn used by nsLocalFile::GetDiskSpaceAvailable. With this in mind, it's not
clear to me what the consequences of not letting Firefox access this information
are. E.g. it may very well let the user start downloading a file that won't fit
on disk.
So, unless good reasons are provided for blocking access to this file, I'm
allowing Firefox to read it.
intrigeri [Thu, 14 Aug 2014 17:25:54 +0000 (17:25 +0000)]
AppArmor: allow Firefox to read processes and tasks' stats.
This partially reverts commit 04b24660, that made the opposite change for
reasons that are unknown to me.
stat files are used in the JiffiesSinceBoot function
(xpcom/ds/TimeStamp_posix.cpp), which is used to compute process lifetime.
The consequences of blocking this access are unclear to me: it might plug issues
wrt. anonymity that the Tor Browser team would have missed (ask them?), but it
can as well introduce security issues by forcing Firefox to downgrade to worse
sources of information. If crypto is in play there, we would be playing
a dangerous game by blocking Firefox from accessing this information.
intrigeri [Thu, 14 Aug 2014 17:02:50 +0000 (17:02 +0000)]
AppArmor: allow Firefox to learn how many CPU cores are present.
This was added in commits ace00d646 and a3908af8 already. Then, commit 04b24660
made the opposite change for reasons that are unknown to me.
Firefox can optimize things a bit depending on this information, which does not
seem terribly critical, and can probably be gathered by other means anyway,
given the current profile.
In the Firefox source code, this file is used in the PR_GetNumberOfProcessors
function, that itself is used e.g. in image/src/RasterImage.cpp to make use of
all available CPUs. Now, if someone shows that this information is leaked
on the network, and cannot be retrieved by other means given the same threat
model, then possibly it'll make sense to block this access... or to suggest
to the Tor Browser people to patch it out and always use one core only,
which would solve the (potential) problem also for people not using AppArmor.
intrigeri [Thu, 14 Aug 2014 16:53:26 +0000 (16:53 +0000)]
AppArmor: allow Firefox to get entropy from @{PROC}/sys/kernel/random/uuid.
First, note that this file returns a different uuid each time it's read.
I'm not sure what Firefox does when it can't get a random UUID from there. If it
falls back to a fixed value, this might have problematic security implications:
randomness is sometimes useful for security purposes. The only place I could
find this file being used in the Firefox source tree is actually in the
`arc4_seed_proc_sys_kernel_random_uuid` function. If that's really why Firefox
tries to access this file, then I don't think we should block it.
I've not seen that file being accessed by Firefox personally. But given
troubadoour added it, and it can be found in the Firefox source code, with the
above reasoning in mind, it seems that the safest thing to do is to allow
Firefox to get the randomness it needs.
intrigeri [Thu, 14 Aug 2014 16:47:41 +0000 (16:47 +0000)]
Remove probably useless commented out AppArmor rules.
These rules are mostly duplicates from ones that are already in the `fonts`
abstraction, that we transitively include, so it's unclear to me when they
may be needed.
Note that the only difference between the abstraction's rules and these ones is
the "k" access granted on /var/cache/fontconfig/, which feels odd: even if
a non-root user is allowed to do that, none of my other confined
fontconfig-using applications need that, so I would be surprised if Firefox used
fontconfig in a way that requires locking that directory. Still, if I'm shown
rejection logs that show it's needed, then I'm happy to add it back... and then,
perhaps it will make more sense to push it to the upstream fonts abstraction.
intrigeri [Thu, 14 Aug 2014 16:44:54 +0000 (16:44 +0000)]
AppArmor: enable Firefox to use GStreamer, again.
I've added these rules in 9d38e775 already. Now, commit 04b24660 made the
opposite change, for reasons that are unknown to me, while at the same time it
added direct access to sound devices, which seems inconsistent. So, I'm
reverting to the previous state.
If these rules are not consensual, let's discuss them instead of silently
dropping them. Thanks in advance.
intrigeri [Thu, 14 Aug 2014 16:41:11 +0000 (16:41 +0000)]
AppArmor: give back read access on /usr/share/gnome/applications/ and /usr/share/gnome/applications/kde4/ to Firefox.
These are places where more .desktop files, that Firefox uses for filetype
association information, can be found on some systems, e.g. Debian unstable.
This is why I have added these rules in commit d033d07e. So, I'm reverting
commit 04b24660, that made the opposite change for reasons that are unknown
to me.
intrigeri [Thu, 14 Aug 2014 16:38:22 +0000 (16:38 +0000)]
Drop AppArmor rules that are duplicate of ones found in abstractions we include, again.
I have done this already in commit 8db75b7c0. The commit message documented why.
So, this very commit is partially reverting commit 04b24660, that made the
opposite change for reasons that are unknown to me. Yay.
intrigeri [Thu, 14 Aug 2014 16:33:48 +0000 (16:33 +0000)]
AppArmor: give back read access on /etc/mailcap to Firefox.
This partially reverts commit 04b24660, that made the opposite change for
reasons that are unknown to me.
This profile gives access to other kinds of file association, e.g.
the .desktop files found in /usr/share/applications/, so one wonders
why /etc/mailcap should be treated differently.
intrigeri [Thu, 14 Aug 2014 16:31:31 +0000 (16:31 +0000)]
Make AppArmor logs silent about Firefox trying to read /etc/machine-id.
This was done recently for /var/lib/dbus/machine-id, and Firefox apparently
falls back on /etc/machine-id if it cannot read the former, so this change
should make things more consistent.
intrigeri [Thu, 14 Aug 2014 16:26:05 +0000 (16:26 +0000)]
AppArmor: allow start-tor-browser to run some programs it needs.
These might be needed only when using the 4.x branch of TBB. Or, they were
always needed, but we didn't notice as torbrowser-launcher was apparently
running start-tor-browser unconfined.
intrigeri [Thu, 14 Aug 2014 16:23:07 +0000 (16:23 +0000)]
Explicitly run Tor with its own AppArmor profile.
Commit 04b24660 changed the way Tor is run, from Px to rix.
Px exec's to profile that matches executable name, with environment
variable scrubbing. rix makes the child process inherit the current
process' confinement. Given we ship a `torbrowser.Tor.tor` profile,
we'd better use it than inherit the browser's confinement.
Leif Ryge [Mon, 11 Aug 2014 03:42:32 +0000 (03:42 +0000)]
make SHARE point at TBL's share directory
also stop using /usr/local/share/torbrowser-launcher/mirrors.txt as a secondary
mirrors list, and start including one from the config directory instead.
projects / torbrowser-launcher.git / log