Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Sunday, August 14, 2016

How to encode URL for HTTP over unix domain sockets? from Claes H on 2008-10-09 (uri@w3.org from October 2008)

How to encode URL for HTTP over unix domain sockets? from Claes H on 2008-10-09 (uri@w3.org from October 2008):

What would be a good way to encode URLs for communication using HTTP
over Unix domain sockets?
...Background: I have for a while wondered why HTTP is rarely used for local RPC, since it is has been so successful on the Internet. Using it over TCP on localhost is certainly possible, but it can be argued that it has security and performance issues, so other options are chosen.
'via Blog this'



Claes:


I found email from you in an archive at https://lists.w3.org/Archives/Public/uri/2008Oct/0000.html

How to encode URL for HTTP over unix domain sockets?

Date: Thu, 9 Oct 2008 21:47:10 +0200
Background: I have for a while wondered why HTTP is rarely used for
local RPC, since it is has been so successful on the Internet. Using
it over TCP on localhost is certainly possible, but it can be argued
that it has security and performance issues, so other options are
chosen.

Q: did you ever get any answers to this?

Has there been any movement on this?

Do you know of any HTTP client (ideally, a webbrowser) that can access unix domain sockets, using their filesystem names?

Ditto HTTP servers - although for my current purpose that I can code myself, e.g. modifying Perl CPAN's HTTP::Server::Simple to support AF_UNIX.

Every decade or so since the 1980s (yes, before the web) I go looking for this, and I must admit that I am amazed that it does not exist (Which I suppose suggests that I should get off my lazy ass and write it, adding support to an open source webbrowser like FireFox.)


If you want to use localhost to develop a web service, you either need to trust all applications on your local host, or you need to build a proper authentication and security system.

IMHO nobody should ever trust all applications on your local host.  Certainly not back in the day when your local host might be a university VAX shared between hundreds of students.   But IMHO also not nowadays, with mostly single user PCs or phones - because malware may be trying to break into your system, and if it breaks into a non-privileged user account but can access localhost it can ask whatever is at the other end of a localhost connection to do stuff.  And since I am imagining a system where software under development is using localhost, it may not validate requests as well as one would like. 

UNIX domain sockets subject to filesystem permissions are in many ways an authentication and security system that is factored out separate from the HTTP server.

Failing this, one needs to have a proper authentication and security system set up from the very moment one starts developing a network service.  Or else you are vulnerable to attacks while your software is under development.


2 comments:

Andy Glew said...

Yes, I know that virtual machines make it easier to ensure that all applications on localhost on a guest VM can be trusted.

But, y'know ... I worked on virtual machines at Intel as early as 1991.

I use a virtual machine on my Mac every day to run Windows apps.

But... I expose all of my Mac filesystem to the Windows guest. For convenience. Because I am using this virtual machine to get as close-to-transparent access to all of my files from both Windows and Mac apps. I am not using it for security.

While I can and should probably create VMs specifically for security... VMs are a pain. Just more systems to administer, to get security settings incorrect on. Not only on host OS, guest OS, but also in the VMM/hypervisor.

When you are an IT department managing hundreds of systems, virtual and non-virtual, you can set up scripting to sanity check all. But if you are a user with only a few such VMs, some used for transparency and others used for security...

VMs can be a hassle: I occasionally listen to Randall Schawrtz's FLOSS podcast. Randall often comments that he hated developing for clients that required him to use VMs, booting them several times a day, paying a startup penalty whenever they tied out while he was away from his desk.

Containers are motivated in large part by VMs being a hassle.

Think about it: UNIX domain sockets are basically containerized INET sockets. Using a much more pleasant namespace.

Andy Glew said...

Yes, UNIX domain sockets have their own security problems.

E.g. on Cygwin, AFAICT UNIX domain sockets are implemented on top of localhost sockets, and have no security to speak of.

Also, passing around open file descriptors is ... interesting. Can be used to build more secure systems, but I am sure also can be a security hole.