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)
Failure to setrlimit should not cause qemu to fail.
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.
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'
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)
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.
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
This has been triggered by the latest glibc update. The top ChangeLog entry reads: * Tue Aug 04 2009 Andreas Schwab <schwab> - 2.10.1-4 - Reenable setuid on pt_chown. Reverting to glibc-2.10.1-2 makes the problem go away.
Moving to glibc, but maybe we just need a policy update
*** Bug 516799 has been marked as a duplicate of this bug. ***
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
Switching selinux to permissive avoids the issue.
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
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.
*** Bug 511179 has been marked as a duplicate of this bug. ***
@comment #13. Why don't we fix anaconda instead of introducing a new setuid binary that breaks other packages ?
See bug 506219.
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.
*** Bug 517234 has been marked as a duplicate of this bug. ***
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)
No that should work also.
So, the permanent fix will be in a future selinux-policy package but, for now, changing /etc/fstab is a good workaround. True?
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.
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.
(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.
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!
Miroslav, Can you get this policy into F11/F10 ASAP
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)
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.
(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
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?)
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.
Just wanted to note which Jerry (of the three! :-) that dwalsh had made the request to for the separate bugzilla.
jvdelisle Too many Jerrys I don't think pt_chown should require mmap_zero
(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
In reply to comment #31 https://bugzilla.redhat.com/show_bug.cgi?id=517582
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.
Possible yes, but we won't do it. This needs to be fixed via setup, program.
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.
(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
*** Bug 517621 has been marked as a duplicate of this bug. ***
*** Bug 517618 has been marked as a duplicate of this bug. ***
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.
Did you update also selinux-policy-targeted ? # rpm -q selinux-policy-targeted
Created attachment 357943 [details] AVC alerts even after install of selinux-policy[-targeted]-3.6.12-78
After installing selinux-policy-targeted-3.6.12-78.fc11 from updates-testing as advised by Miroslav Grepl <mgrepl>, 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".
(In reply to comment #46) > After installing selinux-policy-targeted-3.6.12-78.fc11 from updates-testing as > advised by Miroslav Grepl <mgrepl>, 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.
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)
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
jakub, what do you think? I tend to agree with Daniel,
Deferring to Ulrich, but I think generally using O_CLOEXEC is the way to go.
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.
"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.
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?
"Me too" to Comment #54
Could you try to execute # yum reinstall selinux-policy-targeted
Have you guys fixed the entry in /etc/fstab?
(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?
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
(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.
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 :)
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.
(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
*** Bug 525581 has been marked as a duplicate of this bug. ***
*** Bug 525578 has been marked as a duplicate of this bug. ***
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
*** Bug 527003 has been marked as a duplicate of this bug. ***
*** Bug 527808 has been marked as a duplicate of this bug. ***
*** Bug 528751 has been marked as a duplicate of this bug. ***
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
setup-2.8.3-2.fc11 did not change /etc/fstab. Is lua-posix req'd?
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.
(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.
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
*** Bug 530192 has been marked as a duplicate of this bug. ***
*** Bug 529711 has been marked as a duplicate of this bug. ***
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.
*** Bug 582610 has been marked as a duplicate of this bug. ***
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,