tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal to automatically make the owner/user of an accepted socket the current process





On 6 Jun 2025, at 2:07 PM, Vadim Goncharov <vadimnuclight%gmail.com@localhost> wrote:

On Fri, 6 Jun 2025 08:45:43 -0400
Thor Lancelot Simon <tls%panix.com@localhost> wrote:

On Fri, Jun 06, 2025 at 07:33:37AM +0000, Emmanuel Nyarko wrote:

On 5 Jun 2025, at 11:12???PM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:

What will happen when a socket changes hands by file descriptor passing
over a Unix domain socket?  

But the reason is I want to add this support is for NPF to be able to give
a user based security to Unix servers in network layer. Like being able to
allow or deny certain users on a server from giving out resources. so
maybe for now, even if I???m doing it as opt-in, I can still exempt UDS
from it because I don???t think it will add anything to Unix Domain
Sockets  

I don't think you understand.  I can accept a TCP connection on an AF_INET
socket, then take the resulting file descriptor and transfer it to a
completely unrelated process using a control message on an AF_UNIX socket.
That process can be owned by a different user.  What do you intend to happen
to the AF_INET socket that is passed in this way?

Does that matter at all? For the common needed case, e.g. FreeBSD's ipfw(8)
has uid/gid (and then also jail id) support for decades - not without layering
violation problems in code, though. The BUGS section lists:

    Rules using uid or gid may not behave as expected.  In particular,
    incoming SYN packets may have no uid or gid associated with them since
    they do not yet belong to a TCP connection
listening sockets are loaded into the pcb table in NetBSD AFAIK. So can easily locate the socket using a daddr and dport lookup for them sockets.
And that should be easily found. Maybe FreeBSD doesn’t load the bound/listening sockets into the pcbtable.
, and the uid/gid associated
    with a packet may not be as expected if the associated process calls
    setuid(2) or similar system calls.





--
WBR, @nuclight

A scoffer seeks wisdom in vain, but knowledge is easy for a man of understanding.
Emmanuel







Home | Main Index | Thread Index | Old Index