On 2017.11.23 22:07, Simon Deziel wrote:
I can't reproduce this after commenting out the "deny @{HOME}/.* r" rule.
Me neither and it's not in Firefox profile either so that's a good sign
that we can safely drop it.
After looking more, if this deny is dropped, then we have to change this:
# rw access to HOME is useful when sending/receiving attachments
owner @{HOME}/** rw,
into similar rules as abstractions/user-write has, with `[^.]*` to not allow to
write to all dot files.
Maybe who wrote that `deny` didn't knew possibility to have `owner
@{HOME}/[^.]* rw`.
If we do that, then we need to document in README.Debian than
signatures can be loaded only from ~/.signature*. I'm not sure that's
good enough to avoid creating a "AppArmor breaks basic stuff, let's
disable it" culture in Debian, which is something I've been trying
hard to avoid for years.
If we capture as much as of these corner cases, only fine minority will have to
disable it.
Even better, maybe we will achieve "modify your local/x.y.foo for your use case" culture, instead of "disable AppArmor"
one, so disable-liking minority will be even smaller.
I'm very tempted to propose we simply disable this profile by default:
I have very little hope at this point that we can make it open enough
to avoid breaking all kinds of corner cases, while keeping it strict
enough to be meaningful at all. Opinions?
I wish Thunderbird could keep its Apparmor profile however imperfect it
is. Thunderbird is used in very different setups and I guess that like
other big graphical applications it's always going to be tough to strike
the balance between secure and functional.
That said, if the maintenance burden is too much I can't blame you from
wanting to have it opt-in instead of being enabled by default.
I'm with Simon. We still have time to fix as much as possible until some critical time point is reached (one of the
freezes?).
