Just to make sure that we really talk about the same thing: This bug
sounds like it is *intended* that
unshare --user --map-root-user /bin/bash -c whoami
(as unpriv user) now fails in current Ubuntu 24.04 noble. That still
worked in released 23.10.
I am starting to test Cockpit on the current noble dailies [1] to make
sure everything is ready for 24.04 LTS (as 23.10 was a bit of a
disaster..), and aside from some non-fatal AppAmor noise this is the
most important issue. This breaks /usr/lib/cockpit/cockpit-desktop ,
which uses an user namespace to isolate cockpit's web server + a
browser, and that isolation is absolutely crucial for its security.
I can update cockpit-ws.deb to ship a new file /etc/apparmor.d/cockpit-
desktop with
------ 8< -----------
abi <abi/4.0>,
include <tunables/global>
profile cockpit-desktop /usr/lib/cockpit/cockpit-desktop flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/cockpit-desktop>
}
------ 8< -----------
I confirmed that this works fine. I just wanted to check that this is
intended, and not circumventing your intentions here?
Thanks!
[1] https://github.com/cockpit-project/bots/pull/6048
--
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/2046477
Title:
Enable unprivileged user namespace restrictions by default
Status in apparmor package in Ubuntu:
Triaged
Bug description:
As per https://discourse.ubuntu.com/t/spec-unprivileged-user-
namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626,
unprivileged user namespace restrictions for Ubuntu 23.10 are to be
enabled by default via a sysctl.d conf file in apparmor, and for that
to happen, the restrictions need to be enabled for 24.04
When the unprivileged user namespace restrictions are enabled, various
applications within and outside the Ubuntu archive fail to function,
as they use unprivileged user namespaces as part of their normal
operation.
A search of the Ubuntu archive for the 23.10 release was performed
looking for all applications that make legitimate use of the
CLONE_NEWUSER argument, the details of which can be seen in
https://docs.google.com/spreadsheets/d/1MOPVoTW0BROF1TxYqoWeJ3c6w2xKElI4w-VjdCG0m9s/edit#gid=2102562502
For each package identified in that list, an investigation was made to
determine if the application actually used this as an unprivileged
user, and if so which of the binaries within the package were
affected.
The full investigation can be seen in
https://warthogs.atlassian.net/browse/SEC-1898 (which is unfortunately
private) but is summarised to the following list of Ubuntu source
packages, as well as some out-of-archive applications that are known
to use unprivileged user namespaces.
For each of these binaries, an apparmor profile is required so that
the binary can be granted use of unprivileged user namespaces - an
example profile for the ch-run binary within the charliecloud package
is shown:
$ cat /etc/apparmor.d/ch-run
abi <abi/4.0>,
include <tunables/global>
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/ch-run>
}
However, in a few select cases, it has been decided not to ship an apparmor
profile, since this would effectively allow this mitigation to be bypassed. In
particular, the unshare and setns binaries within the util-linux package are
installed on every Ubuntu system, and allow an unprivileged user the ability to
launch an arbitrary application within a new user namespace. Any malicious
application then that wished to exploit an unprivileged user namespace to
conduct an attack on the kernel would simply need to spawn itself via `unshare
-U` or similar to be granted this permission. Therefore, due to the ubiquitous
nature of the unshare (and setns) binaries, profiles are not planned to be
provided for these by default.
Similarly, the bwrap binary within bubblewrap is also installed by default on
Ubuntu Desktop 24.04 and can also be used to launch arbitrary binaries within a
new user namespace and so no profile is planned to be provided for this either.
In Bug 2035315 new apparmor profiles were added to the apparmor
package for various applications which require unprivileged user
namespaces, using a new unconfined profile mode. They were also added
in the AppArmor upstream project.
As well as enabling the sysctl via the sysctl.d conf file, it is
proposed to add logic into the apparmor.service systemd unit to check
that the kernel supports the unconfined profile mode and that it is
enabled - and if not then to force disable the userns restrictions
sysctl via the following logic:
userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns)
unconfined_userns=$([ -f
/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ]
&& cat
/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ||
echo 0)
if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then
if [ "$unconfined_userns" -eq 0 ]; then
# userns restrictions rely on unconfined userns to be supported
echo "disabling unprivileged userns restrictions since unconfined userns
is not supported / enabled"
sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
fi
fi
This allows a local admin to disable the sysctl via the regular
sysctl.d conf approach, but to also make sure we don't inadvertently
enable it when it is not supported by the kernel.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046477/+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
