You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Last year Ubuntu started to support a new sysctl kernel.apparmor_restrict_unprivileged_userns that allows the use of user namespaces only if the process is confined by an apparmor profile and includes the permission userns, thereby allowing a restricted use of userns. The required patches allegedly also made it into the upstream kernel.
Recently apparmor version 4 was published and this week made it to arch as well, installing a number of apparmor profiles that include the new userns permission for application that require it, thereby allowing the vanilla arch kernel to use restricted userns by setting kernel.apparmor_restrict_unprivileged_userns to 1
With an increasing number of applications displaying warnings when userns are unavailable and consequently reducing or disabling runtime protection features, it may be a good idea to allow restricted userns in the hardened kernel since now the default apparmor package supports it as well.
For this to work the hardened kernel config would need to include CONFIG_USER_NS_UNPRIVILEGED=y while also setting kernel.apparmor_restrict_unprivileged_userns to 1 by default, thereby arriving at the same restrictions we have now since the restricted userns will only be available for processes running in apparmor, which is not loaded as an lsm by default.
While this change wont impact user that do not want userns, it will allow anyone to load the apparmor lsm and use userns for specified applications.
Update: The vanilla kernel has kernel.unprivileged_userns_apparmor_policy set to 1 but there seems to be no documentation about it and whether this is equal to kernel.apparmor_restrict_unprivileged_userns
Currently looking for more information.
The text was updated successfully, but these errors were encountered:
Once this is available, I would suggest to use the above described settings by default in linux-hardened to allow the use of userns for apparmor confined processes. Users till have to setup apparmor profiles to enable the use of userns for specified applications, thereby the default does not change
Last year Ubuntu started to support a new sysctl
kernel.apparmor_restrict_unprivileged_userns
that allows the use of user namespaces only if the process is confined by an apparmor profile and includes the permission userns, thereby allowing a restricted use of userns. The required patches allegedly also made it into the upstream kernel.Recently apparmor version 4 was published and this week made it to arch as well, installing a number of apparmor profiles that include the new userns permission for application that require it, thereby allowing the vanilla arch kernel to use restricted userns by setting
kernel.apparmor_restrict_unprivileged_userns
to 1With an increasing number of applications displaying warnings when userns are unavailable and consequently reducing or disabling runtime protection features, it may be a good idea to allow restricted userns in the hardened kernel since now the default apparmor package supports it as well.
For this to work the hardened kernel config would need to include
CONFIG_USER_NS_UNPRIVILEGED=y
while also settingkernel.apparmor_restrict_unprivileged_userns
to 1 by default, thereby arriving at the same restrictions we have now since the restricted userns will only be available for processes running in apparmor, which is not loaded as an lsm by default.While this change wont impact user that do not want userns, it will allow anyone to load the apparmor lsm and use userns for specified applications.
Feature details: https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626
Update: The vanilla kernel haskernel.unprivileged_userns_apparmor_policy
set to 1 but there seems to be no documentation about it and whether this is equal tokernel.apparmor_restrict_unprivileged_userns
Currently looking for more information.
The text was updated successfully, but these errors were encountered: