** 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2107455
Title:
segfault of lsblk s390x in containers due to apparmor
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2107455/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
