Hi,
Am 04.12.2017 um 18:46 schrieb Vincas Dargis:
> John was talking about "policy namespaces" on #apparmor:
>
> ```
> [2017 m. november 29 d., wednesday] [21:32:18 EET] <jjohansen> Or a user
> could have a firefox profile, and could edit it
> and load it without being a sysadmin
> [2017 m. november 29 d., wednesday] [21:33:20 EET] <jjohansen> the sysadmin
> could specify a separate firefox profile if
> so desired or they may decide to just have a role type profile on the user
> and let the user worry about differentiating
> their own applications
> [2017 m. november 29 d., wednesday] [21:33:30 EET] <jjohansen> it opens up a
> lot of possibilities
> ```
>
> Not sure when this feature will come up though.
that's probably what I meant to describe.
I would appreciate if any user could add additional rules on top of the
existing profile without extra needed sudo rights. But only with the
possibility to free up restriction inside the users home.
...
> If we had only that `#include_if_exists` (and we don't), this example would
> include rules from all users (that has it
> defined) in the system into one global policy applied to all users, so not
> sure if that's OK. Also, reloading policy
> after applied changes would still need root permissions too. So, we need that
> policy-per-user, a.k.a "policy namespaces"
> as JJ talked about, _if_ I understood that correctly.
Yes, that would solve such issues like this report here.
Some days I've written to intrigeri that AppArmor would need in the long
term some GUI stuff where users can easily inspect the current enabled
profiles, see logging stuff (and if put the above all together) tune up
things within their own access level.
But this all would need some extra new features inside apparmor I guess.
>
>>> I have attached WIP patch that I will propose to AppArmor pull request
>>> myself, but only if you agree with this plan.
>>
>> We can add that change of course as we need to start somethere. For
>> 52.5.0 it's to late now. But I can upload a further version with more
>> apparmor related changes in the next weeks.
>
> Well, if we are bound to wait for "policy namespaces", my patch probably (not
> sure how variable would be handled in that
> way) becomes redundant. If we wait for #include_if_exists, empty file is
> unneeded.
>
> Most realistic approach (IMHO) would still be with an empty file and a new
> @{thunderbird_user_dirs} variable as in the
> patch, so that affected users of this bug report could extend Thunderbird
> policy without modifying main profile (which
> would get overwritten after update), and with writing only one line into
> /etc/apparmor.d/local/tunables/usr.local.bin.thunderbird. Only because
> timeline is within the weeks, not.. well, I do
> not know how long :-) .
If we add the now possible @{thunderbird_user_dirs} directive we need to
think about some migration scenario too. The impact on the user side and
the need to modify their rules set up for a second time must be small as
possible. And a decision based an a broader view need to take care also
about other application profiles that may need some extra rules on some
of the users side too.
Currently I haven't enough time to think about all that various things
nor will I have in the next months unfortunately.
But if you all came up with a solution that will cover most of the
things I happily will trust on intrigeri to collect the right things and
push them into the thunderbird packaging.
--
Regards
Carsten Schoenert
