Summary: SELinux is preventing /usr/lib/nspluginwrapper/npviewer.bin "execute" access on /usr/sbin/pcscd. Detailed Description: SELinux denied access requested by npviewer.bin. It is not expected that this access is required by npviewer.bin 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 unconfined_u:unconfined_r:nsplugin_t:s0 Target Context system_u:object_r:pcscd_exec_t:s0 Target Objects /usr/sbin/pcscd [ file ] Source npviewer.bin Source Path /usr/lib/nspluginwrapper/npviewer.bin Port <Unknown> Host (removed) Source RPM Packages nspluginwrapper-1.3.0-14.fc14 Target RPM Packages pcsc-lite-1.6.4-1.fc14 Policy RPM selinux-policy-3.9.5-7.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.35.4-28.fc14.i686.PAE #1 SMP Wed Sep 15 01:57:00 UTC 2010 i686 i686 Alert Count 2 First Seen Fri 01 Oct 2010 04:42:13 PM CEST Last Seen Fri 01 Oct 2010 04:42:18 PM CEST Local ID c38b8f96-19e3-44e7-a16b-8d99f76e6656 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1285944138.81:21237): avc: denied { execute } for pid=5872 comm="npviewer.bin" name="pcscd" dev=sda3 ino=1696035 scontext=unconfined_u:unconfined_r:nsplugin_t:s0 tcontext=system_u:object_r:pcscd_exec_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1285944138.81:21237): arch=40000003 syscall=11 success=no exit=-13 a0=82edb69 a1=bf884f8c a2=bf888c6c a3=2 items=0 ppid=5851 pid=5872 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="npviewer.bin" exe="/usr/lib/nspluginwrapper/npviewer.bin" subj=unconfined_u:unconfined_r:nsplugin_t:s0 key=(null) Hash String generated from catchall,npviewer.bin,nsplugin_t,pcscd_exec_t,file,execute audit2allow suggests: #============= nsplugin_t ============== allow nsplugin_t pcscd_exec_t:file execute;
Flash did this and probably shouldn't, but it could be nice if SElinux could control it somehow other than offering to report it. I guess flash access to smart card can be useful in some cases, so perhaps it deserves a bool.
Boy that is strange. pcscd guys can you think of any reason to execute the daemon code from user space?
Starting from pcsc-lite 1.6.0, upstream has added "autostart" support which means that libpcsclite tries to start pcscd when it's not running, expecting it to be setuid root. However, in Fedora package we are still using the init script to start it and pcscd binary is NOT setuid root. I suspect the reporter's pcscd had either crashed or the init script was disabled, causing libpcsclite to try to start it. What's your opinion about having pcscd as setuid root? I honestly don't like the idea at all at first glance.
Correct, pcsc-lite was installed but the pcscd wasn't enabled/started. (FWIW I don't want anything other than systemd to start system services, neither on startup nor on demand.)
> (FWIW I don't want anything other than systemd to start system services, > neither on startup nor on demand.) This leads to some interesting questions on how to fix this. Do we turn off autostart? This requires pcscd to be started explicitly. I believe that's how it currently works in fedora. The current code is accomplishing Mads Kiilerich's requirements: SELinux is preventing flash from starting pcscd. bob
(In reply to comment #5) > This leads to some interesting questions on how to fix this. Do we turn off > autostart? In my opinion, yes. Or at least change it fundamentally. If something userspace wants to start a system service it shouldn't do that by forking it, but for example by asking some system process to start it - for example by sending a dbus message to for example systemd. > This requires pcscd to be started explicitly. I believe that's how it currently > works in fedora. Yes. That allows me to disable pcscd if I don't want it. > The current code is accomplishing Mads Kiilerich's requirements: SELinux is > preventing flash from starting pcscd. Yes, but SELinux is an extra and brutal safety guard that verifies that the system behaves correctly. The system should behave correctly even without SELinux and without hanging in the safety belt.
In the next pcsc-lite version pcscd will not be suid root any more. But it will be sgid "pcscd". Mads, would that be ok for you or do you still want to use systemd?
Suid root is very evil, but sometimes "necessary". Some kind of sgid is less evil - but still not good. AFAIK pcscd is a system service shared among all users. I think that it is very wrong that such a service is started as a fork from a user library. We have standard ways for starting system services, and when each subsystem implements its own way of doing it the system gets hard to manage and debug. I think the existing way of doing it was fine. What is the problem that motivated the change? But you should ask those who ensures that the whole system works consistent, secure and efficient. I guess that is mostly Dan and Lennart.
The idea is that most of the time on most systems pcscd is not needed. So starting it on request is a good solution. What "standard ways" do you propose instead of a fork from a library? Maybe systemd could work. I did not know this software before. Is it used/available on all/most of the GNU systems?
dbus activation would be the standard way. You could notice that it was not working and send a dbus message to ask the system to start the daemon.
Do you have an URL describing the use of dbus in that specific case? A patch for pcsc-lite would be even better :-) Thanks.
Sorry know. We use python interfaces, but I am sure there is lots of data out there for implementing this.
Actually if you look at setroubleshoot package and seapplet, this is used to start the setroubleshootd daemon.
(In reply to comment #11) > Do you have an URL describing the use of dbus in that specific case? > A patch for pcsc-lite would be even better :-) > Thanks. I just submitted patches for systemd socket activation to the muscle mailing list: http://archives.neohapsis.com/archives/dev/muscle/2011-q2/0138.html The way it works is that systemd opens a listening UNIX socket and when a request arrives on the socket from user space library, systemd starts up the pcscd daemon on demand.
pcsc-lite-1.7.4-2.fc16 in rawhide is now built with systemd socket activation support. Upstream hasn't yet gotten around to reviewing the patches, but they should be good enough for use in Fedora. Autostarting pcscd by using systemd socket activation also plays nice with SELinux, compared to the previous way of autostarting pcscd by forking from user space library. Closing the ticket.