Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)
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)
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)
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)
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)
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)
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)
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)
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
