memcache session with UNIX socket

[Space One]

Hello,
I don't get it how to configure the memcached session to use a UNIX socket:
https://simplesamlphp.org/docs/1.13/simplesamlphp-maintenance#section_2_1

I tried to specify the unix socket path as hostname:
'memcache_store.servers' => array(
array(
array(
'hostname' =>
'/var/run/simplesamlphp.socket',
),
),

),

This fails with:
SimpleSAML_Error_Exception: Error 8 - MemcachePool::set(): Server
/var/run/simplesamlphp.socket (tcp 11211, udp 0) failed with:
php_network_getaddresses: getaddrinfo failed: Name or service not known (0)

P.S.: using memcached seems to be a security nightmare. The
documentation IMHO should mention that TCP sockets must be protected
otherwise anyone can steal sessions.

I hope you can direct me on how to set up the connection to use UNIX
sockets properly.

Greetings
spaceone

[Jaime Perez Crespo]

Hi,

> On 23 Sep 2015, at 18:29 pm, Space One <sp...@wechall.net> wrote:
> Hello,
> I don't get it how to configure the memcached session to use a UNIX socket:
> https://simplesamlphp.org/docs/1.13/simplesamlphp-maintenance#section_2_1
>
> I tried to specify the unix socket path as hostname:
> 'memcache_store.servers' => array(
> array(
> array(
> 'hostname' =>
> '/var/run/simplesamlphp.socket',
> ),
> ),
>
> ),
>
> This fails with:
> SimpleSAML_Error_Exception: Error 8 - MemcachePool::set(): Server
> /var/run/simplesamlphp.socket (tcp 11211, udp 0) failed with:
> php_network_getaddresses: getaddrinfo failed: Name or service not known (0)

I think the name of the option itself ("hostname”) as well as the documentation (“Host name or ip address of a memcache server”) is quite explicit. A local path in the filesystem is definitely not a host name.

In any case, if you take a look at the PHP documentation (see the host parameter), you’ll see the correct way to specify a UNIX socket:

http://php.net/manual/en/memcache.addserver.php

In your case:

unix:///var/run/simplesamlphp.socket

However, the use of sockets imply that you need to set the port number to 0, which is explicitly forbidden by SimpleSAMLphp (because it doesn’t support sockets). This can be fixed very easily, of course, but in any case it means you cannot use sockets right now.

> P.S.: using memcached seems to be a security nightmare. The
> documentation IMHO should mention that TCP sockets must be protected
> otherwise anyone can steal sessions.

Well, the documentation doesn’t even mention sockets at all. I believe it also doesn’t say anything about properly protecting PHP session files, even though that’s the most common mechanism. In the end, the documentation tells you how to configure SimpleSAMLphp, not how to secure your system.

> I hope you can direct me on how to set up the connection to use UNIX
> sockets properly.
>
> Greetings
> spaceone

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Jaime Perez Crespo]

There you go ;-)

https://simplesamlphp.org/docs/development/simplesamlphp-maintenance#section_2_1

[Space One]

Hi Jaime,

thank you very much for
https://github.com/simplesamlphp/simplesamlphp/commit/42b00572f250ed3c71ee1d1821969fab558b2b25

I hope you know that sockets != unix sockets! A connection with a
hostname and port needs also a socket, but a TCP or UDP one.
And using UNIX sockets is way more secure than using TCP sockets in that
context. UNIX sockets can be protected via file permissions while TCP
sockets need a firewall.

Greetings
spaceone

[Jaime Perez Crespo]

Hi,

> On 24 Sep 2015, at 12:43 pm, Space One <sp...@wechall.net> wrote:
> Hi Jaime,
>
> thank you very much for
> https://github.com/simplesamlphp/simplesamlphp/commit/42b00572f250ed3c71ee1d1821969fab558b2b25

No prob! :-)

> I hope you know that sockets != unix sockets!

Of course, though I get that as a comment on a (probably) badly chosen variable name and comments. I take full responsibility for that ;-)

