Bug 729997 - FIXED_IN_GIT: SELinux is preventing /usr/sbin/pcscd from 'getattr' accesses on the sock_file /run/pcscd.comm.
Summary: FIXED_IN_GIT: SELinux is preventing /usr/sbin/pcscd from 'getattr' accesses o...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:62eade48429a87a591d180b2c41...
: 735564 735676 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-11 13:57 UTC by Michal Nowak
Modified: 2013-03-08 02:12 UTC (History)
15 users (show)

Fixed In Version: systemd-35-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-09 17:08:03 UTC


Attachments (Terms of Use)

Description Michal Nowak 2011-08-11 13:57:19 UTC
abrt version: 2.0.5
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.0.1-3.fc16.x86_64
reason:         SELinux is preventing /usr/sbin/pcscd from 'getattr' accesses on the sock_file /run/pcscd.comm.
time:           Thu Aug 11 15:57:03 2011

description:
:SELinux is preventing /usr/sbin/pcscd from 'getattr' accesses on the sock_file /run/pcscd.comm.
:
:*****  Plugin catchall (100. confidence) suggests  ***************************
:
:If you believe that pcscd should be allowed getattr access on the pcscd.comm sock_file by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
:Do
:allow this access for now by executing:
:# grep pcscd /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:pcscd_t:s0
:Target Context                system_u:object_r:var_run_t:s0
:Target Objects                /run/pcscd.comm [ sock_file ]
:Source                        pcscd
:Source Path                   /usr/sbin/pcscd
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           pcsc-lite-1.7.4-2.fc16
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-15.fc16
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.0.1-3.fc16.x86_64 #1 SMP Mon Aug 8
:                              18:13:59 UTC 2011 x86_64 x86_64
:Alert Count                   1
:First Seen                    Thu 11 Aug 2011 03:56:43 PM CEST
:Last Seen                     Thu 11 Aug 2011 03:56:43 PM CEST
:Local ID                      de2566d0-59a8-4a35-8a5d-03f733271453
:
:Raw Audit Messages
:type=AVC msg=audit(1313071003.333:79): avc:  denied  { getattr } for  pid=1799 comm="pcscd" path="/run/pcscd.comm" dev=tmpfs ino=11953 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
:
:
:type=SYSCALL msg=audit(1313071003.333:79): arch=x86_64 syscall=stat success=no exit=EACCES a0=413efd a1=7fff689d3df0 a2=7fff689d3df0 a3=7fff689d3b60 items=0 ppid=1 pid=1799 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=pcscd exe=/usr/sbin/pcscd subj=system_u:system_r:pcscd_t:s0 key=(null)
:
:Hash: pcscd,pcscd_t,var_run_t,sock_file,getattr
:
:audit2allow
:
:#============= pcscd_t ==============
:allow pcscd_t var_run_t:sock_file getattr;
:
:audit2allow -R
:
:#============= pcscd_t ==============
:allow pcscd_t var_run_t:sock_file getattr;
:

Comment 1 Daniel Walsh 2011-08-11 20:10:16 UTC
Systemd is not creating sock_files with the correct labels.

Comment 2 Lennart Poettering 2011-08-21 12:15:08 UTC
Uhmm, then the SELinux policy is borked. We create all sockets with the logic and take the service binary into account.

Comment 3 Lennart Poettering 2011-08-21 12:17:58 UTC
Does pcscd actually employ systemd-style socket activation? If not then systemd is not involved at all.

Comment 4 Daniel Walsh 2011-08-22 16:25:26 UTC
Lennart, I think the problem is the SELinux code in systemd is not creating sock_files with the correct context, it is just labeling the end of the socket correctly.

A connection between a client and a pscd_t socket, involves being able to r/w the sock_file as well as communicate with the pscd_t.

The problem is systemd creates the sock_file it does not execute the code to create it with the right label, I believe it does similar code for fifo_file.

pcsc-lite is socket activated.

rpm -ql pcsc-lite | grep sock
/lib/systemd/system/pcscd.socket

