Bug 515521

Summary: SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
Product: [Fedora] Fedora Reporter: Jerry Amundson <jamundso>
Component: setupAssignee: Ondrej Vasik <ovasik>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 11CC: artix, atodorov, berrange, bugzilla.redhat, drepper.fsp, dwalsh, dwmw2, dxklann, ebenes, eparis, gcosta, gczarcinski, gvarisco, itamar, jakub, James.Wilkinson, jaswinder, jistone, jkubin, jmorris, john.haxby, jonathan.underwood, jon.fairbairn, jvdelisle, lists.kho, loganjerry, markmc, marwalk, me, mgrepl, ovasik, pknirsch, rdassen, ros, rs, sascha, schwab, sds, streeter, tore, virt-maint, waf, walovaton, zcerza
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.8.3-3.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-27 02:42:16 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 480594    
Attachments:
Description Flags
Here is the policy from Rawhide.
none
AVC alerts even after install of selinux-policy[-targeted]-3.6.12-78 none

Description Jerry Amundson 2009-08-04 12:11:15 EDT
Description of problem:
virt-manager now fails to start vm's.

Version-Release number of selected component (if applicable):
Source RPM Packages           qemu-system-x86-0.10.5-3.fc11
Policy RPM                    selinux-policy-3.6.12-69.fc11

How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:


Summary:

SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.

Detailed Description:

