New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 601 users

Issue metadata

Status: Verified
Owner:
Closed: May 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature

Blocked on:
issue 433042
issue 435404
issue 435406

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Implement a mechanism to open up firewall holes for chrome.socket.listen/accept

Project Member Reported by benjhayden@chromium.org, Apr 18 2013

Issue description

Chrome Version: 26.0.1410.57 (Official Build 191765) beta
Chrome OS Version: 3701.81.0 (Official Build) beta-channel link
Chrome OS Platform: Dogfood Arrow/Pixel
Network info: Linksys WRT54G2 Firmware version 1.0.01

Steps To Reproduce:
1. Run https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver
2. Attempt to access the server from another machine on the wifi network

Expected Result:
Can access the chromeos webserver from another machine

Actual Result:
Cannot

How frequently does this problem reproduce? Always

What is the impact to the user, and is there a workaround? If so, what is
it?
I want to run a server that is only accessible inside my wifi network, and that my wife can start/reconfigure without me.
No known workaround.

Wireshark trace attached.
 
chromeos-server.pcapng
91.8 KB Download
Forgot to mention a couple of details.

chromeos is suspected rather than the router because the server is accessible from other machines when run on a macbook.

Minor modifications were made to chrome-app-samples/webserver to refactor and because the socket api is no longer in experimental.

I want to run the server on our chromebox because the only other programmable computer that we have in the house that is not owned by Google is an ancient black macbook that won't live much longer. I suppose I could buy a cheap headless machine like a raspberry pi, but I'm trying to Simplify.
Labels: Cr-Internals-Network
Perhaps somebody on the network team might know something about server sockets on chromeos.
Cc: miket@chromium.org

Comment 4 by miket@chromium.org, Apr 18 2013

Cc: wad@chromium.org
wad@: See #2.
This is almost certainly due to our firewall rules.  I doubt anything is broken.  How do chrome sockets deal with firewalls on other platforms?
Cc: cmasone@chromium.org
Would something like this open up the port in the firewall?
sudo /sbin/iptables -A INPUT -p tcp --dport 9482 -j ACCEPT
from https://sites.google.com/a/google.com/mkrebs/references/chrome-os

Would that require dev-mode?

If that'll work, perhaps it should be documented here? https://developer.chrome.com/apps/app_network.html
Or could chrome.socket.listen automatically open the port in the firewall on chromeos?

I think that's the question :-)  Using this API on CrOS probably shouldn't require you to open firewall ports manually, but it's not clear how chrome should go about getting them opened.

You can go into dev mode and run that command to open your ports, though, to answer the immediate question
Just in case anybody is ever in this situation, I can confirm that switching to dev-mode and running the command in #6 does allow other computers on the network to access the server.

Looking forward to being able to go back to managed mode.
Cc: jorgelo@chromium.org
+jorgelo@

Can something similar to what was done for DIAL be done for the socket API to open up TCP ports?
Cc: deepakg@chromium.org
Status: Untriaged

Comment 11 by sidv@chromium.org, May 1 2013

Labels: -Cr-Internals-Network Cr-OS-Systems-Network
Labels: -Type-Bug Type-Feature
Owner: trond@chromium.org
Summary: Open up firewall for chrome.socket.listen/accept (was: chrome.socket.listen/accept broken)
The setup used for DIAL is not appropriate here, since it is constrained specifically to UDP replies to a specific outgoing multicast transmission.  It sounds like you're asking for the firewall to open up specific UDP ports as a result of an action within Chrome.  There's no infrastructure for this, and would be a new feature request.
This is essentially, asking for a way for any chronos process to open up all incoming ports, right?  Is there any value left in the firewall, given such a feature?
#13: chrome.socket.* is available only to Chrome Apps requesting appropriate, specific permissions.
Yes, we've discussed this before. It still restricts all other daemons, and it will also provide a way to notice listening functionality added outside of an app.
If the feature had a way to guarantee that the caller was bound to the port they were asking the firewall to open, you could argue that such a feature might be more selective.  @jorgelo: Do you have an issue to duplicate this one to?
But Chrome needs to be able to tell Shill (or someone) to open up a port, and will do so over DBus.  Chrome runs as the user "chronos", and I don't believe we have any mechanism for authenticating DBus traffic beyond uids.  This means that any process on the system running as chronos would be able to disable the firewall pretty much entirely.

