Convert /sys to @{sys}

[intrigeri]

John Johansen explained on https://bugs.debian.org/871441 why it will be useful on the long term.
One starting point could be to include tunables/sys in tunables/global, so the @{sys} tunable is readily available and profile authors/maintainers can start using it.

[Vincas Dargis (talkless)]

We have to have in mind that, *for example*, Thunderbird is shipping it's profile even on Debian Jessie, and if we update `tunables/global` *and* all `apparmor-profiles` to use `@{sys}`, and in the meantime if oldstable will not get `tunables/global` update, Thunderbird maintainers will have extra work to maintain two (with/without @{sys}) profiles.

[intrigeri (intrigeri)]

Vincas Dargis:
> We have to have in mind that, *for example*, Thunderbird is shipping
> it's profile even on Debian Jessie, and if we update `tunables/global`
> *and* all `apparmor-profiles` to use `@{sys}`, and in the meantime if
> oldstable will not get `tunables/global` update, Thunderbird maintainers
> will have extra work to maintain two (with/without @{sys}) profiles.

Right, let's avoid proceeding in a backwards-incompatible way.

One solution could be:

1. in every profile that hard-codes /sys, switch to @{sys} and explicitly include tunables/sys
2. include tunables/sys in tunables/global
3. wait until there's no supported distro left that lacks (2)
4. drop "explicitly include tunables/sys" from all profiles

[Vincas Dargis (talkless)]

That's a good plan.

[Vincas Dargis (talkless)]

I believe that `apparmor.git/profiles/apparmor.d/*` profiles (including abstractions) can be updated to the final version in the first run, because they will be pulled together on package update?

Meanwhile, `apparmor.git/profiles/apparmor/profiles/extra/*` and `apparmor-profiles.git/ubuntu/18.04/*` should contain that backwards compatible manual `tunables/sys` include, with a TODO:

```
TODO: remove after relevant distributions has updated "tunables/global" to include "tunables/sys"
```

Is that right?

[Christian Boltz (cboltz)]

I'm afraid you have to coordinate the change better - declaring a variable twice causes a parser error:

# echo '@{foo} = x
@{foo} = y' | apparmor_parser -pq

@{foo} = x

@{foo} = y

'foo' is already defined
AppArmor parser error, in stdin line 3: variable @{foo} was previously declared

[Vincas Dargis (talkless)]

On 2017-12-04 16:52, Christian Boltz wrote:
> I'm afraid you have to coordinate the change better - declaring a
> variable twice causes a parser error:

Thanks! Duplicate rules manages to merge, but not variables...

1. We have to be aware for profiles that _already_ includes tunables/sys then...
"Downgrade" them to not use "@{sys}" (remove include "tunables/sys" too!).

2. Then, update "tunables/global" together with "apparmor.d/abstractios" and "apparmor.d/*" profiles in one go.

3. Finally, only after all these have been shipped on all relevant distributions, we can update profiles from
"profiles/extra" directory and "apparmor-profiles" repository, and the else (Libreoffice that has it's own, etc).

[Vincas Dargis (talkless)]

Looks like in Debian ther's only hplip, dbus, chrony that has <tunables/sys> included:

https://codesearch.debian.net/search?q=tunables%2Fsys

I wonder if there are any extra profiles in Ubuntu, and what about OpenSUSE? Is there a code search tool somewhere?

[Vincas Dargis (talkless)]

What should happen to `<tunables/securityfs>`?

https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/tunables/securityfs

It includes <tunables/sys>, so that include should go away, because <tunables/global> are always included in actually every policy file, right?

[Vincas Dargis (talkless)]

I forgot another step:

4. Delete tunables/sys file from repo, as it is now redundant.

[Vincas Dargis (talkless)]

I believe I misunderstood something. I thought that @{sys} would go into "kernelvars" because John mentioned restriction that @{sys} path should be actual "sysfs", i.e. being "magic" variable some time in the future.

If "kernelvars" would have @{sys} defined, then that step #4 deleting "tunables/sys" would be needed.

If it's only about including "tunables/sys" into "tunables/global" then of course "tunables/sys" should stay.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871441#17

[Vincas Dargis (talkless)]

OK let's forget that step 4 and all that kernelvars diversion. Goal is to make "tunables/global" have "#include <tunables/sys>" in a safe transition, any other changes can follow later if needed.

[Vincas Dargis (talkless)]

https://gitlab.com/apparmor/apparmor/merge_requests/228

[Vincas Dargis (talkless)]

I doubt I would call it "Fix Released", as AppArmor profiles and abstractions are not yet upgraded to use @{sys}. I left these for "second pass" MR.

[intrigeri (intrigeri)]

OK!

[Vincas Dargis (talkless)]

Now I consider this task as finished:

https://gitlab.com/apparmor/apparmor/merge_requests/262
https://gitlab.com/apparmor/apparmor/merge_requests/265
https://gitlab.com/apparmor/apparmor/merge_requests/278

(no backports for 2.11 and 2.12 because maintainers doubt about the need of it)

[intrigeri (intrigeri)]

Vincas Dargis:
> Now I consider this task as finished:

Congrats! \o/