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