Control: tag -1 + upstream
Hi,
Philipp Kern:
> On 11/06/2017 09:46 AM, Philipp Kern wrote:
>> Whenever I start Thunderbird I get the following denial from AppArmor:
>>
>> [ 172.585316] audit: type=1400 audit(1509957761.626:72):
>> apparmor="DENIED" operation="file_mmap"
>> profile="thunderbird//lsb_release" name="/usr/bin/python3.6" pid=4268
>> comm="lsb_release" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
>>
>> According to the profile python3.[0-9] is allowed to be read, but not
>> mapped, so it can't actually be executed.
> This is actually a pretty deep rabbit hole. You need to add all of dpkg
> and apt at this point, which would need an abstraction. I stopped after
> adding these: [...]
> And potentially more. A lot of implementation details now leak somewhere
> where they shouldn't leak to. (I suppose lsb_release would actually need
> its own profile in this case?)
Wow, indeed it's a deep rabbit hole.
Wondering what would be the drawback of simply denying execution of
lsb_release, I've investigated a bit. Apparently Thunderbird uses
lsb_release only to append information to crash reports sent upstream.
The crash reporter for Thunderbird is enabled since early 2017.
My understanding of the code is that if Thunderbird does not manage to
get information from lsb_release, it'll just skip that. I think the
lack of distro info makes such crash reports less valuable for
upstream developers, so I'll dismiss the "deny execution of
lsb_release" option.
Taking a step back, confining lsb_release strictly certainly did make
some sense when this profile generally denied execution of random
programs. But given the changes we've applied for #855346, special
casing lsb_release does not make any sense to me anymore: in the
current state of the upstream profile, essentially we treat
lsb_release as more dangerous than the union of
/{usr/local/,usr/,}bin/*. I don't think this is a reasonable
risk assessment.
So I'm going to submit a merge request upstream that drops the special
casing of lsb_release, which Thunderbird will then be allowed to
execute under sanitized_helper.
(At this point my top-priority in Debian is to avoid breaking stuff
with AppArmor. IMO improving policy to provide higher security value
comes later. If/when someone starts working on making the Thunderbird
profile stricter & more useful, I'll encourage them to look at the big
picture and check what attack vectors are worth addressing first.
I doubt lsb_release will be on that list.)
Cheers,
--
intrigeri
