Hello,
On 2019-05-02 10:58 a.m., Carsten Schoenert wrote:
> Hi,
>
> Am 02.05.19 um 09:05 schrieb Ulrike Uhlig:
>>> Well, but who has enabled AA in PC? I'm sure that I have not worked on
>>> /etc in these days and I am the only one can access on it. In my opinion
>>> there is a bug in some package update that has enabled TB AA profile...
>>> but in effect I realize that to be believable someone else would find
>>> this unbelievable behaviour...
>>
>> Maybe you accidentally upgraded to Buster or you are using a kernel that
>> has AA enabled by default.
>
> the starting email of this bugreport is showing an installed kernel from
> backports. So for me it's quite obvious *why* apparmor is installed and
> has activated all the profiles for the various packages that come along
> with AA profiles which should be also activated then.
>
>> Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
>> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
>
> I can remember we have such discussions again and again from time to
> time and users are surprised why Thunderbird isn't working any more as
> usual or expected after some random update. So far I remember it was
> always an active TB AA profile. And users are even more surprised if I
> tell them the TB packaging in Stretch did never had an automatically
> activated AA profile, in other words, they have it activated it by
> themselves.
>
> In this report there are two things that have come together in my eyes.
>
> 1.) An activated AA profile for Thunderbird.
>
> 2.) An different path for ${HOME} because of an membership within a
> Windows domain.
>
> The first one isn't a big problem anymore in newer days, the current AA
> profile is covering for sure about 95% of the use cases.
Agreed.
> The second point isn't covered nicely until now in the AppArmor
> installations within Debian at least. But I think also that Thunderbird
> isn't the only package that will suffer from this problem and we will
> need a more general solution for this. And this needs to go into
> Apparmor itself instead of every body tries to implement some super
> logic within their AA package profile.
Thunderbird is definitely not the only package affected. There already
is a way to deal with non-standard home path: local adjustment of the
'tunables' provided by Apparmor. Those will affect every profile using
the @{HOME} variable.
> Currently I've no idea how to detect a membership of a Windows domain
> nicely, for sure this is solvable by some PAM voodoo. I have simply no
> knowledge in this area. And I have no environment to test something. It
> seems we just need to trigger a dpkg-reconfigure of AA if the PC is
> within a domain membership.
I don't think it's specific to domain members as all it takes is to have
a home dir located somewhere non-standard (!= /home/$user) as the
default value for @{HOME} only permits what's common.
That said, having a dpkg-reconfigure trigger when $HOME non-standard
might be an idea, but that's a concern for Apparmor itself, not
Thunderbird :)
Regards,
Simon
