[PATCH 0/3] Introduce LSM-hook for socketpair(2)
Serge E. Hallyn
serge at hallyn.com
Mon Apr 23 17:52:33 UTC 2018
Quoting David Herrmann (dh.herrmann at gmail.com):
> 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 .
> 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  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.
>  https://github.com/bus1/dbus-broker/blob/master/src/util/test-peersec.c
>  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 <serge at hallyn.com>
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive