** Description changed:

  [ Impact ]
  
  On 26.04 Resolute, uutils/uucore coreutils commands may read
  localization files from `/usr/share/coreutils/locales/`. The shipped
  AppArmor `abstractions/base` allows common singular locale paths such as
  `/usr/share/**/locale/**`, but it does not match plural `locales` paths.
  
  Affected users can see AppArmor read denials when confined profiles
  execute uutils coreutils commands. The bug was reproduced with the `who`
  profile, and similar denials were also observed under other profiles,
  such as `pollinate`, when commands read uutils locales paths.
  
  The fix is ported from the upstream AppArmor base-abstraction change
  from:
  
https://gitlab.com/apparmor/apparmor/-/commit/44a204dbc3790195a984415674b441a91d3b2fa9
  
  The change to `abstractions/base` resolving this is:
  
  ```
  /usr/share/**/locale/** r,
  ```
  
  to:
  
  ```
  /usr/share/**/locale{,s}/** r,
  ```
  
  This covers `/usr/share/coreutils/locales/...` for profiles that include
  `<abstractions/base>`.
  
  [ Test Plan ]
  
  These steps should be run on Ubuntu 26.04 Resolute with AppArmor enabled
  and theu utils coreutils implementation installed.
  
- A package with these changes is staged in the following PPA:
-   https://launchpad.net/~ks0/+archive/ubuntu/apparmor-lsusb-fix
- Adding it:
-   sudo add-apt-repository ppa:ks0/apparmor-lsusb-fix
-   sudo apt update
- 
  1. Reproduce the `who` denial with the release package:
  
  ```
  sudo dmesg -C
  LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 who >/dev/null
  sudo dmesg | grep 
'apparmor="DENIED".*profile="who".*/usr/share/coreutils/locales'
  ```
  
  Expected: one or more denials for
  `/usr/share/coreutils/locales/.../*.ftl`.
  
  In place of `en_US.UTF-8`, you may also use any generated UTF-8 locale
  that causes uutils commands to read files below
  `/usr/share/coreutils/locales/`.
  
- 2. Install `apparmor` version `5.0.0~beta1-0ubuntu7.1~ppa1` from the
- PPA, or the corresponding version once in -proposed, then reload
- AppArmor:
- 
- ```
- apt-cache policy apparmor
- sudo systemctl reload apparmor
- sudo apparmor_parser -Q -K /etc/apparmor.d/who
- ```
+ 2. Install the new AppArmor version.
  
  3. Verify the `who` denial is gone:
  
  ```
  sudo dmesg -C
  LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 who >/dev/null
  sudo dmesg | grep 
'apparmor="DENIED".*profile="who".*/usr/share/coreutils/locales'
  ```
  
  Expected: `grep` returns no matching denials.
  
  4. Run basic regression checks:
  
  ```
  who >/dev/null
  who -a >/dev/null
  sudo dmesg | grep 'apparmor="DENIED".*/usr/share/coreutils/locales' || true
  ```
  
  Expected: commands complete successfully and no new coreutils locale
  denials are logged for profiles that include `<abstractions/base>`.
  
  [ Where problems could occur ]
  
  This changes the shared `abstractions/base` policy. If the rule is too
  narrow, users will continue to see AppArmor denials for the uutils
  `locales` files. If the rule is too broad, confined processes whose
  profiles include `<abstractions/base>` can read under the plural
  `locales` directory. This is a read-only rule.
  
  [ Other Info ]
  
  The upstream AppArmor task is Fix Released. 26.10 Stonking carries a
  version of AppArmor which contain the upstream commits from which this
  fix was derived, though it was still `In Progress` when this was
  originally triaged. So marking this `Fix Released` for Stonking, while
  an SRU is still needed for Resolute.

** Description changed:

  [ Impact ]
  
  On 26.04 Resolute, uutils/uucore coreutils commands may read
  localization files from `/usr/share/coreutils/locales/`. The shipped
  AppArmor `abstractions/base` allows common singular locale paths such as
  `/usr/share/**/locale/**`, but it does not match plural `locales` paths.
  
  Affected users can see AppArmor read denials when confined profiles
  execute uutils coreutils commands. The bug was reproduced with the `who`
  profile, and similar denials were also observed under other profiles,
  such as `pollinate`, when commands read uutils locales paths.
  
  The fix is ported from the upstream AppArmor base-abstraction change
  from:
  
https://gitlab.com/apparmor/apparmor/-/commit/44a204dbc3790195a984415674b441a91d3b2fa9
  
  The change to `abstractions/base` resolving this is:
  
  ```
  /usr/share/**/locale/** r,
  ```
  
  to:
  
  ```
  /usr/share/**/locale{,s}/** r,
  ```
  
  This covers `/usr/share/coreutils/locales/...` for profiles that include
  `<abstractions/base>`.
  
  [ Test Plan ]
  
  These steps should be run on Ubuntu 26.04 Resolute with AppArmor enabled
  and theu utils coreutils implementation installed.
  
  1. Reproduce the `who` denial with the release package:
  
  ```
  sudo dmesg -C
  LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 who >/dev/null
  sudo dmesg | grep 
'apparmor="DENIED".*profile="who".*/usr/share/coreutils/locales'
  ```
  
  Expected: one or more denials for
  `/usr/share/coreutils/locales/.../*.ftl`.
  
  In place of `en_US.UTF-8`, you may also use any generated UTF-8 locale
  that causes uutils commands to read files below
  `/usr/share/coreutils/locales/`.
  
- 2. Install the new AppArmor version.
+ 2. Install the new AppArmor version from -proposed.
  
  3. Verify the `who` denial is gone:
  
  ```
  sudo dmesg -C
  LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 who >/dev/null
  sudo dmesg | grep 
'apparmor="DENIED".*profile="who".*/usr/share/coreutils/locales'
  ```
  
  Expected: `grep` returns no matching denials.
  
  4. Run basic regression checks:
  
  ```
  who >/dev/null
  who -a >/dev/null
  sudo dmesg | grep 'apparmor="DENIED".*/usr/share/coreutils/locales' || true
  ```
  
  Expected: commands complete successfully and no new coreutils locale
  denials are logged for profiles that include `<abstractions/base>`.
  
  [ Where problems could occur ]
  
  This changes the shared `abstractions/base` policy. If the rule is too
  narrow, users will continue to see AppArmor denials for the uutils
  `locales` files. If the rule is too broad, confined processes whose
  profiles include `<abstractions/base>` can read under the plural
  `locales` directory. This is a read-only rule.
  
  [ Other Info ]
  
  The upstream AppArmor task is Fix Released. 26.10 Stonking carries a
  version of AppArmor which contain the upstream commits from which this
  fix was derived, though it was still `In Progress` when this was
  originally triaged. So marking this `Fix Released` for Stonking, while
  an SRU is still needed for Resolute.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2158941

Title:
  uutils coreutils locale reads blocked

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2158941/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to