[pkg-apparmor] Bug#871441: apparmor: Including tunables/sys to tunables/global?

[John Johansen]

On 09/20/2017 07:32 AM, intrigeri wrote:
> Control: tag -1 + upstream
> 
> Hi,
> 
> Vincent Blut:
>> /etc/apparmor.d/tunables/proc being part of
>> /etc/apparmor.d/tunables/global, I’m wondering if there are any reasons
>> preventing the sysfs pseudo file system location variable (defined in
>> /etc/apparmor.d/tunables/sys) from being included as well?
> 
> Good question! I have no idea.
> 
> I see that tunables/sys was introduced in 2012 by John (Cc'ed) as part
> of a commit that adds "abstractions to support the apparmor api".
> On my system, nothing uses these abstractions nor the @{sys} tunable.
> So I admit I have no idea what problem @{sys} is meant to solve.
> If it _is_ useful then it should be used everywhere instead of /sys/,
> which requires quite some work for no obvious (to me) benefit.
> 
> John, what do you think?
> 
yeah, I think it would be worth starting to do the conversion of
/sys/ to @{sys} as has been done with /proc/ to @{proc}

with that said I haven't ever seen sys mounted somewhere different
than /sys/ where I have seen that for proc.

The big win of course is when fstype conditionals land at which
point @{sys} could be further restricted to be /sys/ with and
fs type of sysfs or even allowing disconnected access to sysfs.

As for why this was introduced as part of the api abstraction
profile management is done through sys and you probably haven't
seen it because its not currently common to confine services
doing profile management.

I expect that will change more in the future as we open up policy
namespaces more, which will safely allow users and applications
to load their own policy.