Comment 5 Lennart Poettering 2011-08-29 14:17:34 UTC
(In reply to comment #4)
> Lennart, I think the problem is the SELinux code in systemd is not creating
> sock_files with the correct context, it is just labeling the end of the socket
> correctly.

I am not sure I can parse this. Could you elaborate? What systemd does is invoke setsockcreatecon() before invoking socket(), followed by and setsockcreatecon(NULL), and then the bind(). Is that not correct? Should we call setsockcreatecon(NULL) only after the bind()?

Comment 6 Daniel Walsh 2011-08-29 16:30:28 UTC
The problem is you need to call 

matchpathcon("/var/run/SOCKET". &scon);
setfscreatcon(scon)
CREATE_SOCKET(/var/run/SOCKET")
setfsreatecon(NULL)
setsockcreatecon()
socket()
setsockcreatecon(NULL)

Comment 7 Lennart Poettering 2011-08-29 19:56:18 UTC
(In reply to comment #6)
> The problem is you need to call 
> 
> matchpathcon("/var/run/SOCKET". &scon);
> setfscreatcon(scon)
> CREATE_SOCKET(/var/run/SOCKET")

What's CREATE_SOCKET supposed to be? You create fs sockets with bind(), there is no way to explicitly create a socket in the fs on Unix/Linux, only a side effect of bind(). So are you suggesting I shoud have setfscreatecon() around bind()?

> setfsreatecon(NULL)
> setsockcreatecon()
> socket()
> setsockcreatecon(NULL)

Comment 8 Kay Sievers 2011-08-29 21:56:06 UTC
We currently do:
  getfilecon(exe, &con);

  setsockcreatecon(&con);
  socket();
  setsockcreatecon(NULL);

which set the context of the socket file descriptor to the
context of the binary.

The socket file is created only later with bind(). Does that
need something like:
  matchpathcon("/var/run/SOCKET". &con);
  setfscreatcon(&con)
  bind();
  setfsreatecon(NULL);

is needed to work properly for UNIX sockets we create on behalf
of other services?

And if, why doesn't the kernel let the file inherit context of
the earlier created socket?

Comment 9 Kay Sievers 2011-08-29 21:59:13 UTC
(In reply to comment #8)
> The socket file is created only later with bind(). Does that
> need something like:
>   matchpathcon("/var/run/SOCKET". &con);
>   setfscreatcon(&con)
>   bind();
>   setfsreatecon(NULL);

Or can we here use the same context we retrieved from the binary
instead of matching the path?

Comment 10 Daniel Walsh 2011-08-30 09:26:10 UTC
I would figure something like the following would work.



           char *sock_file="/run/pcscd.comm";

           matchpatchcon(sock_file, S_IFSOCK, &scon);
           setfscreatecon(scon);
           setsockcreatecon("system_u:system_r:pcscd_t:s0");
           sfd = socket(AF_UNIX, SOCK_STREAM, 0);
           if (sfd == -1)
               handle_error("socket");

           memset(&my_addr, 0, sizeof(struct sockaddr_un));
                               /* Clear structure */
           my_addr.sun_family = AF_UNIX;
           strncpy(my_addr.sun_path, MY_SOCK_PATH,
                   sizeof(my_addr.sun_path) - 1);

           if (bind(sfd, (struct sockaddr *) &my_addr,
                   sizeof(struct sockaddr_un)) == -1)
               handle_error("bind");
           setsockcreatecon(NULL);
           setfscreatecon(NULL);

Comment 11 Daniel Walsh 2011-08-30 09:52:04 UTC
Kay the label of the binary is not the same as the label of the socket.

Comment 12 Lennart Poettering 2011-08-30 23:08:04 UTC
Dan, I have now put together a call label_bind() that closely mimics bind() but initializes setfscreatecon() first and is now called form the appropriate places instead of bind():

http://cgit.freedesktop.org/systemd/tree/src/label.c#n329

This appears to do what is required. I'd be thankful for a quick review.

Comment 13 Lennart Poettering 2011-08-30 23:49:08 UTC
*** Bug 722449 has been marked as a duplicate of this bug. ***

Comment 14 Daniel Walsh 2011-08-31 14:21:30 UTC
Looks good to me.

Comment 15 Fedora Update System 2011-09-01 00:34:54 UTC
systemd-35-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-35-1.fc16

Comment 16 Fedora Update System 2011-09-01 19:02:56 UTC
Package systemd-35-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-35-1.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/systemd-35-1.fc16
then log in and leave karma (feedback).

Comment 17 Miroslav Grepl 2011-09-05 06:48:37 UTC
*** Bug 735676 has been marked as a duplicate of this bug. ***

Comment 18 Miroslav Grepl 2011-09-05 06:48:56 UTC
*** Bug 735564 has been marked as a duplicate of this bug. ***

Comment 19 Fedora Update System 2011-09-09 17:07:18 UTC
systemd-35-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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