question: Possible to disable API?

[buzz]

Version information:

go-ipfs version: 0.4.4-
Repo version: 4
System version: amd64/linux
Golang version: go1.7.1

Type: Question

Priority: P4 (?)

Description:

Is it possible to deactivate the API for security reasons? And would that make sense at all?

Situation: Trying to run ipfs daemon on a shared Linux host.

Problem: It seems currently the API is not secure (#2389, #1532, ipfs/notes#159) in a shared hosting environment. Is this true?
I think this is true because other users can actually access the API from 127.0.0.1.

I am trying to stop the daemon from listening on 127.0.0.1:5001 by removing it from Addresses in the configuration file. For the gateway this is possible but for the API this happens:

$ ipfs daemon
Initializing daemon...
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.2/tcp/4001
Swarm listening on /ip4/192.168.1.157/tcp/4001
Swarm listening on /ip4/x.x.x.x/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Error: serveHTTPApi: manet.Listen() failed:  is not a 'thin waist' address

If I look at the code this behaviour becomes clear.

Would this actually work at all? Are there parts of the software/commands that depend on the API? The web UI part of course wouldn't work anymore. But that wouldn't be a problem.

Thanks!

[ghost]

You can't currently disable the API, since every CLI command apart from ipfs daemon requires it. We eventually want to have unix sockets as an alternative, but that's not gonna happen very soon.

[ghost]

If you're on a shared hosting plan because of pricing, you can also get $1 VPSes.

[buzz]

Thanks for getting in touch so quickly.

You can't currently disable the API, since every CLI command apart from ipfs daemon requires it. We eventually want to have unix sockets as an alternative, but that's not gonna happen very soon.

I was expecting this. Bummer! Read about API tokens and switching to unix sockets. But looking for something working now... (or at least soon) ;)

If you're on a shared hosting plan because of pricing, you can also get $1 VPSes.

I'm not on any plan. I'm evaluating IPFS to be used in a resilient, distributed CDN. Something it generally seems very well suited for.
But often people have to share the hosts they use for one reason or another. Often they cannot easily go for a cheap VPS.

Could you think of any other way to secure the API from users on the same host?

[ghost]

Lock down port 5001 to a certain user using iptables

[buzz]

Lock down port 5001 to a certain user using iptables

Generally users lack privileges on shared hosts to do so. Should happen on application level...

[ghost]

It might be possible using user+net namespace magic (unshare, ip link add, ip netns, ip tuntap, etc.) but I've been trying to for an hour and didn't get anywhere.

One other option — completely insecure mind you, will only keep lazy prying eyes out — is to have it bind to a loopback address that isn't 127.0.0.1. You have an entire /8 to play with there.

[ghost]

This would be pretty useful. Should have an API key at a minimum for writing changes.

[Stebalien]

We should add support for tokens but we're always going to have to expose the API somewhere.

Given that unix domain sockets also has it's own issue. I'm going to close this one (as simply disabling the API entirely isn't really an option).