On 12/04/2017 10:16 AM, Vincas Dargis wrote:
> On 2017-12-04 19:53, John Johansen wrote:
>> On 12/03/2017 04:05 AM, intrigeri wrote:
>>> At first glance I would essentially apply the same path structure as
>>> what we do for top-level profiles:
>>>
>>> * `tunables/usr.bin.thunderbird`, shipped by the package, has the
>>> default settings
>
> Oh, I missed that part. So we move variables from
> apparmor.d/usr.bin.thunderbird into that file then?
> And that particular file would includ local/tunables-one?
>
> I actually see this a little too complicated. Imagine moving these bunch of
> Libreoffice variable definitions away from main profile. Policy kinda becomes
> two-part profile in the sense, a little harder to grasp maybe. Although I
> agree that would be kinda systematic approach.
>
>>>
>>> So this seems to be yet another use case for a directive like
>>> #include_if_exists (or #include -<path/to/snippet>, to reuse systemd
>>> conventions wrt. directives that are allowed to fail). I've had
>>> a quick look (disclaimer: I'm not a C person and know nothing about
>>> flex parsers) and it seems this should not be very hard to implement
>>> in parser/parser_lex.l. Maybe we could discuss the interface and
>>> behavior of this new/updated directive in a dedicated thread, and once
>>> we've reached an agreement I could try to find someone to implement it?
>>>
>> yes very easy to implement, its mostly agreeing on the syntax
>
> John, what's your view about using variable-include-file-as-extension-point
> in the dawn of the per-user policy files?
>
Includes should already support variable expansion, I remember doing
the work to enable this years ago, though I have to admit I haven't
tested it for quite some time so its conceivable something is
broken. ie
Include <@{user}/foo>
should do the right thing if @{user} is defined.
Leveraging it for user profiles is a little more tricky, and I do want
to be careful. Because while the variable include works we don't
automatically generate different profiles for each user, at least not
yet.
> Maybe this proposition will become redundant in some sence? How would
> variables usage would play in the policy namespaces use case? Will there be
> sort of $HOME/.config/apparmor/tunables/usr.bin.thunderbird ?
>
>
So its not entirely redundant in the policy namespace use case. For
one we have to actually start leveraging them, and it will be a long
time before we will be able to use them as the standard base because
not everything we need for them has landed upstream yet.
Policy namespaces in and of themselves do nothing to fix the problems
you are trying to address, they just provide a convenient place to
have different use case profiles, so a different thunderbird for one
user than another. We still need a way to update profiles so that they
apply to a specific user or role. The plan has been to use variables
;-). Well its a little more than that, but the idea is to eventually
have some kernel defined variables and allow them to be defined at
system or the namespace level. That should just change at what point
the variable is expanded, and maybe whether a profile can be
reused/shared to reduce kernel memory usage. The first pass plan was
to define the variables in userspace (look at @{pid} which will be
replaced by a kernel var) and later once we grow the proper support
change the variable define to that of the kernel var.
I should also note some kernel vars will be entirely kernel defined
while other will be able to be defined in userspace and loaded into
the kernel. If we are to ever support a username variable, it will
be the later, the kernel will have no idea of the contents of the
variable stream just that it should map a give uid to the string
variable that userspace is free to define and load.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