> A connection with a
> hostname and port needs also a socket, but a TCP or UDP one.

Strictly speaking, since UDP is not connection oriented, if you want to establish a connection you need a TCP socket, while you can use UDP if you just want to send or receive datagrams.

> And using UNIX sockets is way more secure than using TCP sockets in that
> context. UNIX sockets can be protected via file permissions while TCP
> sockets need a firewall.

I wouldn’t say UNIX sockets are more inherently secure than TCP/IP sockets, at least not in this context. Firewalls and network filtering can be seen as the equivalent of assigning permissions to a file in a UNIX filesystem. In every networked environment you need to have such filtering in place. If you configure the system appropriately, nobody except sysadmins should have access to the server, so that makes it irrelevant whether sessions are stored locally or in a remote memcache server. And on the other hand, if you want to have a failover mechanism or high availability, you’ll need to have several front-end servers, which necessarily need to share the session storage in order to work. That means UNIX domain sockets are fine if you have a very small installation with very constrained resources, but as soon as your service becomes bigger, then they just aren’t enough.

So the point of a memcache server is actually to be able to share the storage. If you are fine with storing sessions locally, maybe you shouldn’t be using memcache at all (which I understand was the reason to not support UNIX domain sockets there, but anyway).

[Space One]

Hi,
the reason I use UNIX sockets is that I can wrap them arround a verified
SSL tunnel (using stunnel)!
All the IDP and memcached servers are reachable via the Internet (and
some allow ssh access for local users) so I need a protection against
MITM, unallowed/unverified TCP connections, and against security wholes
in apache or other wsgi/cgi/php scripts which run at this server!
So, no memcached server should be available via TCP. If I would bind
them to a TCP socket at 127.0.0.1 it is still possible that local users
or scripts (vulnerabilities in PHP scripts) are able to connect to that
socket.

Using a UNIX socket is therefore more secure as this could only be
exploited by gaining access to the posix user under which simplesamlphp
runs or if there is actually a vulnerability in simplesamlphp.

Best regards
spaceone

[Jaime Perez Crespo]

Hi,

> On 24 Sep 2015, at 13:23 pm, Space One <sp...@wechall.net> wrote:
> Hi,
> the reason I use UNIX sockets is that I can wrap them arround a verified
> SSL tunnel (using stunnel)!
> All the IDP and memcached servers are reachable via the Internet (and
> some allow ssh access for local users) so I need a protection against
> MITM, unallowed/unverified TCP connections, and against security wholes
> in apache or other wsgi/cgi/php scripts which run at this server!
> So, no memcached server should be available via TCP. If I would bind
> them to a TCP socket at 127.0.0.1 it is still possible that local users
> or scripts (vulnerabilities in PHP scripts) are able to connect to that
> socket.

That’s a pretty uncommon scenario (neat, but uncommon). Most deployments will have the memcache servers deployed in an internal network, not reachable from the outside, with appropriate network filters. Almost the same would apply to the IdP, except for web TCP ports, and definitely no user (except admins) would have access to any of the servers.

> Using a UNIX socket is therefore more secure as this could only be
> exploited by gaining access to the posix user under which simplesamlphp
> runs or if there is actually a vulnerability in simplesamlphp.

In your specific setup, definitely. But coming back to the discussion about documenting security considerations, I don’t think we should document for every single mechanism supported in SimpleSAMLphp, not to talk about specific setups like yours.

On the other hand, it would be really nice to have a general guide to secure a SimpleSAMLphp installation with the most common considerations for everybody. In the end, we cannot cover every single case, and for advanced scenarios like yours, the users are likely to know how to make everything secure, so not a big need for documentation there.

As always, contributions are more than welcome! ;-)

PD.: this is just curiosity: how’s that you need to allow users to login via SSH to your servers?

[Space One]

Am 24.09.2015 um 13:55 schrieb Jaime Perez Crespo:
> PD.: this is just curiosity: how’s that you need to allow users to login via SSH to your servers?

I will answer this to you on monday but only in private ;-)