Update of AppArmor disables libvirtd dynamic profiles
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Natty |
Fix Released
|
Medium
|
Jamie Strandboge |
Bug Description
Binary package hint: apparmor
Since a while back Ubuntu provides an excellent security model for virtualized systems. This happens via dynamic apparmor profiles protecting against manipulating other virtualized system resources but also the host system itself.
Example of how it works:
# apt-get install apparmor-profiles
# aa-enforce /etc/apparmor.d/*
<start your libvirtd and virtual machines>
# apparmor_status
apparmor module is loaded.
33 profiles are loaded.
33 profiles are in enforce mode.
[...]
4 processes have profiles defined.
4 processes are in enforce mode :
/usr/
/usr/sbin/named (5018)
libvirt-
libvirt-
[...]
# ps -ef --pid 12108
101 12108 1 1 Dec11 ? 00:41:09 /usr/bin/kvm
The dynamic libvirt-<UUID> profiles are created by libvirtd on launch. They are included by /etc/apparmor.
An example of enforcement looks like:
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
"/var/
"/var/
"/var/
"/data/
Very nice.
This is of course until you decide to update your system. And install a new apparmor, apparmor-profile or anything triggering "service apparmor restart" (efficiently unloading and reloading all apparmor profiles).
This efficiently makes apparmor enforce the new policies on existing running applications. Unfortunately /usr/lib/
For a system performing automatic security updates this is almost bound to happen.
Example:
# service apparmor restart
* Reloading AppArmor profiles [ OK ]
# apparmor_status
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
[...]
2 processes have profiles defined.
2 processes are in enforce mode :
/usr/
/usr/sbin/named (5018)
[...]
Security is efficiently disabled.
System information:
Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick
(Thank you launchpad/
visibility: | private → public |
Changed in apparmor (Ubuntu): | |
assignee: | nobody → Jamie Strandboge (jdstrand) |
milestone: | none → natty-alpha-3 |
status: | New → Triaged |
Changed in apparmor (Ubuntu Natty): | |
importance: | Undecided → Medium |
status: | Triaged → In Progress |
Did some additional research, and managed to re-load the existing profiles by executing:
root:/etc/ apparmor. d/libvirt# for i in $(ls | grep -v "\.files" | grep libvirt-); do apparmor_parser -a $i; done
# apparmor_status 22119fd7- e5c4-20c8- 7efe-e0fbb086e2 18 27ddd6d3- 01ec-85dd- 3f3b-0f58cbff18 fe 2d1c701b- d5ed-8524- 4ef6-fbd12419d7 5e 51ef85f6- ce69-4788- 9293-2af1860d45 d0 564dbb14- b9f2-4083- 2b85-cd44e90ee5 c6 909b523f- 78a6-01c2- 8179-daebf72b9e 1f 92d90b8b- b336-b73f- fb22-72a48d4754 45 de951d50- 6787-ec6a- 754c-c5b39a2d7c d9 ec24421d- 1911-4b1b- 09a8-0ece48901c b8
apparmor module is loaded.
40 profiles are loaded.
40 profiles are in enforce mode.
[...]
libvirt-
libvirt-
libvirt-
libvirt-
libvirt-
libvirt-
libvirt-
libvirt-
libvirt-
[...]
However, attempting to apply these to an existing pid (according to wiki @ https:/ /help.ubuntu. com/community/ AppArmor) gives:
root:/proc/ 23859/attr# cat current 23859/attr# echo 'setprofile libvirt- 27ddd6d3- 01ec-85dd- 3f3b-0f58cbff18 fe' > current
unconfined
root:/proc/
-bash: echo: write error: Permission denied
New machines shut down and relaunched after doing the "service apparmor restart" gets correctly confined:
# apparmor_status sbin/libvirtd (1928) 2d1c701b- d5ed-8524- 4ef6-fbd12419d7 5e (11214) sbin/libvirtd (1928)
[...]
3 processes have profiles defined.
3 processes are in enforce mode :
/usr/
/usr/sbin/named (5018)
libvirt-
[...]
# service apparmor restart
[...]
2 processes are in enforce mode :
/usr/
/usr/sbin/named (5018)
[...]