Systemd is not creating sock_files with the correct labels.

Uhmm, then the SELinux policy is borked. We create all sockets with the logic and take the service binary into account.

Does pcscd actually employ systemd-style socket activation? If not then systemd is not involved at all.

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

(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()?

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)

(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)

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?

(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?

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);

Kay the label of the binary is not the same as the label of the socket.

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.

*** Bug 722449 has been marked as a duplicate of this bug. ***

Looks good to me.

systemd-35-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-35-1.fc16

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).

*** Bug 735676 has been marked as a duplicate of this bug. ***

*** Bug 735564 has been marked as a duplicate of this bug. ***

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.