Bug 675440 - SELinux is preventing /usr/bin/virsh from using the 'setpcap' capabilities.
SELinux is preventing /usr/bin/virsh from using the 'setpcap' capabilities.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
14
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:83d94099590...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-05 12:16 EST by thomas
Modified: 2012-01-24 16:52 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-24 16:52:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description thomas 2011-02-05 12:16:28 EST
SELinux is preventing /usr/bin/virsh from using the 'setpcap' capabilities.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that virsh should have the setpcap capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep virsh /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:system_r:virsh_t:s0
Target Context                unconfined_u:system_r:virsh_t:s0
Target Objects                Unknown [ capability ]
Source                        virsh
Source Path                   /usr/bin/virsh
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           libvirt-client-0.8.3-2.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.7-29.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.10-74.fc14.x86_64 #1 SMP
                              Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Sat 05 Feb 2011 12:15:31 PM EST
Last Seen                     Sat 05 Feb 2011 12:15:31 PM EST
Local ID                      06517710-55f1-4d9e-9456-dc5afd3228be

Raw Audit Messages
type=AVC msg=audit(1296926131.119:64039): avc:  denied  { setpcap } for  pid=548 comm="virsh" capability=8  scontext=unconfined_u:system_r:virsh_t:s0 tcontext=unconfined_u:system_r:virsh_t:s0 tclass=capability


type=SYSCALL msg=audit(1296926131.119:64039): arch=x86_64 syscall=prctl success=no exit=EPERM a0=18 a1=0 a2=0 a3=0 items=0 ppid=546 pid=548 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=42 comm=virsh exe=/usr/bin/virsh subj=unconfined_u:system_r:virsh_t:s0 key=(null)

Hash: virsh,virsh_t,virsh_t,capability,setpcap

audit2allow

#============= virsh_t ==============
allow virsh_t self:capability setpcap;

audit2allow -R

#============= virsh_t ==============
allow virsh_t self:capability setpcap;
Comment 1 thomas 2011-02-05 12:24:07 EST
Issuing a "clusvcadm -M vm:<name> -m <target>" results in the setpcap denial reported at the beginning of the migration process (starting the source target qemu instance). 

The denial does not occur if the live migration is performed using the "# virsh migrate --live" command.

The denial does not appear to prevent the migration from completing.
Comment 2 Daniel Walsh 2011-02-07 13:10:25 EST
This indicates that virsh is dropping capabilities?  Daniel does it drop capabilities now?
Comment 3 Daniel Berrange 2011-02-09 05:39:57 EST
virsh itself doesn't drop capabilities, but if it forks a helper program, there may be cases where it drops capabilities inbetween the fork+exec path. I can't remember if there are any such cases in virsh offhand though.   What libvirt driver URI is  being used by clusvcadm ?  It would help to get a debug trace by setting the env variables

 LIBVIRT_LOG_FILTERS="1:libvirt 1:util"
 LIBVIRT_LOG_OUTPUTS="1:file:/var/log/libvirt/virsh.log"

in clusvcadm when issuing the virsh commands.
Comment 4 thomas 2011-02-09 06:49:08 EST
I attempted to set the env variables in the shell where I executed the clusvcadm command, but got no output to a log file in /var/log/libvirt:


[root ~]# export LIBVIRT_LOG_FILTERS="1:libvirt 1:util"
[root ~]# export LIBVIRT_LOG_OUTPUTS="1:file:/var/log/libvirt/virsh.log"
[root ~]# env | grep LIBVIRT
LIBVIRT_LOG_FILTERS=1:libvirt 1:util
LIBVIRT_LOG_OUTPUTS=1:file:/var/log/libvirt/virsh.log
[root ~]# clusvcadm -M vm:vm1 -m host2
Trying to migrate vm:vm1 to host2...Success
[root ~]# clusvcadm -M vm:vm1 -m host1
Trying to migrate vm:vm1 to host1...Success
[root ~]# ls -lart /var/log/libvirt/
total 20
drwx------.  2 root root 4096 Aug 23 17:32 uml
drwx------.  2 root root 4096 Aug 23 17:32 lxc
drwx------.  5 root root 4096 Jan 31 01:02 .
drwx------.  2 root root 4096 Jan 31 15:28 qemu
drwxr-xr-x. 19 root root 4096 Feb  6 03:12 ..
[root ~]#
Comment 5 Daniel Walsh 2011-02-09 09:05:42 EST
The alert says /usr/bin/virsh executed the prctl syscall resulting in a setpcap access check.

Since it has setcap already I thine we should add

setpcap.
Comment 6 Fedora Admin XMLRPC Client 2011-09-22 13:58:34 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora Admin XMLRPC Client 2011-09-22 14:02:16 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2011-11-30 14:58:21 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fedora Admin XMLRPC Client 2011-11-30 14:59:27 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora Admin XMLRPC Client 2011-11-30 15:04:33 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora Admin XMLRPC Client 2011-11-30 15:04:59 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Cole Robinson 2012-01-24 16:52:08 EST
F14 is EOL, please reopen if this is still relevant in a more recent fedora.

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