The changes here look reasonable. However, the test case should be
amended to not suggest the use of a PPA - tests for SRUs need to be done
against the packages we're releasing! (I have done this)
** Description changed:
[ Impact ]
* AppArmor profiles with rules for /sys/devices/ PCI paths using decimal
patterns may miss some PCI devices whose PCI domain or bus starts with
or contains hex characters a-f.
* Example: On a DGX-2 with 10 nvme drives provisioned with Plucky, the
output of lsblk is missing entries for nvme2 (pci0000:ae), nvme3
(pci0000:ae), nvme8 (pci0000:d7), and nvme9 (pci0000:d7), and there are
apparmor="DENIED" messages for each omitted drive.
* This was addressed by updating any profile containing rule(s) for
/sys/devices/ PCI domain:bus paths to use hex matching instead of dec.
The alias `@{pci_bus}=pci@{hex4}:@{hex2}` was established and used in
all such cases (e.g., `@{sys}/devices/pci[0-9]*:[0-9]*/...` ->
`@{sys}/devices/@{pci_bus}/...`) to standardize the globbing used
against /sys/devices PCI paths.
[ Test Plan ]
* On a test device provisioned with Plucky which has one or more block
devices on PCI whose PCI domain or bus begins with a hex character a-f
(e.g., a device with many NVME drives), invoke `lsblk` and compare the
output to what is expected for the hardware physically present on the
device (or temporarily disable AppArmor and compare the output of
- `lsblk`). Add the appropriate PPA [1][2][3], `sudo apt update`, `sudo
- apt install apparmor libapparmor1`, `sudo systemctl restart apparmor`,
- and invoke `lsblk`, and compare the listed block devices (none should be
- missing in this case). Note that this example is specific to Plucky as
- the lsblk profile was not present in releases prior.
+ `lsblk`).
+
+ After installing the proposed packages, invoke `lsblk` again, and
+ compare the listed block devices (none should be missing in this case).
+ Note that this example is specific to Plucky as the lsblk profile was
+ not present in releases prior.
* As many of these profiles are related to software associated with a
specific set of hardware, I am unable to manually test the changes
across all affected profiles. However, since the changes are uniform
across the affected profiles, the implications of a
`@{sys}/devices/pci[0-9]*:[0-9]*/...` rule being updated to
`@{sys}/devices/@{pci_bus}/` in one profile should not differ from the
implications of the same change in another.
[ Where problems could occur ]
* Improper matching of /sys/devices/ PCI paths may result in devices
being 'invisible' to the software for which the profile(s) regulate
(such is the case prior to this patch).
* As far as I'm aware, any PCI bus:domain listed in /sys/devices/ is
strictly in the format pciHHHH:HH (where 'H' are hex chars [0-9a-f]). If
there are *any* exceptions to this which I'm unaware of, devices on
these bus:domains may be omitted by these rules.
[ Other Info ]
Upstream MR (merged):
https://gitlab.com/apparmor/apparmor/-/merge_requests/1725
[1] https://launchpad.net/~ks0/+archive/ubuntu/plucky-apparmor-pci-patch-2
[2] https://launchpad.net/~ks0/+archive/ubuntu/noble-apparmor-pci-patch-3
[3] https://launchpad.net/~ks0/+archive/ubuntu/jammy-apparmor-pci-patch-3
[ Verbose Example with `lsblk` ]
Expected to see all nvmeXn1 (0-9) devices listed, but some are omitted,
such as nvme2n1. nvme2n1 appears under the PCI directory pci0000:ae,
thus AppArmor denials appear in dmesg and nvme2n1 is omitted from the
output of lsblk (the same applies for the other ommitted devices:
nvme3n1, nvme5n1, nvme7n1).
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 29.3G 0 disk
└─sda1 8:1 1 29.3G 0 part
sdb 8:16 1 0B 0 disk
sr0 11:0 1 1024M 0 rom
nvme1n1 259:0 0 894.3G 0 disk
├─nvme1n1p1 259:2 0 512M 0 part /boot/efi
└─nvme1n1p2 259:3 0 893.8G 0 part /
nvme0n1 259:1 0 894.3G 0 disk
nvme4n1 259:4 0 3.5T 0 disk
nvme9n1 259:6 0 3.5T 0 disk
nvme8n1 259:8 0 3.5T 0 disk
nvme6n1 259:11 0 3.5T 0 disk
$ readlink -f /sys/class/block/nvme2n1/device
/sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/0000:b0:00.0/0000:b1:00.0/nvme/nvme2
$ sudo dmesg | grep -i nvme
...
[11748.808896] audit: type=1400 audit(1750465699.990:180): apparmor="DENIED"
operation="open" class="file" profile="lsblk"
name="/sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/0000:b0:00.0/0000:b1:00.0/nvme/nvme2/nvme2n1/hidden"
pid=3734 comm="lsblk" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[11748.808904] audit: type=1400 audit(1750465699.990:181): apparmor="DENIED"
operation="open" class="file" profile="lsblk"
name="/sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/0000:b0:00.0/0000:b1:00.0/nvme/nvme2/nvme2n1/dev"
pid=3734 comm="lsblk" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[11748.808931] audit: type=1400 audit(1750465699.990:182): apparmor="DENIED"
operation="open" class="file" profile="lsblk"
name="/sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/0000:b0:00.0/0000:b1:00.0/nvme/nvme2/dev"
pid=3734 comm="lsblk" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
** Changed in: apparmor (Ubuntu Plucky)
Status: New => Fix Committed
** Tags added: verification-needed verification-needed-plucky
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2115234
Title:
Improper globbing in rules for /sys/devices PCI paths
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2115234/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
