I have the following Electron-ish usecase:
User creates a http daemon listening on connections from local host on port X
User launches web browser and goes to http://localhost:X
Since the http daemon was created by the current user, it shares its permissions (which for this application must be correct).
Problem: Any user may on current machine may connect to the server, which means that private data is shared among all users. Is it possible solve this on system level, like changing permissions on file descriptors, or is it necessary to use some kind of login scheme.
Related
We have created self-hosted services using OWIN. They are working fine inside the server and we can request and retrieve information using the http://localhost. We use a different port for each service so that we can go and get certain information from http://localhost:8001, other from http://localhost:8015 and so on.
Now, we need to expose the results of one of those self-hosted services to access to it through internet. We'd like to provide a custom address such http://ourpublicinfo.mydomain.com:8001 or using the server ip such http://209.111.145.73:8001.
Is that possible?
How can we implement it?
Our server OS is Windows Server 2012 R2
OWIN Self-Hosted apps can run on a Windows Service, as a Console process and, with if desired, as part of a more robust Host like IIS.
Since you mention your app is running as a service you're probably missing all the GUI goodies IIS provides. In reality however, IIS works on top of http.sys, just as HttpListener does (which is probably what you're using to self-host your app) 1. You just need to do some manual set up yourself:
First of all, you need to make a URL reservation in order to publish on a nonstandard port.
Why would you do that? Quite simply because you're not running under localhost alone anymore on your very own local machine, where you probably are an admin and/or have special privileges/powers.
Since this is a server, and the user used for running the Service might not be an admin (most probably), then you need to give permission to that user to use that URL... and here is where URL reservations come into scene.
You pretty much have to options:
open up the URL to be used by any user:
netsh http add urlacl url=http://209.111.145.73:8001/ user="everyone" listen=yes
or open up the URL to be used by the user(s) running the service, e.g.: NETWORK SERVICE:
netsh http add urlacl url=http://209.111.145.73:8001/ user="NETWORK SERVICE" listen=yes
There is a way to make the reservation for several users too, using sddl, user groups, etc... but I'll not get into it (you can look that up).
Second of all, you need to open up a hall through your firewall (if you don't have one on this day and age, I pity you!)
There are plenty of tutorials on this. You can use a GUI, netsh.exe and what not.
Pretty much all you need to do is make sure you allow incoming connections through that port and that should do the trick.
To make sure the hall is open through and through you can use a tool like http://www.yougetsignal.com/tools/open-ports/ and insert 209.111.145.73 in the Remote Address and 8001 in the Port Number.
If for some reason it shows that the port is closed, even after creating an incoming rule in your firewall for it, then you probably have one or more firewalls in between your server and the outside world.
With those to elements in place you should be able to access your Self-Hosted Service from the outside.
As for accessing your service through an address like http://ourpublicinfo.mydomain.com:8001, you'll need to create a DNS entry somewhere, most likely on your Domain Registrar for mydomain.com, where you could create an A Record for your ourpublicinfo subdomain pointing to 209.111.145.73.
From this point on, you should be able to access your service through direct IP and Port or through the afore mentioned URL.
Best of luck!
Note:
If your service will be access from other domains, you might need to make sure you have CORS (Cross Origen Resourece Sharing) well defined and working on your service too ;)
I am studying a tutorial on unix domain socket. I have a question on the receiver part.
If a process is using listen() and waiting for incoming requests:
what options does it have to make itself secure ? Does it have a way to identify who sent the request ? Can it apply some restriction on who can send it a request ?
Is the situation that there is there no security option and if a process uses listen() its completely open to any request ?
The general thought on Linux is that security is enforced by the file permissions on the UNIX socket "file" in the filesystem. A process must have read/write access to the socket special file.
The unix(7) man page indicates:
In the Linux implementation, sockets which are visible in the
filesystem honor the permissions of the directory they are in. Their
owner, group, and permissions can be changed. Creation of a new
socket will fail if the process does not have write and search
(execute) permission on the directory the socket is created in.
Connecting to the socket object requires read/write permission. This
behavior differs from many BSD-derived systems which ignore
permissions for UNIX domain sockets. Portable programs should not
rely on this feature for security.
It seems that directory-searching permissions are honored everywhere, though. So your socket can only be connect()ed to by users that have execute access on the entire path to your socket special file - this is true on all OSes.
Related:
Can UNIX Domain Sockets be locked by user ID?
Which systems do not honor socket read/write permissions?
Why is there this distinction between the registrated ports in well-knows and normal registred ports? Why if I decide to bind a socket on 23 I need the root privileges while on the port 1025 I do not need? What reason brought to this decision? And why, let's suppose I make a software that use a socket it is better to register the port on which it bind itself?
In the time of multiuser unix systems in university campuses, where normal users never had root access, unix systems were using ports below 1024 to indicate that the process that created the port/connection was 'trusted' by the local admin. This was used to f.e. indicate what the local user name in system A was so that a connection would use that user in system B.
I am currently running a single instance of a notebook set up for secure remote access on port 443 (https://example.com/ipython/). I would like to allow others to have access, but not to my main notebook. Is it possible to spawn multiple instances listening on the same port but with different url prefixes (such as /ipython-school/, /ipython-shared/, etc)? (as outlined here)
No it is a general technical limitation. You cannot have multiple app listening on the same port. You will have to rely on something that act as a proxy an forward request to multiple instance that listen on localhost on different port.
I've recently purchased a cloud server which has public IP and I am using it to host an xmpp server.
My first task was to ensure my users connected using my subdomain - as an example m.chat.com.
In my configuration I have the following:
%% Hostname
{hosts, ["m.chat.com"]}.
I then created an admin user with that domain.
In parrellel I have created the following DNS record with my host provider, hostgator for my subdomain m.chat.com
Name TTL Class Type Record
m.chat.com 14400 IN A [IP of the server]
One thing that puzzled me was my ability to access the ejabberd web admin console. This was achieved via: [IP of the server]:5280/admin however I could not access it via m.chat.com:5280/admin
That aside, inside the web console, under "Virtual Hosts" I could see the host "m.chat.com". I created a user "user#m.chat.com" and tried to connect via Adium.
Inside Adium, simply typing in user#m.chat.com with the password did not work. Instead I had to also specify the "Connect server" which in this case was the [IP of the server].
It has connected fine and I have registered other users to check everything is working and it is.
Then I thought I'd go back to the ejabberd configuration and start messing around. I changed the hostname to the following:
%% Hostname
{hosts, ["m.chat.com", "facebook.com"]}.
I registered a user with that domain and restarted ejabberd. Upon checking the web console, to my surprise, I could see the Virtual host "facebook.com". I tested this user in Adium with the [IP of the server] defined in the "Connect server" section and it connected fine. I asked other people with their own internet connections to use this account on their PCs and they were able to connect too.
Story over - my question to everyone is how is this possible? Am I missing something? Is there no domain authentication. After searching online, it seems you can even use fake domains.
If I am to operate my own service in the future (iOS chat app) I do not want anyone using my domain names with their own public servers.
Can someone shine some light.
Thanks!
Edit: A second question - Preferably I do not want to have to define the "Connect Server" upon using a client. I would like the client to recognise the #m.chat.com domain and establish a connection to the Servers IP automatically. Have I configured my DNS record correctly? For anyone else using Hostgator, is there an additional task I must do?
Edit: I can now access the web console via m.chat.com:5280/admin and I no longer have to specify the Connect server when using a client. I didnt do anything, I think it was a case of Hostgater updating the DNS or something, they say it usually takes 4 hours. However I am still slightly puzzled as to why I can create accounts with the facebook.com domain. I understand that because I can not access the DNS admin for this domain I can not create any records but that does not prevent me from using the domain and just specifying a Connect server.
Your initial problems (unable to access the server by using m.chat.com) were almost certainly DNS issues, and it seems you have isolated that down to the time taken to update the record.
Your second question - about the fact that you can name virtual hosts without restriction, is simple but interesting. What makes you think there should be any kind of restriction? It would be like you dictating that I can't save "m.chat.com" in a file on my disk, or that I can't send "m.chat.com" in a message across the internet.
This is why DNS exists and is structured the way it is. Although I can tell my server that it hosts facebook.com, nobody will connect to it because the DNS record for facebook.com does not point at my server (users generally don't set the "connect host" manually). Which begs the question... why would I want to tell my server it hosts facebook.com, and if I did, why should Facebook care?
An additional, but relevant, identity layer on top of DNS are certificates - which clients should validate for the virtual host name in spite of any "connect host" set. Since it's not possible to have a certificate for facebook.com, clients should generally pop up warnings or fail to connect at all. If they don't, they're probably not validating the certificate correctly.