[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Let's enable AppArmor by default (why not?)

Hello Philip,

Am 29.10.2017 um 14:27 schrieb Philipp Kern:
> On 08/05/2017 01:31 AM, intrigeri wrote:
>> What's the cost for package maintainers?
>> ----------------------------------------
>> For most of them: none at all. As said earlier, our AppArmor policy
>> does not cover that much software yet.
> So how will bug reports work? For instance I turned it on and now I see
> a bunch of warnings[1] from Thunderbird and a bunch of actual failures
> when opening links (which is completely broken), because Thunderbird
> cannot exec google-chrome-beta. What about integration issues where a
> browser should be able to register itself as a browser and hence be
> available from applications that try to open links?
> Right now thunderbird's profile is owned by thunderbird. Is
> thunderbird's maintainer expected to deal with all of these issues?
> Should there be some kind of tool where the apparmor team could
> aggregate the updates? (I.e. routinely review denies?)

in the near past I've forwarded bug reports about apparmor suggestions
and issues to Simon Diezel (CC'd) and also to intrigeri. This works
quite well now due a good responsive behavior of both and I'm really
thankful for this!

Right after the beginning of the apparmor profile for
Icedove/Thunderbird I was a bit skeptic if the shipping of the profile
within the ID/TB packaging will work and is maintainable as I haven't
use apparmor ever before and due this have quite zero experience with
that. I got the impression that the profile would be better under the
hood of the apparmor team as there is much more knowledge about the
working model.
Starting with this thread and by some talking to various people I
changed my mind about this. For better flexibility and customizing,
thinking about various releases (like *-security, *-backports e.g.) that
need to be supported, I believe apparmor profiles for the applications
should stay in the belonging source packages in most cases.
Ubuntu is doing the opposite as far as I know [1], the time will show
which way is batter.

But yes, the maintainers of such packages need the help of the apparmor
folks and also vice versa.

For Thunderbird intrigeri and myself came to the conclusion that
especially for the apparmor profile someone from the apparmor team
should be able to contribute changes to the profile directly to the git
tree. So intrigeri has become a member of the pkg-mozilla group to be
able to push changes by himself. I trust intrigeri enough that he will
do good contributions. For now it's the best we can do. This at all is
for sure improvable and we should talk about this on upcoming Debian
events or directly via email.

> [1] e.g.
> [ 3459.624852] audit: type=1400 audit(1509283082.571:59):
> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
> name="/usr/share/thunderbird/omni.ja" pid=24720 comm="gpg2"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> [2] e.g.
> [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
> apparmor="DENIED" operation="exec" profile="thunderbird"
> name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
> comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I suggest to open a bug report for each of such issues against
thunderbird with a description what was done and what was expected.

[1] https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.10

Carsten Schoenert

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: