This is BROKEN!

Posted Dec 18, 2014 14:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: This is BROKEN! by foom
Parent article: Fedora 21 and its Workstation firewall

> Doesn't xmpp usually use port 5222?
Except if you want to use HTTPS tunneling or its Ejabberd's web console.

> Anyways, yes, you *can* bind those ports, without root, without patching the kernel. You just need the server to have the cap_net_bind_service capability.
It turns out that it's impossible. Caps are unconditionally dropped during the ID switch.

> See e.g.
> http://stackoverflow.com/a/7701793
Erm... You can see that it's an answer by some guy named Cyberax. I've just added a comment saying that it doesn't really work.

> Alternatively you can use authbind (which, these days, years later, does actually support IPv6)
Which is even a greater hack.

And all of that for something that does not add any real security.

This is BROKEN!

Posted Dec 18, 2014 19:05 UTC (Thu) by meyert (subscriber, #32097) [Link] (5 responses)

let systemd take the port and give it to the service via StandardInput=socket !

This is BROKEN!

Posted Dec 18, 2014 19:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Doesn't work. Ejabberd creates sockets depending on its configuration, and it can even be reconfigured at runtime.

This is BROKEN!

Posted Dec 18, 2014 19:33 UTC (Thu) by cesarb (subscriber, #6266) [Link] (3 responses)

Ejabberd is written in Erlang, right? Could it use two Unix processes, the normal one and one running as root (with all caps except binding to low ports dropped and no_new_privs set) to listen on low ports and relay whatever is needed over Erlang's IPC?

Or, in a more Unix style (and working for any language, and with a smaller part running as root): have the root part do nothing more than opening the listening socket and giving the socket to the main program via file descriptor passing.

This is BROKEN!

Posted Dec 18, 2014 19:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I don't think Erlang can send the actual sockets. And then there's a question of reliability (you suddenly start to depend on the dispatcher process functioning correctly, even in cases of OutOfMemory conditions).

> Or, in a more Unix style (and working for any language, and with a smaller part running as root): have the root part do nothing more than opening the listening socket and giving the socket to the main program via file descriptor passing.
Ejabberd creates sockets dynamically during the configuration parsing. There's no sharply delimited synchronization point where you can drop the caps.

This is BROKEN!

Posted Dec 18, 2014 19:39 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

> > Or, in a more Unix style (and working for any language, and with a smaller part running as root): have the root part do nothing more than opening the listening socket and giving the socket to the main program via file descriptor passing.
> Ejabberd creates sockets dynamically during the configuration parsing. There's no sharply delimited synchronization point where you can drop the caps.

Sorry for being unclear. I meant a small helper Unix program, running as root, which receives a request from the main program "open me port 1234" through the Unix domain socket, opens a listening socket on the requested port, sends the socket's fd to the main program via file descriptor passing, and closes its copy of the fd.

This is BROKEN!

Posted Dec 18, 2014 19:42 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, I understood that. That's how authbind works (except that it uses a small privileged helper).

It still is a crap solution - lots of complexity and potential for failures for no real reason at all. What's even more infuriating is that the whole capability mechanism in Linux seems to be braindead, because even simple obvious actions are clearly impossible.

This is BROKEN!

Posted Dec 19, 2014 2:35 UTC (Fri) by foom (subscriber, #14868) [Link] (1 responses)

> Erm... You can see that it's an answer by some guy named Cyberax.

Haha, did not see that. :)

You can use filesystem caps on the ejabberd binary now at least, can't you?

This is BROKEN!

Posted Dec 19, 2014 2:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, and that's why it worked when I was writing the answer. I have set caps bits on ejabberd, so my solution 'worked'.

However, it's a very brittle:
1) It doesn't survive ejabberd upgrades.
2) It's not transparent - NOBODY checks file caps.
3) It does not survive the exec() call.

This is BROKEN!

Posted Dec 25, 2014 11:32 UTC (Thu) by job (guest, #670) [Link] (5 responses)

Wouldn't a more sane default be for ejabberd to bind a dedicated (high) port, since there might be a lot of packages on the system providing a web based control panel?

The user could then multiplex whatever applications he/she wanted to publish (using URL routing and/or SNI) using the standard web server component provided by the system?

At least this is how I would expect things to work.

This is BROKEN!

Posted Dec 25, 2014 19:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

It's more complicated. Jabber's SSL tunneling uses a custom non-HTTP protocol over the HTTPS port. So you can't use nginx to do proxying.

And there might be additional reasons to want ejabberd to listen directly on ports 80 and 443. For example, I want only ejabberd on that machine without having to exposure a huge daemon written in C to the network.

This is BROKEN!

Posted Dec 26, 2014 4:25 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Is it something an nginx extension could handle to proxy?

This is BROKEN!

Posted Dec 26, 2014 9:28 UTC (Fri) by cesarb (subscriber, #6266) [Link] (2 responses)

You can also use iptables to proxy from a low port to a high port.

(It exposes a huge kernel written in C to the network, but it's already exposed anyway, so...)

This is BROKEN!

Posted Dec 26, 2014 18:37 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Except it does not work with localhost, as far as I remember.

This is BROKEN!

Posted Dec 26, 2014 21:37 UTC (Fri) by foom (subscriber, #14868) [Link]

Works fine if you set up the iptables rules correctly. Local packets don't go through PREROUTING/POSTROUTING, so you also should add a rule on the OUTPUT nat table for packets destined for interface lo.