** Description changed:
SRU Justification:
[ Impact ]
lsblk would segfault when run from a confined context due to missing
permissions on the binary execution path, and the lsblk profile need
- rules to give m+r permissions for the binaries themselves.
+ rules to give m+r permissions for the binaries themselves. One example
+ of where this would occur is if lsblk was run inside a confined
+ container.
[ Test Plan ]
* Add the following to a new file and use `apparmor_parser path/to/file` to
load it as a profile:
abi <abi/4.0>,
include <tunables/global>
profile allow_all {
allow all,
priority=1 /** px,
}
- * Choose a subset of the applications confined by profiles under
profiles/apparmor.d modified by
debian/patches/ubuntu/profiles_ensure_access_to_attach_path.patch, and for each
selected application:
- - Run `aa-exec -p allow_all -- lsblk`
- - Verify that the application does not segfault on launch
- - If application segfaults on launch only when run under confinement,
check for apparmor="DENIED" log entry denying read or mmap operations on the
binary path, and report verification test failure
+ * Run `aa-exec -p allow_all -- sh -c 'lsblk'`
+ * If a profile for lsblk is not loaded, sh will report a permission denial
on the exec transition when attempting to execute lsblk. If this occurs, report
verification test failure
+ * Verify that the application does not segfault on launch
+ * If application segfaults on launch only when run under confinement, check
for apparmor="DENIED" log entry denying read or mmap operations on the binary
path, and report verification test failure
[ Where problems could occur ]
The lsblk profile update loosens confinement on a profile. However, if a
user manually modified the installed profile, then the package upgrade
would cause conflicts, and rejection of the incoming changes (either by
hand during an interactive upgrade or automatically during an batch
unattended upgrade) would result in end users not getting the packaged
fix.
[ Other Info ]
__________
Hey,
while debugging bug 2107402 we found that there is more to fix.
Running lsblk in a container on s390x hits this:
[12064869.934674] audit: type=1400 audit(1744791155.353:111962):
apparmor="DENIED" operation="file_mmap" class="file"
namespace="root//lxd-p_<var-snap-lxd-common-lxd>" profile="lsblk"
name="/usr/bin/lsblk" pid=3286747 comm="lsblk" requested_mask="rm"
denied_mask="rm" fsuid=1000000 ouid=1000000
To the user it just segfaults.
root@p:~# lsblk
Segmentation fault
root@p:~# aa-disable lsblk
Disabling /usr/bin/lsblk.
root@p:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 93.8M 1 loop
loop1 7:1 0 94M 1 l
...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2107455
Title:
segfault of lsblk s390x in containers due to apparmor
Status in Ubuntu on IBM z Systems:
In Progress
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Plucky:
In Progress
Status in apparmor source package in Questing:
Fix Released
Bug description:
SRU Justification:
[ Impact ]
lsblk would segfault when run from a confined context due to missing
permissions on the binary execution path, and the lsblk profile need
rules to give m+r permissions for the binaries themselves. One example
of where this would occur is if lsblk was run inside a confined
container.
[ Test Plan ]
* Add the following to a new file and use `apparmor_parser path/to/file` to
load it as a profile:
abi <abi/4.0>,
include <tunables/global>
profile allow_all {
allow all,
priority=1 /** px,
}
* Run `aa-exec -p allow_all -- sh -c 'lsblk'`
* If a profile for lsblk is not loaded, sh will report a permission denial
on the exec transition when attempting to execute lsblk. If this occurs, report
verification test failure
* Verify that the application does not segfault on launch
* If application segfaults on launch only when run under confinement, check
for apparmor="DENIED" log entry denying read or mmap operations on the binary
path, and report verification test failure
[ Where problems could occur ]
The lsblk profile update loosens confinement on a profile. However, if
a user manually modified the installed profile, then the package
upgrade would cause conflicts, and rejection of the incoming changes
(either by hand during an interactive upgrade or automatically during
an batch unattended upgrade) would result in end users not getting the
packaged fix.
[ Other Info ]
__________
Hey,
while debugging bug 2107402 we found that there is more to fix.
Running lsblk in a container on s390x hits this:
[12064869.934674] audit: type=1400 audit(1744791155.353:111962):
apparmor="DENIED" operation="file_mmap" class="file"
namespace="root//lxd-p_<var-snap-lxd-common-lxd>" profile="lsblk"
name="/usr/bin/lsblk" pid=3286747 comm="lsblk" requested_mask="rm"
denied_mask="rm" fsuid=1000000 ouid=1000000
To the user it just segfaults.
root@p:~# lsblk
Segmentation fault
root@p:~# aa-disable lsblk
Disabling /usr/bin/lsblk.
root@p:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 93.8M 1 loop
loop1 7:1 0 94M 1 l
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2107455/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
