Bug 589363 - SELinux empêche l'accès en "write" à /usr/sbin/libvirtd on /ro
Summary: SELinux empêche l'accès en "write" à /usr/sbin/libvirtd on /ro
Status: CLOSED DUPLICATE of bug 499536
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:3e4801a31e0...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-05 23:07 UTC by Carl G.
Modified: 2011-06-10 17:34 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-10 17:34:56 UTC
Type: ---

Attachments (Terms of Use)

Description Carl G. 2010-05-05 23:07:10 UTC

SELinux empêche l'accès en "write" à /usr/sbin/libvirtd on /ro

Description détaillée:

SELinux a refusé l'accès demandé par libvirtd. Il n'est pas prévu que cet
accès soit requis par libvirtd et cet accès peut signaler une tentative
d'intrusion. Il est également possible que cette version ou cette configuration
spécifique de l'application provoque cette demande d'accès supplémenta

Autoriser l'accès:

Vous pouvez créer un module de stratégie locale pour autoriser cet accès -
lisez la FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Merci de
remplir un rapport de bogue.

Informations complémentaires:

Contexte source               staff_u:system_r:virtd_t:s0-s0:c0.c1023
Contexte cible                system_u:object_r:admin_home_t:s0
Objets du contexte            /root [ dir ]
source                        libvirtd
Chemin de la source           /usr/sbin/libvirtd
Port                          <Inconnu>
Hôte                         (removed)
Paquetages RPM source         libvirt-0.7.7-3.fc13
Paquetages RPM cible          filesystem-2.4.31-1.fc13
Politique RPM                 selinux-policy-3.7.19-10.fc13
Selinux activé               True
Type de politique             targeted
Mode strict                   Enforcing
Nom du plugin                 catchall
Nom de l'hôte                (removed)
Plateforme                    Linux (removed)
                              #1 SMP Mon May 3 22:37:18 UTC 2010 x86_64 x86_64
Compteur d'alertes            1
Première alerte              mer. 05 mai 2010 19:05:46 EDT
Dernière alerte              mer. 05 mai 2010 19:05:46 EDT
ID local                      0ad4bec9-784a-4f95-aecf-c82fd3731eae
Numéros des lignes           

Messages d'audit bruts        

node=(removed) type=AVC msg=audit(1273100746.958:33494): avc:  denied  { write } for  pid=3733 comm="libvirtd" name="root" dev=dm-2 ino=2097153 scontext=staff_u:system_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir

node=(removed) type=SYSCALL msg=audit(1273100746.958:33494): arch=c000003e syscall=83 success=no exit=-13 a0=15ced60 a1=1ff a2=7fff91cd1f60 a3=b items=0 ppid=1 pid=3733 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=staff_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null)

Hash String generated from  catchall,libvirtd,virtd_t,admin_home_t,dir,write
audit2allow suggests:

#============= virtd_t ==============
#!!!! The source type 'virtd_t' can write to a 'dir' of the following types:
# cgroupfs_t, virt_cache_t, var_log_t, qemu_var_run_t, virt_var_lib_t, virt_var_run_t, virt_content_t, modules_conf_t, virt_etc_t, virt_log_t, virt_etc_rw_t, virt_image_type, system_conf_t, etc_t, var_lib_t, var_run_t, root_t

allow virtd_t admin_home_t:dir write;

Comment 1 Carl G. 2010-05-05 23:09:45 UTC
libvirtd fail to start during the boot procedure.

Comment 2 Daniel Walsh 2010-05-06 12:36:27 UTC
Why is libvirt trying to write to /root?

Did you put an image file in that directory?  Is there something in libvirt database that refers to /root?

Comment 3 Carl G. 2010-05-06 14:59:26 UTC
The only thing i did was to :

