** Description changed:
SRU Justification:
[ Impact ]
- * lsblk on an s390x system that uses DASD disks shows no output.
-
- * journactl shows lsblk is blocked by apparmor:
- 2025-04-15T15:02:26.048075+00:00 s5lp1-gen03 kernel: audit: type=1400
- audit(1744729346.034:270): apparmor="DENIED" operation="open"
- class="file" profile="lsblk" name="/sys/devices/css0/
- 0.0.0000/0.0.0101/block/dasda/hidden" pid=2070 comm="lsblk"
- requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
-
- * The reason is that the lsblk profile does not allow access
- to /sys/devices/css0.
+ 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.
[ Test Plan ]
- * Install Ubuntu Server 25.04 on IBM Z in LPAR, z/VM or KVM
- using DASD ECKD disks.
-
- * Please notice that testing this at install time using the installer
- shell is not sufficient, since the profile is not active at that time.
-
- * Ensure util-linux and the s390-tools are installed
- (which is by default).
-
- * Do an lsdasd, it should list DASD ECKD disks, similar to:
- $ lsdasd
- Bus-ID Status Name Device Type BlkSz Size Blocks
-
================================================================================
- 0.0.0200 active dasda 94:0 ECKD 4096 7042MB 1802880
- 0.0.0300 active dasdb 94:4 ECKD 4096 7042MB 1802880
- 0.0.0400 active dasdc 94:8 ECKD 4096 21128MB 5409000
-
- * Now execute lsblk (and watch the journal)
-
- - on a system that is not patched,
- one will see no output in the Terminal
- (or in case of running in a container a segfault),
- and messages like this in the journal:
- 2025-04-15T15:02:26.048075+00:00 hwe0006 kernel: audit: type=1400
- audit(1744729346.034:270): apparmor="DENIED" operation="open"
- class="file" profile="lsblk" name="/sys/devices/css0/
- 0.0.0000/0.0.0200/block/dasda/hidden" pid=2070 comm="lsblk"
- requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
- ...
-
- - on a patched system, lsblk should provide a proper output
- similar to this:
- $ lsblk
- NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
- loop0 7:0 0 65.4M 1 loop
- loop1 7:1 0 65.4M 1 loop /snap/core22/1909
- loop2 7:2 0 39.9M 1 loop
- loop3 7:3 0 98.7M 1 loop /snap/lxd/32454
- loop4 7:4 0 39.9M 1 loop /snap/snapd/23776
- loop5 7:5 0 65.4M 1 loop
- loop6 7:6 0 100M 1 loop /snap/lxd/33109
- loop7 7:7 0 46.2M 1 loop /snap/snapd/24506
- loop8 7:8 0 65.4M 1 loop /snap/core22/1965
- dasda 94:0 0 20.6G 0 disk
- └─dasda1 94:1 0 20.6G 0 part
- └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm /
- dasdb 94:4 0 6.9G 0 disk
- ├─dasdb1 94:5 0 1G 0 part /boot
- └─dasdb2 94:6 0 5.9G 0 part
- └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm /
- dasdc 94:8 0 20.6G 0 disk
- └─dasdc1 94:9 0 20.6G 0 part
- └─hwe0006--vg-hwe0006--lv 253:0 0 47.1G 0 lvm /
-
- * (After having done 'aa-disable lsblk' lsblk would also work
- would also work without the profile changes.)
-
- * As a regression test, execute lsblk also on a FCP/SCSP
- system, to verify that nothing has changed
- (since this was not affected).
+ * 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
[ Where problems could occur ]
- * This SRU loosens confinement on the lsblk profile. However, if a user
- manually modified the installed profiles, 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.
-
- * Check if apparmor is enabled and the profile active:
- sudo aa-status --enabled
- sudo aa-status --show=all | grep lsblk
-
- * This should not have an impact on other (disk type) devices
- like SCSI/FCP, but better check (see test plan, last bullet).
+ 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 ]
- * The modification is already included in questing.
-
- * The patch was tested also successfully tested in plucky on s390x.
__________
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:
Confirmed
Status in apparmor package in Ubuntu:
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.
[ 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
[ 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 : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
