lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Mon, 7 Nov 2016 21:18:02 -0500
From:   Nathaniel McCallum <npmccallum@...hat.com>
To:     linux-kernel@...r.kernel.org
Subject: Authenticating Unix Socket Connections by PGID

I apologize if this is the wrong mailing list for this query. I wasn't
sure where else to post it.

In user space, I have a process hierarchy. There is a root process
which spawns a child which in turn may spawn more children. Hence, I
have a standard hierarchy with a root process, zero or more branch
processes and one or more leaf processes. I need a mechanism by which
the leaf processes communicate with the root process. However, I also
need to prevent parallel hierarchies from communicating with the root
process: only descendants of the root process should have access to
the root process. Further, I'd like to avoid the complication of
proxying through branch processes.

I'm already using a process group so that the root process can
killpg() for cleanup. So I was wondering: can I use the PGID for
authentication as well? Basically, I'd just use a well-known
AF_UNIX/SOCK_STREAM socket. The root process would then check that new
connections were in the process group by using:
getpgid(getsockopt(SO_PEERCRED).pid) == getpid().

I inquired with several very knowledgeable people before sending this
email, and they were all somewhat uncomfortable with this scheme but
couldn't detail why. This system depends on a few features.

First, it depends on the documented requirement that setpgid() fails
if attempting to move to a different session. Since I create my own
session (via setsid()) in the root process, it would seem that
spoofing a child is impossible. This requirement is documented in the
man page for setpgid() as failing with EPERM. I also confirmed this
behavior by reviewing the kernel code for implementing the setpgid()
syscall.

Second, it depends on being able to properly determine the PGID of the
unix socket connection peer. One concern that was voiced to me was a
fear that this wouldn't work across namespaces; so I tested it. In
child namespaces, getsockopt(SO_PEERCRED).pid returns the mapped PID
in the parent. In parallel namespaces, the same approach returns PID =
0. Thus, AFAICS, this requirement is also met: we can accurately
detect the PGID of a unix socket peer.

Obviously, branch/leaf processes need to be sure not to call
setpgid()/setsid(). But the worst case here is that they get
authentication denied.

Am shooting myself in the foot? Might there be some corner case that
I'm missing?

Powered by blists - more mailing lists