All of lore.kernel.org
 help / color / mirror / Atom feed
* SO_PEERSEC on socket connected to the same process
@ 2017-06-13  7:37 Laurent Bigonville
  2017-06-13 14:43 ` Stephen Smalley
  0 siblings, 1 reply; 3+ messages in thread
From: Laurent Bigonville @ 2017-06-13  7:37 UTC (permalink / raw)
  To: selinux

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

Hi,

Currently the dbus-daemon is not returning anything when asked about its 
own security context (using GetConnectionSELinuxSecurityContext or 
GetConnectionCredentials methods). This cause some issues[0] with 
systemd now that it's enforcing the policy for user sessions again.

I already made a patch that has been merged[1][2] upstream in the 
GetConnectionSELinuxSecurityContext case and it now returns the SELinux 
context of the dbus-daemon process itself.

For the GetConnectionCredentials case, upstream wanted a generic way of 
getting the security label and went the way of using SO_PEERSEC on a 
socket connected to itself.

But for some reasons it's always returning unlabeled_t. Note that the 
same value is returned by the getpeercon() function as well.

I've made a small test case (see attached file) and tested it on both 
debian and RHEL7.

Is this somehow expected? Is this a bug?

Cheers,

Laurent Bigonville

[0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864221
[1]https://bugs.freedesktop.org/show_bug.cgi?id=101315
[2] https://phabricator.freedesktop.org/rDBUSdcf02f80656d

[-- Attachment #2: so_peersec.c --]
[-- Type: text/x-csrc, Size: 1003 bytes --]

#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdio.h>
#include <selinux/selinux.h>

int main(void) {

	int socks[2];
	char buf[1024] = "";
	int len = sizeof(buf);
	char *context = NULL;

	if (getcon_raw(&context) < 0)
		perror("getcon_raw");
	printf("getcon: %s\n", context);
	freecon(context);

	if (socketpair (AF_UNIX, SOCK_STREAM, 0, socks) < 0)
		perror("socketpair");

	if (getsockopt (socks[0], SOL_SOCKET, SO_PEERSEC, &buf, &len) < 0)
		perror("getsockopt 1");
	printf("socket 1: %s\n", buf);

	len = sizeof(buf);

	if (getsockopt (socks[1], SOL_SOCKET, SO_PEERSEC, &buf, &len) < 0)
		perror("getsockopt 2");
	printf("socket 2: %s\n", buf);

	if (getpeercon_raw(socks[0], &context) < 0)
		perror("getpeercon_raw 1");
	printf("getpeercon 1: %s\n", context);
	freecon(context);

	if (getpeercon_raw(socks[1], &context) < 0)
		perror("getpeercon_raw 2");
	printf("getpeercon 2: %s\n", context);
	freecon(context);

	close(socks[0]);
	close(socks[1]);


	return 0;
}

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SO_PEERSEC on socket connected to the same process
  2017-06-13  7:37 SO_PEERSEC on socket connected to the same process Laurent Bigonville
@ 2017-06-13 14:43 ` Stephen Smalley
  2017-06-13 20:17   ` Paul Moore
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Smalley @ 2017-06-13 14:43 UTC (permalink / raw)
  To: Laurent Bigonville, selinux

On Tue, 2017-06-13 at 09:37 +0200, Laurent Bigonville wrote:
> Hi,
> 
> Currently the dbus-daemon is not returning anything when asked about
> its 
> own security context (using GetConnectionSELinuxSecurityContext or 
> GetConnectionCredentials methods). This cause some issues[0] with 
> systemd now that it's enforcing the policy for user sessions again.
> 
> I already made a patch that has been merged[1][2] upstream in the 
> GetConnectionSELinuxSecurityContext case and it now returns the
> SELinux 
> context of the dbus-daemon process itself.
> 
> For the GetConnectionCredentials case, upstream wanted a generic way
> of 
> getting the security label and went the way of using SO_PEERSEC on a 
> socket connected to itself.
> 
> But for some reasons it's always returning unlabeled_t. Note that
> the 
> same value is returned by the getpeercon() function as well.
> 
> I've made a small test case (see attached file) and tested it on
> both 
> debian and RHEL7.
> 
> Is this somehow expected? Is this a bug?
> 
> Cheers,
> 
> Laurent Bigonville
> 
> [0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864221
> [1]https://bugs.freedesktop.org/show_bug.cgi?id=101315
> [2] https://phabricator.freedesktop.org/rDBUSdcf02f80656d

SO_PEERSEC has never been supported for socketpair()-created sockets. 
To do so would require a new LSM hook called by unix_socketpair() to
set the peer SIDs for the two sockets.  In the absence of such a hook,
the peer SIDs are left with their initial values (the unlabeled SID),
and thus SO_PEERSEC returns the unlabeled context for both.  That's why
you see the current behavior.

It would be easy enough to implement such a hook (and perhaps we
should), but the more fundamental question is whether SO_PEERSEC makes
sense for socketpair()-created sockets and what does it actually mean.
Suppose we implement the hook and set the peer SIDs during
socketpair(). Pop quiz: Process P1 in context C1 calls socketpair(),
creating sockets S1 and S2 connected to each other.  P1 also creates a
socket S3 via socket() and connects to a socket S4 created via socket()
by process P2 in context C2.  P1 passes S2 over the connection to P2. 
P1 and P2 talk via S1 (P1's endpoint) and S2 (P2's endpoint). What is
the result of:

1. getsockopt(S1, SO_PEERSEC)? Answer: C1 (not C2!)

2. getsockopt(S2, SO_PEERSEC)? Answer: C1

3. getsockopt(S3, SO_PEERSEC)? Answer: C2

4. getsockopt(S4, SO_PEERSEC)? Answer: C1

NB SO_PEERSEC returns the context of the peer socket, i.e. the context
of the socket to which it is connected, not necessarily the context of
the peer process.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SO_PEERSEC on socket connected to the same process
  2017-06-13 14:43 ` Stephen Smalley
