Thread: Re: improving security of AF_UNIX sockets

Hi!

Friday, 13 April, 2001 Jason Tishler Jason.Tishler@dothill.com wrote:

JT> On Wed, Apr 04, 2001 at 10:02:50PM +0400, egor duda wrote:
>>   this patch prevents local users from connecting to cygwin-emulated
>> AF_UNIX socket if this user have no read rights on socket's file.
>> it's done by adding 128-bit random secret cookie to !<socket>port
>> string in file. later, each processes which is negotiating connection
>> via connect() or accept() must signal its peer that it knows this
>> secret cookie.
>>
>> sendto() and recvfrom() are still insecure, unfortunately.
>>
>> Comments?

JT> I have tried the above with PostgreSQL and it works as documented.

Actually, before this patch it already worked the same way. At
least for programs that use legitimate socket APIs, nothing should
have been changed. if user tries to open AF_UNIX socket he hasn't
access to, via normal cygwin socket() call, cygwin1.dll returns
EACCESS. It is so for a long time already.

this patch is supposed to prevent malicious local user to connect to
inet socket used for AF_UNIX socket emulation. just run some program
that accept()s on AF_UNIX socket and run 'netstat -a'. You'll see
that new LISTEN'ing port appeared. it's AF_INET socket used for
AF_UNIX socket emulation. Before the patch you could telnet to this
port, perform read and writes even if you don't have access to AF_UNIX
socket file. Sometimes (ssh-agent is a good example), this can
lead to security compromise.

JT> However, see the attached for a comment from one of the PostgreSQL
JT> core developers.

Peter Eisentraut wrote:
PE> Jason Tishler writes:
>> I used 7.1rc4 from Cygwin's contrib and everything seems to work as
>> expected.  The regression tests all passed.  Even the enhanced AF_UNIX
>> security worked as advertised.  If the client (i.e., psql) has read
>> access to the socket file (i.e., /tmp/.s.PGSQL.5432), then it can connect
>> to postmaster.  Otherwise, the client gets a "Permission denied" failure.

PE> Actually, connections to Unix domain sockets are controlled by *write*
PE> access to the socket file.  Maybe Cygwin should change this.

Hmm. Can you point to some references? What operations (socket(), bind(),
connect(), accept()) will fail in case of
1) r-- access
2) -w- access
3) rw- access
to socket file?

JT> Is it possible and/or does it make sense to do as suggested?

Well, i'll try to think it over. References/suggestions as for
implementation of those references/comments are welcome.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

egor duda writes:

> PE> Actually, connections to Unix domain sockets are controlled by *write*
> PE> access to the socket file.  Maybe Cygwin should change this.
>
> Hmm. Can you point to some references? What operations (socket(), bind(),
> connect(), accept()) will fail in case of
> 1) r-- access
> 2) -w- access
> 3) rw- access
> to socket file?

If there's no 'w' then connect() will fail with ECONNREFUSED on Linux 2.2.
(At least this is what PostgreSQL tells me, I didn't bother tracking it
down at the source level.)  Note that the glibc documentation until
recently claimed that read permission was what mattered, but this was
never the case and has been removed after I pointed it out.  (This tells
you how well known this actually is.)  Unfortunately, now it doesn't say
anything about this.

FreeBSD 4.3's connect(2) man page documents EACCESS as the error code if
"Write access to the named socket is denied."

On Solaris 8, connect(3XNET) says

"The connect() function may fail if:

    EACCES    Search permission is denied for a component of the path
              prefix; or write access to the named socket is denied."

On Irix 6.5, unix(7F) has

: Normal filesystem
: access-control mechanisms are also applied when referencing pathnames;
: e.g., the destination of a connect(2) or sendto(2) must be writable.

And last but not least, The Single UNIX ® Specification, Version 2
(a.k.a., Unix98):

"The connect() function may fail if:

      [EACCES]
            Search permission is denied for a component of the path
            prefix; or write access to the named socket is denied."

(Hmm, somebody was copying here.)

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:
> If there's no 'w' then connect() will fail with ECONNREFUSED on Linux 2.2.
> [ and several other systems document EACCES as the error code ]

FWIW: HPUX 10.20 doesn't document this error condition at all on the
connect(2) man page, but some quick experimentation shows that indeed
write access to the socket is necessary and sufficient to make a
connection.  (And EACCES is what you get if you ain't got it.)

            regards, tom lane