Bug#871441: [pkg-apparmor] Bug#871441: apparmor: Including tunables/sys to tunables/global?
Vincent Blut: > Thanks a lot for handling this! No problem. Note that I have no plans to work on this personally. But perhaps you might want to give it a try?
Bug#871441: apparmor: Including tunables/sys to tunables/global?
Hey,
On Mon, Oct 30, 2017 at 10:41:56AM +0100, intrigeri wrote:
Control: forwarded -1 https://bugs.launchpad.net/apparmor/+bug/1728551
Hi,
John Johansen:
On 09/20/2017 07:32 AM, intrigeri wrote:
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.
Thanks for the explanation. I've filed an upstream bug about this.
Thanks a lot for handling this!
Cheers,
--
intrigeri
Have a good day,
Vincent
signature.asc
Description: PGP signature
Bug#871441: apparmor: Including tunables/sys to tunables/global?
Control: forwarded -1 https://bugs.launchpad.net/apparmor/+bug/1728551
Hi,
John Johansen:
> On 09/20/2017 07:32 AM, intrigeri wrote:
>> 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.
Thanks for the explanation. I've filed an upstream bug about this.
Cheers,
--
intrigeri
Bug#871441: apparmor: Including tunables/sys to tunables/global?
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.
Bug#871441: apparmor: Including tunables/sys to tunables/global?
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?
Cheers,
--
intrigeri
Bug#871441: apparmor: Including tunables/sys to tunables/global?
Package: apparmor Version: 2.11.0-6+b2 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, /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? Cheers, Vincent - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apparmor depends on: ii debconf 1.5.63 ii init-system-helpers 1.49 ii libapparmor-perl 2.11.0-6+b2 ii libc62.24-12 ii lsb-base 9.20161125 ii python3 3.5.3-3 apparmor recommends no packages. Versions of packages apparmor suggests: ii apparmor-profiles2.11.0-6 ii apparmor-profiles-extra 1.12 ii apparmor-utils 2.11.0-6+b2 - -- debconf information excluded -BEGIN PGP SIGNATURE- iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAlmI/uEXHHZpbmNlbnQu ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4COow//UJMfmaQKFfUSXKFzNfBns2cu 4mljJIqO43SHTRyecm9QubL4WqQ1uhU/uXfvSfxw4NZLdjUWaZTS9z5oLZELuTXg sCtQ9crQHrWr/ECb5zLfnZpYCnT5mdZ8mEV1khWYD6EqPe0mpkTi6Dz8GX4eS8/d Mp9UewUTeqzupOfC3WTrgZXpfkuIXUR0/P++DypcrnprGrYflTo6+MBnROPRF3g3 bfyThrKIYyQglOsEjII5UuGGvXnYohPDa+JW4QMm+gX2iF8sdU7X1eQrNOgz5sK8 6JFc5vtqrCLInq+4SmVYGMCH1nYPHz1YaqfCPm+mkJ2Fwn4JVYezZzHV9ACR9wMy YRR+nCeDERoFaGgWaC2P110bI0ezaDtdtfZ0xCyx3xhYpEzqsOyPOKohksLXea8y S9Vm6dZ7Km1K8c6jsE+PjQz89OXh5UiQ2VozMcOymbCSEy/4F3ph+rExSejoSOa+ F2Qo40nw4sC5Th1e1acknMSWRdICIQfPIHX0vZPqAHiD/ADnO0lGU+RZlIhbzpO9 GuTG3FHS7CyCZ68KhoXYXX1otDtY0oGz4bhrY1lvSOxxsKF9zkQJ3d0F4Ut8tsC2 L2UueLXxaYF6Oabh/iXTpcw31VQxi5fUdFQ8dCVdI6XGrdhGQ8q22nn0sULQxtXz BP6nnFrBL1mP7FFSk8M= =Q7Hy -END PGP SIGNATURE-
