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.
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.
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.
--
Regards
Carsten Schoenert