@ 2017-06-13 20:17   ` Paul Moore
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Moore @ 2017-06-13 20:17 UTC (permalink / raw)
  To: Stephen Smalley, Laurent Bigonville; +Cc: selinux

On Tue, Jun 13, 2017 at 10:43 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2017-06-13 at 09:37 +0200, Laurent Bigonville wrote:
>> Hi,
>>
>> Currently the dbus-daemon is not returning anything when asked about
>> its
>> own security context (using GetConnectionSELinuxSecurityContext or
>> GetConnectionCredentials methods). This cause some issues[0] with
>> systemd now that it's enforcing the policy for user sessions again.
>>
>> I already made a patch that has been merged[1][2] upstream in the
>> GetConnectionSELinuxSecurityContext case and it now returns the
>> SELinux
>> context of the dbus-daemon process itself.
>>
>> For the GetConnectionCredentials case, upstream wanted a generic way
>> of
>> getting the security label and went the way of using SO_PEERSEC on a
>> socket connected to itself.
>>
>> But for some reasons it's always returning unlabeled_t. Note that
>> the
>> same value is returned by the getpeercon() function as well.
>>
>> I've made a small test case (see attached file) and tested it on
>> both
>> debian and RHEL7.
>>
>> Is this somehow expected? Is this a bug?
>>
>> Cheers,
>>
>> Laurent Bigonville
>>
>> [0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864221
>> [1]https://bugs.freedesktop.org/show_bug.cgi?id=101315
>> [2] https://phabricator.freedesktop.org/rDBUSdcf02f80656d
>
> SO_PEERSEC has never been supported for socketpair()-created sockets.
> To do so would require a new LSM hook called by unix_socketpair() to
> set the peer SIDs for the two sockets.  In the absence of such a hook,
> the peer SIDs are left with their initial values (the unlabeled SID),
> and thus SO_PEERSEC returns the unlabeled context for both.  That's why
> you see the current behavior.
>
> It would be easy enough to implement such a hook (and perhaps we
> should), but the more fundamental question is whether SO_PEERSEC makes
> sense for socketpair()-created sockets and what does it actually mean.

Just to weigh in on this issue, the meaning is exactly as Stephen said
at the end of his email: "SO_PEERSEC returns the context of the peer
socket".  Based on my understanding of how socketpair() is typically
used this would be confusing for the majority of applications,
sticking with the current (unlabeled peer) behavior seems the best
option.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-06-13 20:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-13  7:37 SO_PEERSEC on socket connected to the same process Laurent Bigonville
2017-06-13 14:43 ` Stephen Smalley
2017-06-13 20:17   ` Paul Moore

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.