Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-05-04 Thread David Herrmann
Hey

On Wed, Apr 25, 2018 at 9:02 PM, James Morris  wrote:
> On Wed, 25 Apr 2018, Paul Moore wrote:
>
>> On Wed, Apr 25, 2018 at 2:44 PM, James Morris  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


Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-25 Thread James Morris
On Wed, 25 Apr 2018, Paul Moore wrote:

> On Wed, Apr 25, 2018 at 2:44 PM, James Morris  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




Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-25 Thread Paul Moore
On Wed, Apr 25, 2018 at 2:44 PM, James Morris  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
www.paul-moore.com


Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-25 Thread David Miller
From: James Morris 
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.


Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-25 Thread James Morris
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




Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-23 Thread Serge E. Hallyn
Quoting David Herrmann (dh.herrm...@gmail.com):
> 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 



Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-23 Thread Casey Schaufler
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(+)
>



[PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-23 Thread David Herrmann
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