Hi
This series adds a new LSM hook for the socketpair(2) syscall. The idea
is to allow SO_PEERSEC to be called on AF_UNIX sockets created via
socketpair(2), and return the same information as if you emulated
socketpair(2) via a temporary listener socket. Right now SO_PEERSEC
will return the unlabeled credentials for a socketpair, rather than the
actual credentials of the creating process.
A simple call to:
socketpair(AF_UNIX, SOCK_STREAM, 0, out);
can be emulated via a temporary listener socket bound to a unique,
random name in the abstract namespace. By connecting to this listener
socket, accept(2) will return the second part of the pair. If
SO_PEERSEC is queried on these, the correct credentials of the creating
process are returned. A simple comparison between the behavior of
SO_PEERSEC on socketpair(2) and an emulated socketpair is included in
the dbus-broker test-suite [1].
This patch series tries to close this gap and makes both behave the
same. A new LSM-hook is added which allows LSMs to cache the correct
peer information on newly created socket-pairs.
Apart from fixing this behavioral difference, the dbus-broker project
actually needs to query the credentials of socketpairs, and currently
must resort to racy procfs(2) queries to get the LSM credentials of its
controller socket. Several parts of the dbus-broker project allow you
to pass in a socket during execve(2), which will be used by the child
process to accept control-commands from its parent. One natural way to
create this communication channel is to use socketpair(2). However,
right now SO_PEERSEC does not return any useful information, hence, the
child-process would need other means to retrieve this information. By
avoiding socketpair(2) and using the hacky-emulated version, this is not
an issue.
There was a previous discussion on this matter [2] roughly a year ago.
Back then there was the suspicion that proper SO_PEERSEC would confuse
applications. However, we could not find any evidence backing this
suspicion. Furthermore, we now actually see the contrary. Lack of
SO_PEERSEC makes it a hassle to use socketpairs with LSM credentials.
Hence, we propose to implement full SO_PEERSEC for socketpairs.
This series only adds SELinux backends, since that is what we need for
RHEL. I will gladly extend the other LSMs if needed.
Thanks
David
[1] https://github.com/bus1/dbus-broker/blob/master/src/util/test-peersec.c
[2] https://www.spinics.net/lists/selinux/msg22674.html
David Herrmann (3):
security: add hook for socketpair(AF_UNIX, ...)
net/unix: hook unix_socketpair() into LSM
selinux: provide unix_stream_socketpair callback
include/linux/lsm_hooks.h | 8 ++++++++
include/linux/security.h | 7 +++++++
net/unix/af_unix.c | 5 +++++
security/security.c | 6 ++++++
security/selinux/hooks.c | 14 ++++++++++++++
5 files changed, 40 insertions(+)
--
2.17.0
Use the newly created LSM-hook for unix_socketpair(). The default hook
return-value is 0, so behavior stays the same unless LSMs start using
this hook.
Signed-off-by: David Herrmann <[email protected]>
---
net/unix/af_unix.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 68bb70a62afe..bc9705ace9b1 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
static int unix_socketpair(struct socket *socka, struct socket *sockb)
{
struct sock *ska = socka->sk, *skb = sockb->sk;
+ int err;
+
+ err = security_unix_stream_socketpair(ska, skb);
+ if (err)
+ return err;
/* Join our sockets back to back */
sock_hold(ska);
--
2.17.0
Right now the LSM labels for socketpairs are always uninitialized,
since there is no security hook for the socketpair() syscall. This
patch adds the required hooks so LSMs can properly label socketpairs.
This allows SO_PEERSEC to return useful information on those sockets.
Note that the behavior of socketpair() can be emulated by creating a
listener socket, connecting to it, and then discarding the initial
listener socket. With this workaround, SO_PEERSEC would return the
caller's security context. However, with socketpair(), the uninitialized
context is returned unconditionally. This is unexpected and makes
socketpair() less useful in situations where the security context is
crucial to the application.
With the new socketpair-hook this disparity can be solved by making
socketpair() return the expected security context.
Signed-off-by: David Herrmann <[email protected]>
---
include/linux/lsm_hooks.h | 8 ++++++++
include/linux/security.h | 7 +++++++
security/security.c | 6 ++++++
3 files changed, 21 insertions(+)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9d0b286f3dba..2a23c75c1541 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -717,6 +717,12 @@
* @other contains the peer sock structure.
* @newsk contains the new sock structure.
* Return 0 if permission is granted.
+ * @unix_stream_socketpair:
+ * Check permissions before establishing a Unix domain stream connection
+ * for a fresh pair of sockets.
+ * @socka contains the first sock structure.
+ * @sockb contains the second sock structure.
+ * Return 0 if permission is granted and the connection was established.
* @unix_may_send:
* Check permissions before connecting or sending datagrams from @sock to
* @other.
@@ -1651,6 +1657,7 @@ union security_list_options {
#ifdef CONFIG_SECURITY_NETWORK
int (*unix_stream_connect)(struct sock *sock, struct sock *other,
struct sock *newsk);
+ int (*unix_stream_socketpair)(struct sock *socka, struct sock *sockb);
int (*unix_may_send)(struct socket *sock, struct socket *other);
int (*socket_create)(int family, int type, int protocol, int kern);
@@ -1919,6 +1926,7 @@ struct security_hook_heads {
struct hlist_head inode_getsecctx;
#ifdef CONFIG_SECURITY_NETWORK
struct hlist_head unix_stream_connect;
+ struct hlist_head unix_stream_socketpair;
struct hlist_head unix_may_send;
struct hlist_head socket_create;
struct hlist_head socket_post_create;
diff --git a/include/linux/security.h b/include/linux/security.h
index 200920f521a1..be275deeda10 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1187,6 +1187,7 @@ static inline int security_inode_getsecctx(struct inode *inode, void **ctx, u32
#ifdef CONFIG_SECURITY_NETWORK
int security_unix_stream_connect(struct sock *sock, struct sock *other, struct sock *newsk);
+int security_unix_stream_socketpair(struct sock *socka, struct sock *sockb);
int security_unix_may_send(struct socket *sock, struct socket *other);
int security_socket_create(int family, int type, int protocol, int kern);
int security_socket_post_create(struct socket *sock, int family,
@@ -1242,6 +1243,12 @@ static inline int security_unix_stream_connect(struct sock *sock,
return 0;
}
+static inline int security_unix_stream_socketpair(struct sock *socka,
+ struct sock *sockb)
+{
+ return 0;
+}
+
static inline int security_unix_may_send(struct socket *sock,
struct socket *other)
{
diff --git a/security/security.c b/security/security.c
index 7bc2fde023a7..3dfd374e84e5 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1340,6 +1340,12 @@ int security_unix_stream_connect(struct sock *sock, struct sock *other, struct s
}
EXPORT_SYMBOL(security_unix_stream_connect);
+int security_unix_stream_socketpair(struct sock *socka, struct sock *sockb)
+{
+ return call_int_hook(unix_stream_socketpair, 0, socka, sockb);
+}
+EXPORT_SYMBOL(security_unix_stream_socketpair);
+
int security_unix_may_send(struct socket *sock, struct socket *other)
{
return call_int_hook(unix_may_send, 0, sock, other);
--
2.17.0
Make sure to implement the new unix_stream_socketpair callback so the
SO_PEERSEC call on socketpair(2)s will return correct information.
Signed-off-by: David Herrmann <[email protected]>
---
security/selinux/hooks.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4cafe6a19167..828881d9a41d 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4905,6 +4905,18 @@ static int selinux_socket_unix_stream_connect(struct sock *sock,
return 0;
}
+static int selinux_socket_unix_stream_socketpair(struct sock *socka,
+ struct sock *sockb)
+{
+ struct sk_security_struct *sksec_a = socka->sk_security;
+ struct sk_security_struct *sksec_b = sockb->sk_security;
+
+ sksec_a->peer_sid = sksec_b->sid;
+ sksec_b->peer_sid = sksec_a->sid;
+
+ return 0;
+}
+
static int selinux_socket_unix_may_send(struct socket *sock,
struct socket *other)
{
@@ -6995,6 +7007,8 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx),
LSM_HOOK_INIT(unix_stream_connect, selinux_socket_unix_stream_connect),
+ LSM_HOOK_INIT(unix_stream_socketpair,
+ selinux_socket_unix_stream_socketpair),
LSM_HOOK_INIT(unix_may_send, selinux_socket_unix_may_send),
LSM_HOOK_INIT(socket_create, selinux_socket_create),
--
2.17.0
On 04/23/2018 09:30 AM, David Herrmann wrote:
> Make sure to implement the new unix_stream_socketpair callback so the
> SO_PEERSEC call on socketpair(2)s will return correct information.
>
> Signed-off-by: David Herrmann <[email protected]>
Acked-by: Stephen Smalley <[email protected]>
> ---
> security/selinux/hooks.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4cafe6a19167..828881d9a41d 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4905,6 +4905,18 @@ static int selinux_socket_unix_stream_connect(struct sock *sock,
> return 0;
> }
>
> +static int selinux_socket_unix_stream_socketpair(struct sock *socka,
> + struct sock *sockb)
> +{
> + struct sk_security_struct *sksec_a = socka->sk_security;
> + struct sk_security_struct *sksec_b = sockb->sk_security;
> +
> + sksec_a->peer_sid = sksec_b->sid;
> + sksec_b->peer_sid = sksec_a->sid;
> +
> + return 0;
> +}
> +
> static int selinux_socket_unix_may_send(struct socket *sock,
> struct socket *other)
> {
> @@ -6995,6 +7007,8 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
> LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx),
>
> LSM_HOOK_INIT(unix_stream_connect, selinux_socket_unix_stream_connect),
> + LSM_HOOK_INIT(unix_stream_socketpair,
> + selinux_socket_unix_stream_socketpair),
> LSM_HOOK_INIT(unix_may_send, selinux_socket_unix_may_send),
>
> LSM_HOOK_INIT(socket_create, selinux_socket_create),
>
On 4/23/2018 6:30 AM, David Herrmann wrote:
> Hi
>
> This series adds a new LSM hook for the socketpair(2) syscall. The idea
> is to allow SO_PEERSEC to be called on AF_UNIX sockets created via
> socketpair(2), and return the same information as if you emulated
> socketpair(2) via a temporary listener socket. Right now SO_PEERSEC
> will return the unlabeled credentials for a socketpair, rather than the
> actual credentials of the creating process.
>
> ...
>
> This series only adds SELinux backends, since that is what we need for
> RHEL. I will gladly extend the other LSMs if needed.
I would be very happy to see a proposed patch for Smack. It shouldn't
be much different from the SELinux version, with the exception that it
will use pointers to smk_known structures instead of secids. It would be
a big help, as someone just threw a whole new species of scorpion into
this pit.
>
> Thanks
> David
>
> [1] https://github.com/bus1/dbus-broker/blob/master/src/util/test-peersec.c
> [2] https://www.spinics.net/lists/selinux/msg22674.html
>
> David Herrmann (3):
> security: add hook for socketpair(AF_UNIX, ...)
> net/unix: hook unix_socketpair() into LSM
> selinux: provide unix_stream_socketpair callback
>
> include/linux/lsm_hooks.h | 8 ++++++++
> include/linux/security.h | 7 +++++++
> net/unix/af_unix.c | 5 +++++
> security/security.c | 6 ++++++
> security/selinux/hooks.c | 14 ++++++++++++++
> 5 files changed, 40 insertions(+)
>
Quoting David Herrmann ([email protected]):
> Hi
>
> This series adds a new LSM hook for the socketpair(2) syscall. The idea
> is to allow SO_PEERSEC to be called on AF_UNIX sockets created via
> socketpair(2), and return the same information as if you emulated
> socketpair(2) via a temporary listener socket. Right now SO_PEERSEC
> will return the unlabeled credentials for a socketpair, rather than the
> actual credentials of the creating process.
>
> A simple call to:
>
> socketpair(AF_UNIX, SOCK_STREAM, 0, out);
>
> can be emulated via a temporary listener socket bound to a unique,
> random name in the abstract namespace. By connecting to this listener
> socket, accept(2) will return the second part of the pair. If
> SO_PEERSEC is queried on these, the correct credentials of the creating
> process are returned. A simple comparison between the behavior of
> SO_PEERSEC on socketpair(2) and an emulated socketpair is included in
> the dbus-broker test-suite [1].
>
> This patch series tries to close this gap and makes both behave the
> same. A new LSM-hook is added which allows LSMs to cache the correct
> peer information on newly created socket-pairs.
>
> Apart from fixing this behavioral difference, the dbus-broker project
> actually needs to query the credentials of socketpairs, and currently
> must resort to racy procfs(2) queries to get the LSM credentials of its
> controller socket. Several parts of the dbus-broker project allow you
> to pass in a socket during execve(2), which will be used by the child
> process to accept control-commands from its parent. One natural way to
> create this communication channel is to use socketpair(2). However,
> right now SO_PEERSEC does not return any useful information, hence, the
> child-process would need other means to retrieve this information. By
> avoiding socketpair(2) and using the hacky-emulated version, this is not
> an issue.
>
> There was a previous discussion on this matter [2] roughly a year ago.
> Back then there was the suspicion that proper SO_PEERSEC would confuse
> applications. However, we could not find any evidence backing this
> suspicion. Furthermore, we now actually see the contrary. Lack of
> SO_PEERSEC makes it a hassle to use socketpairs with LSM credentials.
> Hence, we propose to implement full SO_PEERSEC for socketpairs.
>
> This series only adds SELinux backends, since that is what we need for
> RHEL. I will gladly extend the other LSMs if needed.
>
> Thanks
> David
>
> [1] https://github.com/bus1/dbus-broker/blob/master/src/util/test-peersec.c
> [2] https://www.spinics.net/lists/selinux/msg22674.html
>
> David Herrmann (3):
> security: add hook for socketpair(AF_UNIX, ...)
> net/unix: hook unix_socketpair() into LSM
> selinux: provide unix_stream_socketpair callback
>
> include/linux/lsm_hooks.h | 8 ++++++++
> include/linux/security.h | 7 +++++++
> net/unix/af_unix.c | 5 +++++
> security/security.c | 6 ++++++
> security/selinux/hooks.c | 14 ++++++++++++++
> 5 files changed, 40 insertions(+)
Makes sense to me, thanks.
Acked-by: Serge Hallyn <[email protected]>
On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann <[email protected]> wrote:
> Use the newly created LSM-hook for unix_socketpair(). The default hook
> return-value is 0, so behavior stays the same unless LSMs start using
> this hook.
>
> Signed-off-by: David Herrmann <[email protected]>
> ---
> net/unix/af_unix.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 68bb70a62afe..bc9705ace9b1 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
> static int unix_socketpair(struct socket *socka, struct socket *sockb)
> {
> struct sock *ska = socka->sk, *skb = sockb->sk;
> + int err;
> +
> + err = security_unix_stream_socketpair(ska, skb);
> + if (err)
> + return err;
I recognize that AF_UNIX is really the only protocol that supports
socketpair(2) at the moment, but I like to avoid protocol specific LSM
hooks whenever possible. Unless someone can think of a good
objection, I would prefer to see the hook placed in __sys_socketpair()
instead (and obviously drop the "unix_stream" portion from the hook
name).
> /* Join our sockets back to back */
> sock_hold(ska);
> --
> 2.17.0
--
paul moore
http://www.paul-moore.com
From: Paul Moore <[email protected]>
Date: Tue, 24 Apr 2018 13:55:31 -0400
> On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann <[email protected]> wrote:
>> Use the newly created LSM-hook for unix_socketpair(). The default hook
>> return-value is 0, so behavior stays the same unless LSMs start using
>> this hook.
>>
>> Signed-off-by: David Herrmann <[email protected]>
>> ---
>> net/unix/af_unix.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 68bb70a62afe..bc9705ace9b1 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
>> static int unix_socketpair(struct socket *socka, struct socket *sockb)
>> {
>> struct sock *ska = socka->sk, *skb = sockb->sk;
>> + int err;
>> +
>> + err = security_unix_stream_socketpair(ska, skb);
>> + if (err)
>> + return err;
>
> I recognize that AF_UNIX is really the only protocol that supports
> socketpair(2) at the moment, but I like to avoid protocol specific LSM
> hooks whenever possible. Unless someone can think of a good
> objection, I would prefer to see the hook placed in __sys_socketpair()
> instead (and obviously drop the "unix_stream" portion from the hook
> name).
The counterargument is that after 30 years no other protocol has grown
usage of this operation. :-)
On Tue, Apr 24, 2018 at 1:56 PM, David Miller <[email protected]> wrote:
> From: Paul Moore <[email protected]>
> Date: Tue, 24 Apr 2018 13:55:31 -0400
>
>> On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann <[email protected]> wrote:
>>> Use the newly created LSM-hook for unix_socketpair(). The default hook
>>> return-value is 0, so behavior stays the same unless LSMs start using
>>> this hook.
>>>
>>> Signed-off-by: David Herrmann <[email protected]>
>>> ---
>>> net/unix/af_unix.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>>> index 68bb70a62afe..bc9705ace9b1 100644
>>> --- a/net/unix/af_unix.c
>>> +++ b/net/unix/af_unix.c
>>> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr,
>>> static int unix_socketpair(struct socket *socka, struct socket *sockb)
>>> {
>>> struct sock *ska = socka->sk, *skb = sockb->sk;
>>> + int err;
>>> +
>>> + err = security_unix_stream_socketpair(ska, skb);
>>> + if (err)
>>> + return err;
>>
>> I recognize that AF_UNIX is really the only protocol that supports
>> socketpair(2) at the moment, but I like to avoid protocol specific LSM
>> hooks whenever possible. Unless someone can think of a good
>> objection, I would prefer to see the hook placed in __sys_socketpair()
>> instead (and obviously drop the "unix_stream" portion from the hook
>> name).
>
> The counterargument is that after 30 years no other protocol has grown
> usage of this operation. :-)
Call me a an optimist ;)
--
paul moore
http://www.paul-moore.com
On Mon, 23 Apr 2018, David Herrmann wrote:
> This patch series tries to close this gap and makes both behave the
> same. A new LSM-hook is added which allows LSMs to cache the correct
> peer information on newly created socket-pairs.
Looks okay to me.
Once it's respun with the Smack backend and maybe the hook name change,
I'll merge this unless DaveM wants it to go in via his networking tree.
--
James Morris
<[email protected]>
From: James Morris <[email protected]>
Date: Thu, 26 Apr 2018 04:44:38 +1000 (AEST)
> On Mon, 23 Apr 2018, David Herrmann wrote:
>
>> This patch series tries to close this gap and makes both behave the
>> same. A new LSM-hook is added which allows LSMs to cache the correct
>> peer information on newly created socket-pairs.
>
> Looks okay to me.
>
> Once it's respun with the Smack backend and maybe the hook name change,
> I'll merge this unless DaveM wants it to go in via his networking tree.
No, feel free to take it via your tree James.
On Wed, Apr 25, 2018 at 2:44 PM, James Morris <[email protected]> wrote:
> On Mon, 23 Apr 2018, David Herrmann wrote:
>> This patch series tries to close this gap and makes both behave the
>> same. A new LSM-hook is added which allows LSMs to cache the correct
>> peer information on newly created socket-pairs.
>
> Looks okay to me.
>
> Once it's respun with the Smack backend and maybe the hook name change,
> I'll merge this unless DaveM wants it to go in via his networking tree.
Note my objection to the hook placement in patch 2/3; I think we
should move the hook out of the AF_UNIX layer and up into the socket
layer.
--
paul moore
http://www.paul-moore.com
On Wed, 25 Apr 2018, Paul Moore wrote:
> On Wed, Apr 25, 2018 at 2:44 PM, James Morris <[email protected]> wrote:
> > On Mon, 23 Apr 2018, David Herrmann wrote:
> >> This patch series tries to close this gap and makes both behave the
> >> same. A new LSM-hook is added which allows LSMs to cache the correct
> >> peer information on newly created socket-pairs.
> >
> > Looks okay to me.
> >
> > Once it's respun with the Smack backend and maybe the hook name change,
> > I'll merge this unless DaveM wants it to go in via his networking tree.
>
> Note my objection to the hook placement in patch 2/3; I think we
> should move the hook out of the AF_UNIX layer and up into the socket
> layer.
I vote for this as it maintains the intended abstraction of the socket
API.
--
James Morris
<[email protected]>
Hey
On Wed, Apr 25, 2018 at 9:02 PM, James Morris <[email protected]> wrote:
> On Wed, 25 Apr 2018, Paul Moore wrote:
>
>> On Wed, Apr 25, 2018 at 2:44 PM, James Morris <[email protected]> wrote:
>> > On Mon, 23 Apr 2018, David Herrmann wrote:
>> >> This patch series tries to close this gap and makes both behave the
>> >> same. A new LSM-hook is added which allows LSMs to cache the correct
>> >> peer information on newly created socket-pairs.
>> >
>> > Looks okay to me.
>> >
>> > Once it's respun with the Smack backend and maybe the hook name change,
>> > I'll merge this unless DaveM wants it to go in via his networking tree.
>>
>> Note my objection to the hook placement in patch 2/3; I think we
>> should move the hook out of the AF_UNIX layer and up into the socket
>> layer.
>
> I vote for this as it maintains the intended abstraction of the socket
> API.
Sounds good, I changed it. I will send v2 shortly.
Thanks
David