Autore: Jacob Appelbaum Data: To: The Tails public development discussion list Oggetto: Re: [Tails-dev] AppArmor policy vs. hard links [Was: MFSA 2015-78
(aka. CVE-2015-4495) vs. Tails]
On 8/8/15, intrigeri <intrigeri@???> wrote: > 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 :)
Sure thing.
>
>> 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.
>
Ok.
> 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?
>
I wouldn't call it an audit but I agree with your initial findings.