SELinux denied access requested by qemu-kvm. It is not expected that this access
is required by qemu-kvm 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://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:svirt_t:s0:c472,c874
Target Context                system_u:system_r:svirt_t:s0:c472,c874
Target Objects                None [ process ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          jerry-opti755
Source RPM Packages           qemu-system-x86-0.10.5-3.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     jerry-opti755
Platform                      Linux jerry-opti755 2.6.29.6-217.2.3.fc11.x86_64
                              #1 SMP Wed Jul 29 16:02:42 EDT 2009 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 04 Aug 2009 10:57:06 AM CDT
Last Seen                     Tue 04 Aug 2009 10:57:06 AM CDT
Local ID                      ab8ee2e7-20e2-43d6-a120-be95300cdb7f
Line Numbers                  

Raw Audit Messages            

node=jerry-opti755 type=AVC msg=audit(1249401426.412:26475): avc:  denied  { setrlimit } for  pid=2272 comm="qemu-kvm" scontext=system_u:system_r:svirt_t:s0:c472,c874 tcontext=system_u:system_r:svirt_t:s0:c472,c874 tclass=process

node=jerry-opti755 type=SYSCALL msg=audit(1249401426.412:26475): arch=c000003e syscall=160 success=no exit=-13 a0=4 a1=7fff83502a00 a2=0 a3=7f92f28e4220 items=0 ppid=2270 pid=2272 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c472,c874 key=(null)
Comment 1 Daniel Walsh 2009-08-05 17:29:00 EDT
Failure to setrlimit should not cause qemu to fail.
Comment 2 Daniel Berrange 2009-08-06 06:40:41 EDT
Hmm, I don't see any code in QEMU that actually calls  'setrlimit'. Can you provide the /var/log/libvirt/$GUEST.log for the guest that fails to start due to this problem.
Comment 3 Jerry Amundson 2009-08-06 10:23:16 EDT
This is from /var/log/libvirt/qemu/RawhideStick.log-20090805 :

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name RawhideStick -uuid 308c56d6-c212-ae5f-20cb-4a01c714bb3d -monitor pty -pidfile /var/run/libvirt/qemu//RawhideStick.pid -boot c -drive file=/dev/sdc1,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:28:10:0e,vlan=0,model=virtio -net tap,fd=17,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0
qemu: could not open monitor device 'pty'
Comment 4 Jerry Amundson 2009-08-06 10:29:08 EDT
Sorry, missed this other AVC at the same time... 


Summary:

SELinux prevented qemu-kvm from using the terminal 0.

Detailed Description:

SELinux prevented qemu-kvm from using the terminal 0. In most cases daemons do
not need to interact with the terminal, usually these avc messages can be
ignored. All of the confined daemons should have dontaudit rules around using
the terminal. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy.
If you would like to allow all daemons to interact with the terminal, you can
turn on the allow_daemons_use_tty boolean.

Allowing Access:

Changing the "allow_daemons_use_tty" boolean to true will allow this access:
"setsebool -P allow_daemons_use_tty=1."

Fix Command:

setsebool -P allow_daemons_use_tty=1

Additional Information:

Source Context                system_u:system_r:svirt_t:s0:c472,c874
Target Context                system_u:object_r:devpts_t:s0:c472,c874
Target Objects                0 [ chr_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          jerry-opti755
Source RPM Packages           qemu-system-x86-0.10.5-3.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_daemons_use_tty
Host Name                     jerry-opti755
Platform                      Linux jerry-opti755 2.6.29.6-217.2.3.fc11.x86_64
                              #1 SMP Wed Jul 29 16:02:42 EDT 2009 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 04 Aug 2009 10:57:06 AM CDT
Last Seen                     Tue 04 Aug 2009 10:57:06 AM CDT
Local ID                      4ff90db3-eb84-488c-ad5e-b65b500606d2
Line Numbers                  

Raw Audit Messages            

node=jerry-opti755 type=AVC msg=audit(1249401426.401:26474): avc:  denied  { setattr } for  pid=2270 comm="qemu-kvm" name="0" dev=devpts ino=3 scontext=system_u:system_r:svirt_t:s0:c472,c874 tcontext=system_u:object_r:devpts_t:s0:c472,c874 tclass=chr_file

node=jerry-opti755 type=SYSCALL msg=audit(1249401426.401:26474): arch=c000003e syscall=92 success=no exit=-13 a0=7fff83501950 a1=0 a2=5 a3=7fff83501240 items=0 ppid=1 pid=2270 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c472,c874 key=(null)
Comment 5 Daniel Berrange 2009-08-06 10:40:23 EDT
I'm still at a loss to explain this.  No calls to setrlimit() appear when stracing QEMU:

# strace -e trace=getrlimit,setrlimit qemu-kvm -cdrom ~/boot.iso -monitor pty 
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
char device redirected to /dev/pts/13
char device redirected to /dev/pts/14
--- SIGALRM (Alarm clock) @ 0 (0) ---


And no setrlimit() calls appear in the source code. And I can launch VMs with similar configuration, without seeing any AVCs about setrlimit()

eg, this config works fine on my F11 host

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root /usr/bin/qemu-kvm -S -M pc -m 700 -smp 1 -name f11i686 -uuid 76079eb9-9321-f04d-57cf-14b57f62857c -monitor pty -pidfile /var/run/libvirt/qemu//f11i686.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/media/lacie-500-disk-2/virtual-machines/f11i686.img,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:35:fb:ac,vlan=0,model=virtio -net tap,fd=18,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 
char device redirected to /dev/pts/15
char device redirected to /dev/pts/16


So I've really no clue why your host should want setrlimit(), and I agree with Dan Walsh that we shouldn't allow this in the policy either.
Comment 6 David Klann 2009-08-08 12:43:16 EDT
Seeing this on my system as well.

Another data point: this occurs when attempting to start a guest from within the Virtual Machine Manager. setroubleshoot actually throws two messages. Summaries:

SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
SELinux prevented pt_chown from using the terminal 2.

Python trace:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 493, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup
    self.vm.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 287, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open monitor device 'pty'

F11 version info:
Virtual Machine Manager 0.7.0
kernel: 2.6.29.6-217.2.3.fc11.x86_64
qemu-kvm-0.10.6-1.fc11.x86_64virt-manager-0.7.0-5.fc11.x86_64
libvirt-0.6.2-14.fc11.x86_64
python-virtinst-0.400.3-8.fc11.noarch
libvirt-python-0.6.2-14.fc11.x86_64
virt-viewer-0.0.3-6.fc11.x86_64
selinux-policy-targeted-3.6.12-72.fc11.noarch
selinux-policy-3.6.12-72.fc11.noarch
Comment 7 Jerry James 2009-08-11 12:03:02 EDT
This has been triggered by the latest glibc update.  The top ChangeLog entry reads:

* Tue Aug 04 2009 Andreas Schwab <schwab@redhat.com> - 2.10.1-4
- Reenable setuid on pt_chown.

Reverting to glibc-2.10.1-2 makes the problem go away.
Comment 8 Mark McLoughlin 2009-08-11 13:34:13 EDT
Moving to glibc, but maybe we just need a policy update
Comment 9 Daniel Walsh 2009-08-11 18:49:12 EDT
*** Bug 516799 has been marked as a duplicate of this bug. ***
Comment 10 Jonas Nyman 2009-08-11 19:18:25 EDT
I can confirm this. 

Trying to start a virtual machine from within Virtual Machine Manager gives this error:

Error starting domain: internal error unable to start guest: qemu: could not open monitor device 'pty'

And

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 493, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup
    self.vm.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 287, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open monitor device 'pty'

And SElinux says: SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. 
SELinux prevented pt_chown from using the terminal 0. 

This happened when I updated the following packages:
glibc, glibc-common, headers and devel to version 
2.10.1-4.x86_64
Comment 11 Wayne Feick 2009-08-11 19:29:02 EDT
Switching selinux to permissive avoids the issue.
Comment 12 William Lovaton 2009-08-11 22:39:28 EDT
I'm definitely seeing this problem too after upgrading glibc, I made some comments in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=511179#c13
Comment 13 Andreas Schwab 2009-08-12 03:33:07 EDT
If selinux does not allow pt_chown then it must be updated.  This is required due to the anaconda bug that breaks /dev/pts permissions.
Comment 14 Andreas Schwab 2009-08-12 03:34:05 EDT
*** Bug 511179 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Berrange 2009-08-12 05:20:44 EDT
@comment #13.  Why don't we fix anaconda instead of introducing a new setuid binary that breaks other packages ?
Comment 16 Andreas Schwab 2009-08-12 08:03:01 EDT
See bug 506219.
Comment 17 Daniel Walsh 2009-08-12 14:45:52 EDT
Changing the line in /etc/fstab to 

devpts                  /dev/pts                devpts  gid=5,mode=620  0 0

then reboot.

Should allow you to run with SELinux enforcing again.

What is happening here is glibc is executing the chmod/setrlimit/fsetid calls under the covers for qemu, when qemu creates the pts device.  Since SELinux stops these calls from executing glibc returns an error and qemu dies.   It does not use the helper app, since it is running as root, I believe.  I can write policy to allow svirt_t -> pt_chown_exec_t -> pt_chown_t

But I am not sure glibc will do this if it is running as root.
Comment 18 Daniel Berrange 2009-08-13 05:03:47 EDT
*** Bug 517234 has been marked as a duplicate of this bug. ***
Comment 19 Jón Fairbairn 2009-08-13 13:29:15 EDT
re comment #17: Is the reboot necessary?
mount /dev/pts -o remount,gid=5,mode=620
seems to have worked for me (doesn't check that /etc/fstab has been modified correctly, though)
Comment 20 Daniel Walsh 2009-08-13 14:42:56 EDT
No that should work also.
Comment 21 Gene Czarcinski 2009-08-13 16:38:12 EDT
So, the permanent fix will be in a future selinux-policy package but, for now, changing /etc/fstab is a good workaround.  True?
Comment 22 Daniel Walsh 2009-08-13 16:51:14 EDT
No this is not an SELinux bug, it is caused by a configuration problem, that is triggering glibc to cleanup the permissions on /dev/pts files.

We are working on a policy for /usr/libexec/pt_chown right now in Rawhide, that will find it's way back into F11 policy.  But I am not sure if this would fix this problem.
Comment 23 Daniel Walsh 2009-08-13 17:02:26 EDT
Created attachment 357371 [details]
Here is the policy from Rawhide. 

I need people to play with it.  All you should need to do is to run

ptchown.sh as root and it will install the policy and setup the labeling.

THen run virtual machines, and see if they work.

Attach avc messages it, if you get any.
Comment 24 Josh Stone 2009-08-13 17:51:23 EDT
(In reply to comment #23)
> Created an attachment (id=357371) [details]
> Here is the policy from Rawhide. 
> 
> I need people to play with it.  All you should need to do is to run
> ptchown.sh as root and it will install the policy and setup the labeling.
> THen run virtual machines, and see if they work.
> Attach avc messages it, if you get any.  

I just tried this policy module, and it works perfectly for me.  My VMs now start without any AVC messages at all.
Comment 25 David Klann 2009-08-13 17:53:15 EDT
Same here:

% sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

Virtual machines start from within Virtual Machine Manager.

Thanks!
Comment 26 Daniel Walsh 2009-08-13 18:08:04 EDT
Miroslav, 

Can you get this policy into F11/F10 ASAP
Comment 27 Jerry 2009-08-14 00:12:11 EDT
I am seeing this problem when running gcc testsuite.  I think expect is triggering it.  I ran the script and it did not fix this. (the PID is for expect)

#
Summary:
#
 
#
SELinux is preventing pt_chown (unconfined_t) "mmap_zero" to <Unknown>
#
(unconfined_t).
#
 
#
Detailed Description:
#
 
#
SELinux denied access requested by pt_chown. The current boolean settings do not
#
allow this access. If you have not setup pt_chown to require this access this
#
may signal an intrusion attempt. If you do intend this access you need to change
#
the booleans on this system to allow the access.
#
 
#
Allowing Access:
#
 
#
Confined processes can be configured to to run requiring different access,
#
SELinux provides booleans to allow you to turn on/off access as needed. The
#
boolean allow_unconfined_mmap_low is set incorrectly.
#
Boolean Description:
#
Allow unconfined domain to map low memory in the kernel
#
 
#
 
#
Fix Command:
#
 
#
# setsebool -P allow_unconfined_mmap_low 1
#
 
#
Additional Information:
#
 
#
Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
#
023
#
Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
#
023
#
Target Objects None [ memprotect ]
#
Source pt_chown
#
Source Path /usr/libexec/pt_chown
#
Port <Unknown>
#
Host quattro.localdomain
#
Source RPM Packages glibc-common-2.10.1-4
#
Target RPM Packages
#
Policy RPM selinux-policy-3.6.12-72.fc11
#
Selinux Enabled True
#
Policy Type targeted
#
MLS Enabled True
#
Enforcing Mode Enforcing
#
Plugin Name catchall_boolean
#
Host Name quattro.localdomain
#
Platform Linux quattro.localdomain
#
2.6.29.6-217.2.3.fc11.x86_64 #1 SMP Wed Jul 29
#
16:02:42 EDT 2009 x86_64 x86_64
#
Alert Count 195
#
First Seen Thu 13 Aug 2009 08:03:43 PM PDT
#
Last Seen Thu 13 Aug 2009 09:05:56 PM PDT
#
Local ID 284f2a3e-8592-47c0-80da-73724d72108c
#
Line Numbers
#
 
#
Raw Audit Messages
#
 
#
node=quattro.localdomain type=AVC msg=audit(1250222756.953:83): avc: denied { mmap_zero } for pid=4939 comm="pt_chown" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect
#
 
#
node=quattro.localdomain type=AVC msg=audit(1250222756.953:83): avc: denied { mmap_zero } for pid=4939 comm="pt_chown" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect
#
 
#
node=quattro.localdomain type=AVC msg=audit(1250222756.953:83): avc: denied { mmap_zero } for pid=4939 comm="pt_chown" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect
#
 
#
node=quattro.localdomain type=SYSCALL msg=audit(1250222756.953:83): arch=c000003e syscall=125 success=no exit=-1264681000 a0=7fff77194014 a1=0 a2=7fff75085e80 a3=7fff60c559b0 items=0 ppid=18067 pid=4939 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="pt_chown" exe="/usr/libexec/pt_chown" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Comment 28 Jerry 2009-08-14 00:33:25 EDT
Applying the change to devpts as described in Comment #17 resolves the issue with running the gcc testsuite.

Thanks for that fix.  Let me know if you need me to test anything else.
Comment 29 Miroslav Grepl 2009-08-14 03:13:40 EDT
(In reply to comment #26)
> Miroslav, 
> 
> Can you get this policy into F11/F10 ASAP  

Added to selinux-policy-3.6.12-78.fc11

http://koji.fedoraproject.org/koji/buildinfo?buildID=127255
Comment 30 "FeRD" (Frank Dana) 2009-08-14 04:49:57 EDT
This one bit me earlier, when I tried to start a VM for the first time in quite a while. I'm now running with the comment #17 fix (change to /dev/pts mounting), which solved the problem on my system without requiring any changes to selinux policy. Thus, I haven't tried the updated policy that Dan attached in comment #23.

My question is, what's the security exposure (if any) to running with /dev/pts mounted gid=5,mode=620? Additionally, what's the long-term "correct" fix for this bug? Is this updated fstab entry now the "correct" way to mount /dev/pts, going forward, or should we revert the changes and rely on updated selinux policy to solve this, once that policy is pushed out?

(Actually, that begs the question: WILL updated selinux policy solve this completely, once it's pushed out?)
Comment 31 Daniel Walsh 2009-08-14 08:46:11 EDT
The bug is that the install procedure did not setup the /dev/pts with the gid=5,mode=620 flag.  It was this way in F10 and is this way in F12.  I am hoping that this will be fixed somehow in F11.  

Without this fix, I believe the terminals are setup with permission too low, so other proceses could evesdrop on the terminal sessions.  (I am guessing this is the problem.) 

Glibc has a fix to make sure the protection on the terminals is correct when they are created, if not glibc fixes the permissions using pt_chown.  Since the install had setup /etc/fstab, incorrectly when qemu asked pt_chown to create a new pts, it noticed that the pty was created with the incorrect permission and fixes it, but the pt_chown was running under the svirt_t label, so it did not have the permission to fix the pty, causing the glibc function call to fail, killing qemu.

My SELinux fix in policy now transitions from svirt_t to pt_chown_t, when executing pt_chown.  pt_chown has the access to fix the terminal.

I would fix the /etc/ftab file and install the SELinux fix, when it gets released.
If you install the ptchown package that I attached, it will get overwritten in the next selinux-policy release.

Jerry, can you open up a separate bugzilla on the pt_chown requiring mmap_zero, please.
Comment 32 Jerry Amundson 2009-08-14 10:45:39 EDT
Just wanted to note which Jerry (of the three! :-) that dwalsh had made the request to for the separate bugzilla.
Comment 33 Daniel Walsh 2009-08-14 10:50:59 EDT
jvdelisle@verizon.net

Too many Jerrys

I don't think pt_chown should require mmap_zero
Comment 34 Mark McLoughlin 2009-08-14 13:23:50 EDT
(In reply to comment #29)
> (In reply to comment #26)
> > Miroslav, 
> > 
> > Can you get this policy into F11/F10 ASAP  
> 
> Added to selinux-policy-3.6.12-78.fc11
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=127255

Could you add the bug number to the update, please:

  https://admin.fedoraproject.org/updates/selinux-policy-3.6.12-78.fc11
Comment 36 Jerry 2009-08-14 15:30:04 EDT
Is it possible to push an update to SELINUX policy that will run a clean-up script that would examine the fstab and if it is found to have the wrong default devpts, simply replace the devpts line and notify the use to reboot or just execute the mount?

If any devpts that does not match the anaconda default one is found, do nothing.
Comment 37 Daniel Walsh 2009-08-14 16:02:31 EDT
Possible yes, but we won't do it.  This needs to be fixed via setup, program.
Comment 38 Ondrej Vasik 2009-08-17 08:18:25 EDT
Having fix in setup is ugly, as setup is not the one who caused the problem. It was broken by installation - so by anaconda - setup just creates empty /etc/fstab file. Similar reports are #510382 and #506219. 

I know, setup is owner, fix in instalator does not solve the issue for already installed machines. From this point of view it does make sense to have fix in setup package. 

But as setup could have only <lua> scriptlets and no dependencies for %post at all, any such fix would look very ugly (various checks for program existence and running them only in those cases). Additionally I don't know if something like generic `sed -i -e 's/devpts  defaults/devpts  gid=5,mode=620/' /etc/fstab` is good way to solve that issue.
Comment 39 Mark McLoughlin 2009-08-18 06:45:21 EDT
(Taking on the role of bugbot since the bug number isn't properly added to the update)

selinux-policy-3.6.12-78.fc11 has been pushed to the Fedora 11 testing repository.

If problems still persist, please make note of it in this bug report.

If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'.

You can provide feedback for this update here: https://admin.fedoraproject.org/updates/F11/FEDORA-2009-8536
Comment 40 Mark McLoughlin 2009-08-18 06:46:58 EDT
*** Bug 517621 has been marked as a duplicate of this bug. ***
Comment 41 Mark McLoughlin 2009-08-18 06:47:13 EDT
*** Bug 517618 has been marked as a duplicate of this bug. ***
Comment 43 Ralf Oltmanns 2009-08-19 09:28:47 EDT
Just to give some feedback:

I installed selinux-policy-3.6.12-78.fc11 from updates-testing, restarted my F11 and tried to start my VM from out Virtual Machine Manager.

Despite the update I have the same results a before:

SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
SELinux prevented pt_chown from using the terminal 1.

If you need more details, let me know.
Comment 44 Miroslav Grepl 2009-08-19 09:48:43 EDT
Did you update also selinux-policy-targeted ?

# rpm -q selinux-policy-targeted
Comment 45 Ralf Oltmanns 2009-08-19 10:29:52 EDT
Created attachment 357943 [details]
AVC alerts even after install of selinux-policy[-targeted]-3.6.12-78
Comment 46 Ralf Oltmanns 2009-08-19 10:31:42 EDT
After installing selinux-policy-targeted-3.6.12-78.fc11 from updates-testing as advised by Miroslav Grepl <mgrepl@redhat.com>, my VM did start.

AVC signaled the following messages, though:

SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t.
SELinux prevented qemu-kvm from using terminal 2.
SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t.
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t.

But on my colleagues machine (F11) with a almost identical setup still fails to start his VM although his machine is up2date and also has installed selinux-policy-3.6.12-78.fc11 and selinux-policy-targeted-3.6.12-78.fc11 followed be restarting his system.

See the AVC messages of his machine in the attached file "AVC alerts even after install of selinux-policy[-targeted]-3.6.12-78".
Comment 47 Jerry Amundson 2009-08-19 12:13:56 EDT
(In reply to comment #46)
> After installing selinux-policy-targeted-3.6.12-78.fc11 from updates-testing as
> advised by Miroslav Grepl <mgrepl@redhat.com>, my VM did start.
> 
> AVC signaled the following messages, though:

Yes, similiar for me, VM did start, but with this:

SELinux prevented qemu-kvm from using the terminal 1. 
SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. 
SELinux prevented qemu-kvm from using the terminal 2.
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t.
SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t.
SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t.

The system has fstab back to :
devpts   /dev/pts      devpts defaults   0 0
updated to:
selinux-policy-targeted-3.6.12-78.fc11.noarch
selinux-policy-3.6.12-78.fc11.noarch
and then rebooted.
Comment 48 Daniel Walsh 2009-08-19 17:38:22 EDT
allow ptchown_t ptmx_t:chr_file { read write ioctl };
allow ptchown_t self:capability fsetid;

These should be added.


allow ptchown_t svirt_image_t:file { read write };
allow ptchown_t svirt_var_run_t:file { read write };
allow ptchown_t tun_tap_device_t:chr_file { read write };

These are caused by leaks in qemu.

qemu should close all file descriptors on exec

fcntl(fd, F_SETFD, FD_CLOEXEC)
Comment 49 Daniel Berrange 2009-08-20 04:46:26 EDT
QEMU does not know that ptchown even exists, let alone is executed. All qemu does is  openpty(), and glibc secretly exec's this binary. Thus apps have no idea that they actually need to be FD_CLOSEEXEC'ing anything. glibc should be explicitly closing all file descriptors from 0 to sysconf(_SC_OPEN_MAX) to avoid this leak, particularly since this is a setuid binary. 

Adding those rules to ptchown_t doesn't seem like a viable approach, since ptchown can be called from any application that does openpty() or grantpt(), and thus pretty much any open file on the system could be leaked by apps which don't realize there is a binary being secretly exec'd here
Comment 50 Daniel Walsh 2009-08-20 09:34:15 EDT
jakub, what do you think?

I tend to agree with Daniel,
Comment 51 Jakub Jelinek 2009-08-20 09:42:53 EDT
Deferring to Ulrich, but I think generally using O_CLOEXEC is the way to go.
Comment 52 Ulrich Drepper 2009-08-20 10:31:17 EDT
It is completely wrong to ever do the "close every file descriptor I'm not interested in to pass on" dance.

This would assume that we know what all the file descriptors are for.  Which we cannot.

There might be descriptors used in NSS modules.  In audit modules.  In atfork hooks of libraries etc.  We'd break all that code.

Programmers have to learn to always use O_CLOEXEC (or FD_CLOEXEC) if necessary.  I'm fine with not caring about about systems.  So, just use a self-defined function open_local() or so instead of open() and transparently add O_CLOEXEC.  As a start, you could even use ld's --wrap option to automatically change the references and then define __wrap_open using the __open entry point.

And one more thing: pt_chown is perhaps now the only helper program used.  But there can always be more.  Again, assume a NSS service which needs to do something requiring a state transition or UID/GID elevation.
Comment 53 Ondrej Vasik 2009-09-23 14:23:29 EDT
"bugbot" ;) - as you switched the bugzilla to ON_QA - ok to close that bugzilla? I'm reluctant to add more <lua> rubbish into setup %post scriptlets.
Comment 54 Jerry Amundson 2009-09-23 15:59:47 EDT
Just to be clear, I still see these when starting a virtual machine on this fc11 box:

SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t. 
SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. 
SELinux prevented qemu-kvm from using the terminal 3. 
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t. 
SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t. 
SELinux prevented qemu-kvm from using the terminal 2. 

This system is fully updated Fedora 11, with the attachment "Here is the policy from Rawhide." applied.

Of course, with
mount /dev/pts -o remount,gid=5,mode=620
there are no avc's, which naturally means a freshly installed/updated system would still be unfixed, right?
Comment 55 Jonathan Underwood 2009-09-23 16:22:58 EDT
"Me too" to Comment #54
Comment 56 Miroslav Grepl 2009-09-24 04:15:28 EDT
Could you try to execute

# yum reinstall selinux-policy-targeted
Comment 57 Daniel Walsh 2009-09-24 11:29:51 EDT
Have you guys fixed the entry in /etc/fstab?
Comment 58 Jerry Amundson 2009-09-24 14:11:52 EDT
(In reply to comment #57)
> Have you guys fixed the entry in /etc/fstab?  

Yes, and no.
What I know is this:
1. The avc's referenced herein do not occur with the "fixed" devpts mount.
2. The avc's referenced herein *do* occur with the default devpts mount.
3. An install of fc11, and all updates thereafter, maintain the default devpts mount.

So what I don't know is, with the "fixed" devpts mount, what am I testing?
Comment 59 Daniel Walsh 2009-09-24 14:46:47 EDT
 I just wanted to make sure you guys new there was a fix.  If you are testing the policy then thanks.

It certainly looks like those rules are in the selinux-policy-3.6.12-82.fc11
Comment 60 Jerry Amundson 2009-09-25 16:36:48 EDT
(In reply to comment #59)
>  I just wanted to make sure you guys new there was a fix.  If you are testing
> the policy then thanks.
> 
> It certainly looks like those rules are in the selinux-policy-3.6.12-82.fc11  

That's what I thought.
Then, I'm just waiting for an update to setup (or whatever...) to fix the devpts mount in /etc/fstab.
Comment 61 Dagan McGregor 2009-09-26 00:05:33 EDT
 I applied the fix to devpts in /etc/fstab also, and had no further problems.

 I am just watching this bug to see that the problem won't appear in future installs :)
Comment 62 Daniel Walsh 2009-09-28 16:22:10 EDT
selinux-policy-3.6.12-82.fc11

Definitely has 

SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t. 
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t. 
SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t.
Comment 63 Mark McLoughlin 2009-10-01 12:27:55 EDT
(In reply to comment #53)
> "bugbot" ;) - as you switched the bugzilla to ON_QA - ok to close that
> bugzilla? I'm reluctant to add more <lua> rubbish into setup %post scriptlets.  

Ah, sorry - I got confused; I thought all we needed was an selinux-policy fix and that was in updates-testing

But yeah, this bug is filed against setup because we're talking about something to fixup the /dev/pts line in /etc/fstab
Comment 64 Mark McLoughlin 2009-10-01 12:30:54 EDT
*** Bug 525581 has been marked as a duplicate of this bug. ***
Comment 65 Mark McLoughlin 2009-10-01 12:35:36 EDT
*** Bug 525578 has been marked as a duplicate of this bug. ***
Comment 66 Fedora Update System 2009-10-08 10:23:37 EDT
setup-2.8.3-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/setup-2.8.3-2.fc11
Comment 67 Mark McLoughlin 2009-10-09 06:11:04 EDT
*** Bug 527003 has been marked as a duplicate of this bug. ***
Comment 68 Zack Cerza 2009-10-09 10:16:48 EDT
*** Bug 527808 has been marked as a duplicate of this bug. ***
Comment 69 Ondrej Vasik 2009-10-13 11:56:34 EDT
*** Bug 528751 has been marked as a duplicate of this bug. ***
Comment 70 Fedora Update System 2009-10-13 21:33:09 EDT
setup-2.8.3-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10401
Comment 71 Jerry Amundson 2009-10-14 12:16:15 EDT
setup-2.8.3-2.fc11 did not change /etc/fstab. 
Is lua-posix req'd?
Comment 72 Ondrej Vasik 2009-10-19 05:42:53 EDT
Strange, it should not be required. /bin/sh and sed are required, but their availability is checked. Anyway, more generic sed expression and comment about change should be added, so rebuilt. Could you please test rpm from http://koji.fedoraproject.org/koji/taskinfo?taskID=1753581 ? TIA.
Comment 73 Jerry Amundson 2009-10-19 10:39:55 EDT
(In reply to comment #72)
> Strange, it should not be required. /bin/sh and sed are required, but their
> availability is checked. Anyway, more generic sed expression and comment about
> change should be added, so rebuilt. Could you please test rpm from
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1753581 ? TIA.  

setup-2.8.3-3 did modify /etc/fstab adequately. The "ugly" comment is not needed, however.
Comment 74 Fedora Update System 2009-10-20 20:51:36 EDT
setup-2.8.3-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10401
Comment 75 Mark McLoughlin 2009-10-23 09:01:32 EDT
*** Bug 530192 has been marked as a duplicate of this bug. ***
Comment 76 Mark McLoughlin 2009-10-23 09:56:24 EDT
*** Bug 529711 has been marked as a duplicate of this bug. ***
Comment 77 Fedora Update System 2009-10-27 02:42:01 EDT
setup-2.8.3-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 78 Daniel Walsh 2010-04-15 11:02:53 EDT
*** Bug 582610 has been marked as a duplicate of this bug. ***
Comment 79 Robert Story 2010-05-01 11:43:43 EDT
I'm trying KVM for the first time, and I'm getting this error. rpm -qi reports that I have setup-2.8.3.3... Do I need to do something to trigger the update for fstab?

Things worked fine after I ran "mount /dev/pts -o remount,gid=5,mode=620", just wanted to note here that the extra step is needed,