Hi, Below is an setroubleshoot report for spice-vdagent, which I just submitted as a package for inclusion into Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=648549 I've no idea what you know about spice, so let me give you a short intro: SPICE is a protocol (amd an implementation of that protocol) for Virtual Desktop Infrastructure (VDI). What this boils down to is that spice is a much more efficient alternative for VNC in the special case of remotely displaying the desktop (framebuffer) of a virtual machine. The focus on spice is making it possible to run full blown desktop environments on a bunch of servers as virtual machines. And then be able to connect to these from thin clients: http://spice-space.org/ One part of spice is an agent process running inside the guest OS, which allows for things like copy and paste between client and guest (when using the client from a fat client). spice-vdagent is a Linux version of this agent which we've just released. Since there can be multiple desktop sessions at a time on one linux guest, (think switch user functionality for example) spice-vdagent is split into a daemon multiplexing the connection to the client (so that only the active session can access the client clipboard for example) and per X-session agent processes. The daemon /usr/sbin/spice-vdagentd listens to a unix domain server socket: /var/run/spice-vdagentd/spice-vdagent-sock And the per session agent processes connect to this. The denial below is about the per session agent running under gdm (the agent also offers something known as client mouse mode which leads to a much more pleasant mouse experience, which is why it gets started under gdm too). The reason I'm giving all this info is because although just a small fix for the below issue would be great, the ideal solution would also include denying access to /var/run/spice-vdagentd/spice-vdagent-sock to all processes except /usr/bin/spice-vdagent. Although the daemon is quite defensively written and should take any crap send to it, it would be better if none could send any crap to it at al :) I've considered using sgid tricks for this, but I already knew I needed to file this bug, so I hope that this can be fixed at the selinux level too. Thanks & Regards, Hans p.s. Even better would be running spice-vdagentd in its own context, as it runs with root rights, but needs only very few limited rights. Let me know if you would be willing to help with this and I'll write a short list with the external io the daemon needs / does. ### Summary: SELinux is preventing /usr/bin/spice-vdagent "write" access on spice-vdagent-sock. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by spice-vdagent. It is not expected that this access is required by spice-vdagent and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_run_t:s0 Target Objects spice-vdagent-sock [ sock_file ] Source spice-vdagent Source Path /usr/bin/spice-vdagent Port <Unknown> Host localhost.localdomain Source RPM Packages spice-vdagent-0.6.3-1.fc14 Target RPM Packages Policy RPM selinux-policy-3.9.5-7.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.35.6-37.fc14.x86_64 #1 SMP Fri Oct 1 06:07:16 UTC 2010 x86_64 x86_64 Alert Count 2 First Seen Mon 01 Nov 2010 01:47:33 PM CET Last Seen Mon 01 Nov 2010 01:47:33 PM CET Local ID cb3a852d-5426-4343-9215-bc8976ed8592 Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1288615653.816:5): avc: denied { write } for pid=990 comm="spice-vdagent" name="spice-vdagent-sock" dev=dm-0 ino=1716681 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file node=localhost.localdomain type=AVC msg=audit(1288615653.816:5): avc: denied { connectto } for pid=990 comm="spice-vdagent" path="/var/run/spice-vdagentd/spice-vdagent-sock" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket node=localhost.localdomain type=SYSCALL msg=audit(1288615653.816:5): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fffe372d2a0 a2=6e a3=7fffe372d000 items=0 ppid=980 pid=990 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="spice-vdagent" exe="/usr/bin/spice-vdagent" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
Where can I get the package?
(In reply to comment #1) > Where can I get the package? Hi, I assume you mean the spice-vdagent package, there is a .src.rpm here: http://people.fedoraproject.org/~jwrdegoede/spice-vdagent-0.6.3-1.fc14.src.rpm I can do a scratch build for you if you want. Note though that spice-vdagentd will quit as soon as you connect to it with a spice-vdagent per session process as it then tries to connect to /dev/virtio-ports/com.redhat.spice.0, which is only available when you're running a qemu virtual machine with spice as display (rather then vnc or sdl). If you want I can give you some short instructions on howto setup such a virtual machine under F-14. Thanks & Regards, Hans
Miroslav can you look into writing policy for spice-vdagent?
Yes, it is my plan.
> > If you want I can give you some short instructions on howto setup such a > virtual machine under F-14. Hi Hans, it would be fine. Thanks. > Thanks & Regards, > > Hans
To get a spice virtual machine take an F-14 virtual machine disk image and start it with qemu from the cmdline something like this: qemu-kvm -enable-kvm -cpu host -m 1024 -name F14 \ -drive file=/mnt/virt_images/f14.img,if=virtio,media=disk \ -net nic,macaddr=52:54:00:7a:b4:7d,vlan=0,model=virtio,name=virtio.0 -net user,vlan=0 \ -vga qxl -spice port=5931,disable-ticketing \ -device virtio-serial -device spicevmc,subtype=vdagent Then you can connect with spice client like this (after yum install spice-client): spicec -h localhost -p 5931 Then you can install spice-vdagent inside the guest, and see it in action (it has a daemon started by /etc/init.d/spice-vdagentd, and a per x session agent /usr/bin/spice-vdagent which gets auto started under gdm and a regular gnome session).
Great, it works and I am seeing AVC messages :^) Thanks.
Hans, could you do the following changes /var/run/spice-vdagentd.pid file move to /var/run/spice-vdagentd directory and /var/log/spice-vdagentd.log move to /var/log/spice-vdagentd directrory. The reason is simple. We will have the label for these dirs in the policy and dirs/files, which will be created in these dirs, will get the proper label always (the label is derived from the parent directory). Then you can add additional sock files, log files and the label will be correct and we won't need to change labeling in the policy.
I have done a scratch build with the spice-vdagent policy for testing http://koji.fedoraproject.org/koji/taskinfo?taskID=2609677
Hi Miroslav, Thanks for working on this! I've done a scratch build of spice-vdagent moving the log and pid files to the requested directories: http://koji.fedoraproject.org/koji/taskinfo?taskID=2610995 I've also given your scratchbuild policy a try, but it won't work in enforcing mode. In permissive move I get the following AVC's : type=USER_AVC msg=audit(1290165541.460:140): user pid=877 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.ConsoleKit.Manager member=GetSeats dest=org.freedesktop.ConsoleKit spid=3294 tpid=938 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1290165541.461:141): user pid=877 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.131 spid=938 tpid=3294 scontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:vdagent_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=AVC msg=audit(1290165726.316:142): avc: denied { read write } for pid=3294 comm="spice-vdagentd" name="vport0p1" dev=devtmpfs ino=10208 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=AVC msg=audit(1290165726.316:142): avc: denied { open } for pid=3294 comm="spice-vdagentd" name="vport0p1" dev=devtmpfs ino=10208 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1290165726.316:142): arch=c000003e syscall=2 success=yes exit=8 a0=405810 a1=2 a2=0 a3=0 items=0 ppid=1 pid=3294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="spice-vdagentd" exe="/usr/sbin/spice-vdagentd" subj=unconfined_u:system_r:vdagent_t:s0 key=(null) type=AVC msg=audit(1290165748.509:146): avc: denied { read write } for pid=3294 comm="spice-vdagentd" name="vport0p1" dev=devtmpfs ino=10208 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=AVC msg=audit(1290165748.509:146): avc: denied { open } for pid=3294 comm="spice-vdagentd" name="vport0p1" dev=devtmpfs ino=10208 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1290165748.509:146): arch=c000003e syscall=2 success=yes exit=8 a0=405810 a1=2 a2=0 a3=0 items=0 ppid=1 pid=3294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="spice-vdagentd" exe="/usr/sbin/spice-vdagentd" subj=unconfined_u:system_r:vdagent_t:s0 key=(null) type=AVC msg=audit(1290165764.521:156): avc: denied { read write } for pid=3294 comm="spice-vdagentd" name="vport0p1" dev=devtmpfs ino=10208 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=AVC msg=audit(1290165764.521:156): avc: denied { open } for pid=3294 comm="spice-vdagentd" name="vport0p1" dev=devtmpfs ino=10208 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1290165764.521:156): arch=c000003e syscall=2 success=yes exit=9 a0=405810 a1=2 a2=0 a3=0 items=0 ppid=1 pid=3294 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm="spice-vdagentd" exe="/usr/sbin/spice-vdagentd" subj=unconfined_u:system_r:vdagent_t:s0 key=(null) Also I noticed that spice-vdagent (the agent not the daemon) is not running in its own context. If possible (not sure if it needs its own context for that) I would like to see connecting to /var/run/spice-vdagentd/spice-vdagent-sock or to unix domain sockets with a context of unconfined_u:object_r:vdagent_var_run_t:s0 only be allowed by /usr/bin/spice-vdagent . Note that /usr/bin/spice-vdagent does not need to be restricted in any way. Thanks & Regards, Hans
(In reply to comment #10) > Hi Miroslav, > > Thanks for working on this! > > I've done a scratch build of spice-vdagent moving the log and pid files to the > requested directories: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2610995 Great. > > I've also given your scratchbuild policy a try, but it won't work in enforcing > mode. In permissive move I get the following AVC's : Thanks for testing. Just try to execute # restorecon -R -v /dev/vport0p1 Should fix some AVC messages. > > Also I noticed that spice-vdagent (the agent not the daemon) is not running in > its own context. If possible (not sure if it needs its own context for that) I > would like to see connecting to /var/run/spice-vdagentd/spice-vdagent-sock or > to unix domain sockets with a context of > unconfined_u:object_r:vdagent_var_run_t:s0 only be allowed by > /usr/bin/spice-vdagent . Note that /usr/bin/spice-vdagent does not need to be > restricted in any way. Yes, you are right. It is running in xdm_t domain and this domain is allowed to connect to /var/run/spice-vdagentd/spice-vdagent-sock. I will look at it. > Thanks & Regards, > > Hans
I have just tested it with your scratch build and it works fine for me. I am going to do a new selinux-policy scratch build for you.
(In reply to comment #12) > I have just tested it with your scratch build and it works fine for me. I am > going to do a new selinux-policy scratch build for you. http://koji.fedoraproject.org/koji/taskinfo?taskID=2617091
(In reply to comment #13) > (In reply to comment #12) > > I have just tested it with your scratch build and it works fine for me. I am > > going to do a new selinux-policy scratch build for you. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2617091 Thanks, looks pretty good, but I still get these 2 avc's in permissive mode (and a non working spice-vdagentd in enforcing mode): type=USER_AVC msg=audit(1290459948.245:23): user pid=859 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.ConsoleKit.Manager member=GetSeats dest=org.freedesktop.ConsoleKit spid=1601 tpid=1005 scontext=unconfined_u:system_r:vdagent_t:s0 tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1290459948.246:24): user pid=859 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.58 spid=1005 tpid=1601 scontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:vdagent_t:s0 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
Oops, sorry about that. I did the build with the wrong patch. To make sure it works with these rules execute # grep vdagent /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Then should work.
Miroslav is this in the current policy?