** Description changed:
[ Impact ]
Various commands segfaulted when run from a confined context due to
missing permissions on the binary execution path, and their
corresponding profiles need rules to give m+r permissions for the
binaries themselves.
[ Test Plan ]
+ * Run `sudo aa-status` to verify that all the profiles under
profiles/apparmor.d modified by
debian/patches/ubuntu/profiles_ensure_access_to_attach_path.patch (henceforth
"the patch") have loaded successfully
* 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 -- the_application`, under sudo if the
application needs root privileges
+ * Choose a subset of the applications confined by profiles under
profiles/apparmor.d modified by the patch, and for each selected application:
+ - Run `aa-exec -p allow_all -- sh -c 'the_application'`, under sudo if the
application needs root privileges
+ - If a profile for the application is not loaded, sh will report a
permission denial on the exec transition when attempting to execute it
- 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 ]
All the profile changes in this SRU are loosening confinement on a
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 complete set of packaged fixes. However, as each
of the files updated are independent of each other, a partially fixed
state will not be more broken than an unfixed (before upgrade) state.
[ Other Info ]
This is a bug filed in response to LP: #2107455, which is one particular
instance of this more general bug we discovered while investigating that
bug. As such, the test plan in this bug is a corresponding
generalization of the test plan in that bug.
--
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/2110628
Title:
apparmor profiles need mr permissions on their own binaries for
execution from a confined context
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Plucky:
In Progress
Status in apparmor source package in Questing:
Fix Released
Bug description:
[ Impact ]
Various commands segfaulted when run from a confined context due to
missing permissions on the binary execution path, and their
corresponding profiles need rules to give m+r permissions for the
binaries themselves.
[ Test Plan ]
* Run `sudo aa-status` to verify that all the profiles under
profiles/apparmor.d modified by
debian/patches/ubuntu/profiles_ensure_access_to_attach_path.patch (henceforth
"the patch") have loaded successfully
* 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 the patch, and for each selected application:
- Run `aa-exec -p allow_all -- sh -c 'the_application'`, under sudo if the
application needs root privileges
- If a profile for the application is not loaded, sh will report a
permission denial on the exec transition when attempting to execute it
- 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 ]
All the profile changes in this SRU are loosening confinement on a
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 complete set of packaged fixes. However, as each
of the files updated are independent of each other, a partially fixed
state will not be more broken than an unfixed (before upgrade) state.
[ Other Info ]
This is a bug filed in response to LP: #2107455, which is one
particular instance of this more general bug we discovered while
investigating that bug. As such, the test plan in this bug is a
corresponding generalization of the test plan in that bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2110628/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