And, frankly, any Chrome app would be able to as well.
cmasone: totally agreed. My point was that even in that case, the firewall would still be useful. I'm not arguing for this feature specifically.
This bug basically renders chrome.socket.listen useless on ChromeOS, as you can never connect to the port. 
I discovered this issue today on ChromeOS 28.0.1500.11 4100.7.0.

Can confirm that developer mode and opening the port mnaually in iptables does resolve the issue, but for clarification, the extension should automatically open the port when   listen is called.

Comment 20 by miket@chromium.org, Jun 27 2013

Can the USB broker process be generalized to make these decisions and tweak the firewall as needed?

Comment 21 by chron@chromium.org, Jun 27 2013

Cc: chron@chromium.org
Labels: M-31
Owner: quiche@chromium.org
Status: Assigned
I spoke to cmasone and we think that the behavior of opening a port on the firewall is OK if the socket was successfully opened for the application requesting it-- i.e. we check that the socket was bound for the app and not for say, SSH.

Mukesh I think you might be the right person for this, I've put this on 31 for now.
Happy to take the OS side of the work, but this will require some work in Chrome as well:

1. adding a way to make the D-Bus call to open the firewall hole
2. adding a way to make the D-Bus call to close the firewall hole
3a. extending the sockets API to request opening a firewall hole, or
3b. changing the chrome.socket.listen API to automatically call the "open firewall hole" API
4. changing the chrome.socket implementation (or something else) to close the hole when the app/extension is terminated

#1 and #2 sound like things that @stevenjb or @gauravsh might work on.
#3 and #4 might be @ikarienator

@chron, can you find owners for those. 
Well, at the OS level we can only check that the socket was open for Chrome right?
#c23: Right. I'd read "for the application requesting it" to mean "by Chrome".

Along with that, Chrome would be responsible for ensuring that Chrome Apps are only allowed to firewall holes for sockets they have open. (That would be automatic with 3b in #c22, or would require some checks in the socket API implementation for 3a.)
Agreed on c#24.

Comment 26 by wad@chromium.org, Jun 27 2013

Cc: sumit@chromium.org
And don't forget, DBus can pass file descriptors.  So the broker could open the fd with the right flags and pass it over dbus back to chrome for use.

The key things to consider are if we'd be clobbering any listening ports we expect system services to be on.  We can start with the normal (nothing below 1024), but in reality we could open up more space than that if needed.

As to firewall efficacy, it should still protect against non UDP/TCP traffic, accidental exposure, etc.  However, it stills seems a bit crazy that we'd want an app to "just listen".  I doubt Chrome pokes holes in the OS X or Windows firewalls when they are enabled, the difference is that we don't let the fw be managed by the user.

Once this is functional, should we consider firewall-hole-punching a separate permission?  (I can see a lot of enterprises wanting to have the knob to disable it, for instance. Not that we have to do it.)

In general though, I think we have a few different bugs exactly along these lines.  We can dupe those to this one :)
How about having Chrome pass the fd over to the broker, instead? Then we avoid the possibility of the broker providing Chrome / apps running in Chrome with sockets they couldn't get on their own (e.g. low-numbered ports).

Comment 28 by wad@chromium.org, Jun 27 2013

That works, but it does mean we'll not be able to selectively do low number ports super easily later, but maybe that's a good thing. Either way, I think we'll be fine for starters!
Can we get what port a socket is listening on directly from the fd or do we need to include the port number separately in the IPC message (chrome->broker)?

Comment 30 by pstew@chromium.org, Jun 28 2013

I'm not sure about the exact context of the question, but if you look at /proc/<pid>/fd, and also /proc/net/{tcp,udp}, you'll see that there's a wealth of ways you can map back and forth between process ID, fd and listening port.
That answers the question :-D

Comment 32 by quiche@google.com, Jun 28 2013

