[Tails-dev] AppArmor policy vs. hard links [Was: MFSA 2015-7…

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: The Tails public development discussion list
Assumptes vells: Re: [Tails-dev] MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails
Assumpte: [Tails-dev] AppArmor policy vs. hard links [Was: MFSA 2015-78 (aka. CVE-2015-4495) vs. Tails]
Hi,

Jacob Appelbaum wrote (07 Aug 2015 12:33:10 GMT) :
> If you hard link a file say, /home/amnesia/.gnupg/secring.gpg into
> ~/Tor Browser/secring.gpg - you can read it with Tor Browser. AppArmor
> uses file paths to constrain things. That second file path is allowed
> by the sandbox, even though the file is also "outside" of that path,
> AppArmor has no clue.


Right, thanks for refreshing my memories :)

> Reading the policy for Tor Browser on Tails 1.4.1 - I see the
> following relevant entries:
> [...]
> Note that none of those include the flag "l" - which is what is
> required to make a hard link. That was why I said "until an attacker
> figures out how to make a hard link"; if such a hardlink were made,
> they'd be able to read the contents of the linked file. That is all
> that I meant with my comment. AppArmor is useful but has some rough
> edges.


OK. I've filed https://labs.riseup.net/code/issues/9949 about it, and
after an initial evaluation of our current AppArmor policy, it seems
everything is good... except the I2P confinement, but that one is
still WIP (#7724), and the version we currently ship should merely be
regarded as a technology preview, that's only marginally better
than nothing.

It would be awesome if someone double-checked my findings. E.g.
the regexp I've used might be buggy and miss some problematic rules.
Jacob, perhaps?

Cheers,
--
intrigeri