UDP firewall rules for Windows.

UDP firewall rules for Windows.

On Windows, Chrome cannot pick the local port for a UDP packet without
Windows Firewall thinking that Chrome is trying to listen for incoming
connections. In fact, Chrome is not, it just wants to pick a specific
local port for an outgoing packet. This change introduces the
FirewallManager in installer_util. This is used by the installer to add
(and remove at uninstall) a rule to block inbound UDP packets for Chrome
so that Chrome can safely pick local ports. Additionally, QUIC uses the
FirewallManager at startup to determine whether or not it's safe to pick
a local port.

BUG=329255
COLLABORATOR=vitalybuka@chromium.org

[Vitaly Buka (NO REVIEWS), 2014-02-07 21:42:03]

That's a problem.
I had impression that goal is to allow UDP not to block.
This rule will kill Local Discovery. We need 5353 open.

Right now mDns code work on windows just because it's port is in sandbox
process. Windows firewall can't show alert for sandbox process, so it's allow
incoming traffic for a short time, it's enough for us so far. But with blocking
rule it's not going to work at all.

So if we don't want allow all UDP traffic, we need also add 5353 rule.

[rvargas (doing something else), 2014-02-11 19:19:37]

On 2014/02/07 21:42:03, Vitaly Buka wrote:
> That's a problem.
> I had impression that goal is to allow UDP not to block.
> This rule will kill Local Discovery. We need 5353 open.
> 
> Right now mDns code work on windows just because it's port is in sandbox
> process. Windows firewall can't show alert for sandbox process, so it's allow
> incoming traffic for a short time, it's enough for us so far. But with
blocking
> rule it's not going to work at all.
> 
> So if we don't want allow all UDP traffic, we need also add 5353 rule.

Just to double check, if you delete all chrome firewall rules, then run a canary
build and dismiss the dialog that pops when connecting to youtube, is your
feature broken? Sounds like you needed a rule from the start...

[Vitaly Buka (NO REVIEWS), 2014-02-11 22:42:38]

On 2014/02/11 19:19:37, rvargas wrote:
> On 2014/02/07 21:42:03, Vitaly Buka wrote:
> > That's a problem.
> > I had impression that goal is to allow UDP not to block.
> > This rule will kill Local Discovery. We need 5353 open.
> > 
> > Right now mDns code work on windows just because it's port is in sandbox
> > process. Windows firewall can't show alert for sandbox process, so it's
allow
> > incoming traffic for a short time, it's enough for us so far. But with
> blocking
> > rule it's not going to work at all.
> > 
> > So if we don't want allow all UDP traffic, we need also add 5353 rule.
> 
> Just to double check, if you delete all chrome firewall rules, then run a
canary
> build and dismiss the dialog that pops when connecting to youtube, is your
> feature broken? Sounds like you needed a rule from the start...


Yes, we need rule, but it was not essential. We don't trigger firewall at all
(because of sandbox), and feature works. So users have no chance to dismiss
alert. If user runs with --no-sandbox firewall may be triggered. But number of
affected users should be small. So we postponed implementation of our rule.

With current version of patch feature will be broken for all users immediately.

[Vitaly Buka (NO REVIEWS), 2014-03-14 01:54:49]

On 2014/02/11 22:42:38, Vitaly Buka wrote:
> On 2014/02/11 19:19:37, rvargas wrote:
> > On 2014/02/07 21:42:03, Vitaly Buka wrote:
> > > That's a problem.
> > > I had impression that goal is to allow UDP not to block.
> > > This rule will kill Local Discovery. We need 5353 open.
> > > 
> > > Right now mDns code work on windows just because it's port is in sandbox
> > > process. Windows firewall can't show alert for sandbox process, so it's
> allow
> > > incoming traffic for a short time, it's enough for us so far. But with
> > blocking
> > > rule it's not going to work at all.
> > > 
> > > So if we don't want allow all UDP traffic, we need also add 5353 rule.
> > 
> > Just to double check, if you delete all chrome firewall rules, then run a
> canary
> > build and dismiss the dialog that pops when connecting to youtube, is your
> > feature broken? Sounds like you needed a rule from the start...
> 
> 
> Yes, we need rule, but it was not essential. We don't trigger firewall at all
> (because of sandbox), and feature works. So users have no chance to dismiss
> alert. If user runs with --no-sandbox firewall may be triggered. But number of
> affected users should be small. So we postponed implementation of our rule.
> 
> With current version of patch feature will be broken for all users
immediately.

Hi Greg. we are going to move mdns to browser process for M36, so we need to
setup firewall rules 
I'd like to continue to work on this and summit at least necessary part.

[grt (UTC plus 2), 2014-03-14 16:45:33]

On 2014/03/14 01:54:49, Vitaly Buka wrote:
> Hi Greg. we are going to move mdns to browser process for M36, so we need to
> setup firewall rules 
> I'd like to continue to work on this and summit at least necessary part.

I've added you as COLLABORATOR on this issue in case you'd like to use it.
Please keep chrome-security in the loop, since on XP I think you'll need to make
the rule allow all inbound connections to chrome.exe. I'm happy to review any
changes you make. Keep in mind that it's still the case that Chrome's installer
can't modify firewalls rules for user-level installs, so consider adding UX that
guides the user to making the correct choice if the firewall rule isn't present.