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
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2115234
Title:
Improper globbing in rules for /sys/devices PCI paths
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Jammy:
New
Status in apparmor source package in Noble:
New
Status in apparmor source package in Plucky:
Fix Committed
Status in apparmor source package in Questing:
Fix Released
Bug description:
[ 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`).
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2115234/+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