1) Create a storage pool (in my home dir (carl) labeled svirt_image_t

libvirtd is configured to start with my system but it fail to do so and that's the AVC i get when i run sudo to start it.

I can also attach libvirt / qemu config but i don't think you will find anything interresting.

Comment 4 Carl G. 2010-05-06 15:03:00 UTC
I don't see anything in /root that could be related to virt.

Comment 5 Daniel Walsh 2010-05-06 15:13:44 UTC
This would be a libvirt issue then

Comment 6 Carl G. 2010-05-06 15:23:54 UTC
sudo /etc/init.d/libvirtd restart
Arrêt du démon libvirtd :                                  [  OK  ]
Démarrage du démon libvirtd :                              [  OK  ]

May  6 11:19:30  libvirtd: 11:19:30.668: warning : qemudDispatchSignalEvent:385 : Shutting down on signal 15
May  6 11:19:30  libvirtd: Could not find keytab file: /etc/libvirt/krb5.tab: No such file or directory
May  6 11:19:30  libvirtd: 11:19:30.908: error : udevStrToLong_ui:78 : Failed to convert 'ff' to unsigned int
May  6 11:19:30  libvirtd: 11:19:30.925: warning : qemudStartup:1150 : Unable to create cgroup for driver: No such device or address
May  6 11:19:31  kernel: lo: Disabled Privacy Extensions
May  6 11:19:31  libvirtd: 11:19:31.056: warning : lxcStartup:1748 : Unable to create cgroup for driver: No such device or address
May  6 11:19:31  libvirtd: 11:19:31.056: error : umlStartup:422 : Failed to create monitor directory /root/.uml: Permission denied
May  6 11:19:31  libvirtd: 11:19:31.065: error : virStateInitialize:890 : Initialization of UML state driver failed
May  6 11:19:31  libvirtd: 11:19:31.065: error : main:3160 : Driver state initialization failed
May  6 11:19:31  libvirtd: 11:19:31.065: warning : qemudDispatchSignalEvent:385 : Shutting down on signal 3
May  6 11:19:33  setroubleshoot: SELinux empêche l'accès en "write" à /usr/sbin/libvirtd on /root. For complete SELinux messages. run sealert -l 0ad4bec9-784a-4f95-aecf-c82fd3731eae


Comment 7 Daniel Walsh 2010-05-06 15:34:30 UTC
We need to trick libvirt into seeing its homedir as something other then /root

Comment 8 Daniel Berrangé 2010-05-06 15:47:57 UTC
Why does it matter what its working directory is ? AFAIK libvirt isn't attempting to create files in its CWD. I'd prefer to know what is being written to /root before simply moving the working directory elsewhere.

Comment 9 Carl G. 2010-05-06 16:03:33 UTC
(In reply to comment #8)
> Why does it matter what its working directory is ? AFAIK libvirt isn't
> attempting to create files in its CWD. I'd prefer to know what is being written
> to /root before simply moving the working directory elsewhere.    

ls -l /root/.uml
total 0

Comment 10 Carl G. 2010-05-06 18:46:00 UTC
Once the directory is created, everything seems to be fine.

libvirtd is trying to create the directory .uml in /root.

Comment 11 Daniel Walsh 2010-05-06 19:20:58 UTC
Daniel I can give libvirt the rights to write to this directory.  And we can add a label for .uml.  But is seems to me that these directories/files get created based on libraries that libvirt calls, and does not necessarily control.  Changing $HOMEDIR to /var/lib/libvirt Would allow libvirt and any libraries it executes the ability to write and manipulate stuff, with less risk of mislabeled content.

Comment 12 Daniel Berrangé 2010-05-07 10:06:18 UTC
Ok, the UML problem is also reported in Fedora 11 as bug 499536. In theory we can move this directory, but I need to actually do some tests to make sure it'll work. If possible we'll move it to /var/run/libvirt/uml to match the qemu location.

Comment 13 Bug Zapper 2011-06-02 14:27:15 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 14 Cole Robinson 2011-06-10 17:34:56 UTC
Duping to 499536

*** This bug has been marked as a duplicate of bug 499536 ***

Note You need to log in before you can comment on or make changes to this bug.