FWIW, there's also a netlink API for this, as used by the "ss" utility (short for socket stats), in the iproute2 package.
Cc: ikarienator@chromium.org
Cc: flackr@chromium.org rbyers@chromium.org kuscher@chromium.org
 Issue 259410  has been merged into this issue.
Cc: rpaquay@chromium.org

Comment 36 by wad@chromium.org, Sep 23 2013

Cc: jln@chromium.org
 Issue 225406  has been merged into this issue.
Labels: -M-31 M-32 MovedFrom-31
Moving all non essential bugs to the next Milestone.

Comment 38 by kareng@google.com, Nov 8 2013

Labels: -M-32 MovedFrom-32
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
This effectively prevent any Chrome app listening for TCP connections from working on Chromebooks. This would open the door to advanced applications on the Chromebooks. My particular use case is to implement a UPnP/DLNA control point for controlling local devices. I need to open an HTTP/TCP server to receive UPnP Events from my local network.
Yes - its incredibly frustrating. We have an app ready to go once this bug is fixed, but its been pushed back from 31 and 32.... 

Comment 41 by guan...@gmail.com, Dec 9 2013

I have the same issue to implement a remote controller for a videoplayer
Labels: Restrict-AddIssueComment-EditIssue
Please star issues to vote for them, instead of adding "me too"-style comments. It's the only scalable way to track user interest.
quiche: status update?
#c43: Sorry, no news here. I'm aware of the feature request, but am focused on other features at this time. Let me know if you're interested in contributing, though.
Cc: reillyg@chromium.org

Comment 46 by c...@chromium.org, Sep 17 2014

Labels: Cr-Enterprise
Owner: roc...@chromium.org
Status: Available
Ken, will you please find an owner for this? It's something very much worth doing.

Comment 48 by c...@chromium.org, Oct 3 2014

Cc: vidster@chromium.org saswat@chromium.org
Cc: pneubeck@chromium.org
It seems like there are three separate issues under this umbrella issue:
1) security implications of allowing installed apps to have listening ports
2) UI/UX to show these permissions and revoke them
3) specifics of how to use dbus to add iptable rules

Does it make sense to split this into three bugs?  I imagine rockot@ would only be considering (2) for instance as the owner of this.

Summary: Implement a mechanism to open up firewall holes for chrome.socket.listen/accept (was: Open up firewall for chrome.socket.listen/accept)
As long as the firewall holes are punched temporarily and are tied to the app's lifetime, we should be able to make this work.

I do think (2) and (3) can be tracked in separate bugs, blocking this bug.
Blockedon: chromium:435404
Blockedon: chromium:435406
Cc: roc...@chromium.org
Owner: jorgelo@chromium.org
Status: Assigned
I've split up a few bugs and added them as blockers. I think I'm gonna put myself as owner for this bug, at least for the time being.
Labels: -Pri-2 -MovedFrom-31 -MovedFrom-32 Pri-1 M-41
Labels: -M-41 M-42
Punting to 42.
Jorge, are you on track for 42 or will this likely slip to 43? saw some promising CLs.

Given that you have shepherded this, is an independent sec review needed?

The system side will probably be ready for 42, not sure if the Chrome side will.

We probably don't need a security review.
Chrome side will not make 42.
I can take on the Chrome side of this once the DBus interface is available.
Labels: -M-42 M-43
Punting to M-43 per comment #59.
System side is done.  Issue 435404  can happen now.
Blockedon: chromium:433042
Labels: -Cr-Enterprise Hotlist-Enterprise
Adding Hotlist-Enterprise per #26. Removing Cr-Enterprise, since no Chrome OS Enterprise development work is needed.
Labels: -M-43 M-44 MovedFrom-43
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)


Ref: https://sites.google.com/a/chromium.org/dev/developers/ticket-milestone-punting-1
Status: Fixed
All blocking bugs has been closed which means this feature has been implemented. It is currently hidden behind the --enable-firewall-hole-punching flag which will be removed for M-44.
Labels: Needs-Feedback
what manual testing do we require for verification of this issue?
Issue 478231 is the launch bug for this, issue 478295 describes testing.
Status: Verified
Used tcp server demo app to create a server and check if it is reachable from another system on the same network.
Minnie -R44 -7077.1.0

Sign in to add a comment