[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
@pitti: yes this intended. At this stage we are essentially enumerating
the known users of unprivileged user namespaces. We can ship the profile
for you or you are welcome to ship it.
In the future this is going to gradually tighten, some of the
"unconfined" profiles will be developed into real profiles, unconfined
(including these profiles) will get tied into integrity checks, or
require user exceptions in the security center, etc.
--
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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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:
[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
It solves several problems, but not all.
With regard to unprivileged user namespace mediation it should fix
- mscode
- nautilis
- devhelp
- element-desktop
- piphany
- evolution
- keybase
- opam
the element-desktop is still known to have some issues, which are on the snapd
side. It needs to add some interfaces etc.
there is a beta3 coming early next week with additional fixes coming.
The full set won't be finalized until beta3 is rolled this weekend.
--
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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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
[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
apparmor 4.0.0~beta2-0ubuntu3 installed today from proposed solves problem of
bug https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/2047256, does it
solve other problems too?
Thanks
--
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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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 : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help :
[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
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 ,
include
profile cockpit-desktop /usr/lib/cockpit/cockpit-desktop flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
-- 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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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
[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
We will get this updated with requested information soon. We are
currently working on a revision that provides more flexibility and will
support some cases that break today.
--
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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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 : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help :
[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
Can you please explain how all of this is handled during dist-upgrades?
Have all the packages with affected profiles have versioned depends
added?
Is the featured _not_ turned on during dist-upgrade from jammy hwe to
noble, but only after reboot? (as the kernel is compatible, yet during
upgrade the profiles may not be updated in the correct order)
** Changed in: apparmor (Ubuntu)
Status: Fix Released => Triaged
--
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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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:
[Touch-packages] [Bug 2046477] Re: Enable unprivileged user namespace restrictions by default
This bug was fixed in the package apparmor - 4.0.0~alpha2-0ubuntu7
---
apparmor (4.0.0~alpha2-0ubuntu7) noble; urgency=medium
[Alex Murray]
* Enable user namespace restrictions by default (LP: #2046477)
- d/p/u/userns-runtime-disable.patch: add logic to disable user
namespace restrictions if kernel lacks support
- debian/usr/lib/sysctl.d/10-apparmor.conf: set sysctl value to 1 and
update comment to match
- debian/apparmor.service: run After systemd-sysctl.service
[John Johansen]
* Add additional AppArmor profiles to support third-party applications
that use unprivileged user namespace
- add d/p/u/oot-unconfined-profiles.patch
- add profiles to debian/apparmor.install
- /etc/apparmor.d/1password
- /etc/apparmor.d/Discord
- /etc/apparmor.d/MongoDB_Compass
- /etc/apparmor.d/code
- /etc/apparmor.d/firefox
- /etc/apparmor.d/github-desktop
- /etc/apparmor.d/obsidian
- /etc/apparmor.d/opera
- /etc/apparmor.d/polypane
- /etc/apparmor.d/signal-desktop
- /etc/apparmor.d/slack
- /etc/apparmor.d/steam
[Alex Murray]
* Drop duplicate profiles for usr.share.code.bin.code and
* usr.lib.multiarch.opera.opera since they are now also in
d/p/u/oot-unconfined-profiles.patch
- modified d/p/u/userns-unconfined-profiles.patch to remove them
- removed from debian/apparmor.install
- added to debian/apparmor.maintscript to ensure they are removed on
upgrade
-- John Johansen Wed, 13 Dec 2023
20:38:45 -0800
** Changed in: apparmor (Ubuntu)
Status: New => Fix Released
--
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:
Fix Released
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 ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
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
