From: Christian Franke <Christian.Franke@t-online.de>
To: cygwin-developers@cygwin.com
Subject: Cygwin AF_UNIX emulation
Date: Thu, 16 Oct 2014 21:34:00 -0000 [thread overview]
Message-ID: <544039E2.2040908@t-online.de> (raw)
Hi Corinna,
Corinna Vinschen wrote:
> On Oct 13 07:37, Christian Franke wrote:
>>> I
>>> also added a comment to explain why we do this and a FIXME comment so we
>>> don't forget we're still looking for a more generic solution for the
>>> SO_PEERCRED exchange.
>> Definitely, at least because the current AF_LOCAL emulation has some
>> security issues.
> -v?
With the secret+cred exchange, the current implementation is IMO
reasonably safe. The client cannot connect without access to the socket
file.
Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw-
and relies only on directory permissions (private: rwx------, public:
rwx--x---) for access control. This is not effective on Cygwin. Due to
the rw-rw-rw-, the 'secret' is world readable on Cygwin and another
Cygwin specific patch is required :-)
After new setsockopt(sd, ., SO_PEERCRED, .), AF_UNIX sockets are
definitely vulnerable. Any local process could "guess" the TCP port and
connect to any emulated AF_UNIX server regardless of user account.
Two draft ideas for a new AF_UNIX emulation:
1)
Keep the current secret+cred exchange, but handle accept() and connect()
differently:
After actual accept():
if (! recv client secret+cred)
return abort_connection();
send(server secret+cred);
set_state(connected).
After actual connect():
send(client secret+cred);
set_state(connected_but_secret_missing)
Before actual recv() and getpeerid():
if (state == connected_but_secret_missing) {
if (! recv server secret+cred)
return abort_connection()
set_state(connected)
}
Before actual send(): Do nothing special.
Secrets should be different such that knowledge of client secret (send
unconditionally) does not expose the server secret.
In contrast to my first more 'symmetric' approach, this should support
'client send() before server accept()'. Could not test it with postfix yet.
Unfortunately this leaves one security issue open: Client may send
confidential data to malicious server if original server died. The
client will recognize it too late in first receive.
2)
Don't exchange anything over TCP. Rely on a connection table in the
socket file. Use 'bind before connect()' to avoid races.
local_bind:
bind(localhost:0);
getsockname(&server_port);
create_socket_file(path);
lock_socket_file(path) {
socket_file.slot[0] = (server_port, my_creds);
}
local_connect:
bind(localhost:0)
getsockname(&client_port);
lock_socket_file(path) {
server_port = socket_file.slot[0].port;
peer_creds = socket_file.slot[0].credentials;
i = find_free_slot();
socket_file.slot[i] = (client_port, my_creds, timestamp);
}
return connect(localhost:serverport);
local_accept:
accept(&client_port);
lock_socket_file(path) {
i = find_slot(client_port));
peer_creds = socket_file.slot[i].credentials;
}
Problem: There is no real proof that the TCP peer is the actual peer
listed in the file.
Christian
next reply other threads:[~2014-10-16 21:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 21:34 Christian Franke [this message]
2014-10-17 11:49 ` Corinna Vinschen
2014-10-17 19:29 ` Christian Franke
2014-10-18 10:35 ` Corinna Vinschen
2014-10-18 15:05 ` Christian Franke
2014-10-20 10:44 ` Corinna Vinschen
2014-10-20 10:44 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544039E2.2040908@t-online.de \
--to=christian.franke@t-online.de \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).