Public bug reported:
A user with CAP_MAC_ADMIN in the init namespace can create an AppArmor
policy namespace and load a profile belonging to that AppArmor
namespace. Once that's done, the user can confine a process with that
namespaced AppArmor profile and enter into a user namespace. That
process can then load additional AppArmor profiles inside of the
AppArmor and user namespace. Here's an example:
We need to set up the namespace, n1, and load the profile, p1.
$ export rules="file, signal, unix, dbus, ptrace, mount, pivot_root,
capability,"
$ sudo mkdir /sys/kernel/security/apparmor/policy/namespaces/n1
$ echo "profile p1 { $rules }" | sudo apparmor_parser -qrn n1
Now we enter into confinement using the AppArmor namespace and profile and then
enter into an unprivileged user namespace
$ aa-exec -n n1 -p p1 -- unshare -Ur
We can now load profiles as the privileged user inside of the unprivileged user
namespace
# echo "profile test {}" | apparmor_parser -qr
The reason for this bug report is that we cannot create a nested
AppArmor policy namespace inside of the unprivileged user namespace
# mkdir /sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1
mkdir: cannot create directory
‘/sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1’: Permission
denied
If that worked, we could adjust LXD to read
/sys/kernel/security/apparmor/.ns_name to get the current AppArmor
namespace, then create a new namespace under the current namespace, and
leverage the nested namespace for its nested containers.
** Affects: apparmor (Ubuntu)
Importance: High
Assignee: Ubuntu Security Team (ubuntu-security)
Status: New
** Affects: linux (Ubuntu)
Importance: High
Assignee: Ubuntu Security Team (ubuntu-security)
Status: New
** Tags: aa-kernel bot-stop-nagging
** Tags added: bot-stop-nagging
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu)
Importance: Undecided => High
** Changed in: apparmor (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
** Tags added: aa-kernel
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1652101
Title:
Can't created nested AppArmor namespaces
Status in apparmor package in Ubuntu:
New
Status in linux package in Ubuntu:
New
Bug description:
A user with CAP_MAC_ADMIN in the init namespace can create an AppArmor
policy namespace and load a profile belonging to that AppArmor
namespace. Once that's done, the user can confine a process with that
namespaced AppArmor profile and enter into a user namespace. That
process can then load additional AppArmor profiles inside of the
AppArmor and user namespace. Here's an example:
We need to set up the namespace, n1, and load the profile, p1.
$ export rules="file, signal, unix, dbus, ptrace, mount, pivot_root,
capability,"
$ sudo mkdir /sys/kernel/security/apparmor/policy/namespaces/n1
$ echo "profile p1 { $rules }" | sudo apparmor_parser -qrn n1
Now we enter into confinement using the AppArmor namespace and profile and
then enter into an unprivileged user namespace
$ aa-exec -n n1 -p p1 -- unshare -Ur
We can now load profiles as the privileged user inside of the unprivileged
user namespace
# echo "profile test {}" | apparmor_parser -qr
The reason for this bug report is that we cannot create a nested
AppArmor policy namespace inside of the unprivileged user namespace
# mkdir /sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1
mkdir: cannot create directory
‘/sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1’: Permission
denied
If that worked, we could adjust LXD to read
/sys/kernel/security/apparmor/.ns_name to get the current AppArmor
namespace, then create a new namespace under the current namespace,
and leverage the nested namespace for its nested containers.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1652101/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
