Bug 503421 - setsebool -P allow_daemons_use_tty=1 doesn't work with virtual machine
Summary: setsebool -P allow_daemons_use_tty=1 doesn't work with virtual machine
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-31 20:52 UTC by Rene Pilz
Modified: 2009-06-13 20:30 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-06-13 20:30:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Output of the ausearch-command (590 bytes, text/plain)
2009-06-05 10:07 UTC, Rene Pilz
no flags Details
output of the getsebool-command (you can see, it should be allowed!) (81 bytes, text/plain)
2009-06-05 10:08 UTC, Rene Pilz
no flags Details
the full selinux-alert entry (2.60 KB, text/plain)
2009-06-05 10:09 UTC, Rene Pilz
no flags Details
virtmanager log (I don't know, but this entries are all completely old??) (25.51 KB, application/octet-stream)
2009-06-05 10:09 UTC, Rene Pilz
no flags Details
logfile of the virtual-machine (/var/log/libvirt/qemu/...) (719 bytes, text/plain)
2009-06-05 10:11 UTC, Rene Pilz
no flags Details

Description Rene Pilz 2009-05-31 20:52:16 UTC
Description of problem:

When configuring a virtual machine (using virt-manager) and adding /dev/ttyS0 to this virtual machine, there always comes a SELinux-Error not removeable.

Version-Release number of selected component (if applicable):
kvm.x86_64                           74-10.fc10                   installed 
libselinux.x86_64                    2.0.78-1.fc10                installed     
selinux-policy-minimum.noarch        3.5.13-59.fc10               updates       
selinux-policy-mls.noarch            3.5.13-59.fc10               updates       


How reproducible:
each time

Steps to Reproduce:
1. configuring a virtual machine,
2. adding /dev/ttyS0 to this machine
3. start the machine

Sniplet of /etc/libvirt/qemu/<virtual-machine-config>:
<serial type="dev">
        <source path="/dev/ttyS0"/>
        <target port="0"/>
      </serial>


Actual results:

The SELinux-Alerting-Monitor tells me that I should do a
sudo setsebool -P allow_daemons_use_tty=1

But this changes nothing.

Each time I start the virutal machine, I got the error.
The Virtual Machine also cannot connect to /dev/ttyS0

When doing a "getsebool allow_daemons_use_tty" it tells me "allowed" ???

Expected results:


Additional info:

Comment 1 Mark McLoughlin 2009-06-04 14:32:51 UTC
Please include the full SELinux error - e.g. try "ausearch -m AVC -ts recent"

Also, please include ~/.virt-manager/virt-manager.log and the log file for the guest from /var/log/libvirt/qemu

Comment 2 Rene Pilz 2009-06-05 10:07:59 UTC
Created attachment 346629 [details]
Output of the ausearch-command

Comment 3 Rene Pilz 2009-06-05 10:08:44 UTC
Created attachment 346630 [details]
output of the getsebool-command (you can see, it should be allowed!)

Comment 4 Rene Pilz 2009-06-05 10:09:17 UTC
Created attachment 346631 [details]
the full selinux-alert entry

Comment 5 Rene Pilz 2009-06-05 10:09:57 UTC
Created attachment 346632 [details]
virtmanager log (I don't know, but this entries are all completely old??)

Comment 6 Rene Pilz 2009-06-05 10:11:36 UTC
Created attachment 346634 [details]
logfile of the virtual-machine (/var/log/libvirt/qemu/...)

Comment 7 Mark McLoughlin 2009-06-05 10:56:14 UTC
Thanks Rene

dwalsh: this is F10; do we need an init_system_domain(qemu_t) ?

Comment 8 Daniel Walsh 2009-06-05 14:57:34 UTC
Try 
# setsebool -P qemu_use_comm 1

setroubleshoot is suggesting the incorrect boolean.

I will update the setroubleshoot plugins to report the correct boolean.

Comment 9 Daniel Walsh 2009-06-05 15:11:40 UTC
Fixed in setroubleshoot-plugins-2.0.18-1

Comment 10 Rene Pilz 2009-06-06 12:40:02 UTC
dwalsh: 
setsebool -P qemu_use_comm 1

worked perfect. Now no error rises (otherwise, /dev/ttyS0 is not available from the virtual-machine, but I guess there is anythink not configured perfect).

Regards
 Rene


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