"Workstation" Product defaults to wide-open firewall

[Bastien Nocera]

----- Original Message -----
> On 10 December 2014 at 11:47, Bastien Nocera <bnocera at redhat.com> wrote:
<snip>
> >> I see no
> >> explanation of why rygel needs a random port or why it cannot supply
> >> that information to firewalld. The same goes for any others that have
> >> random ports.
> >
> > Because that's the mechanism the kernel offers for applications when
> > selecting a
> > port isn't important, the high port isn't defined by the IANA, and the
> > specs
> > (DLNA/UPnP in this case) don't force particular ports to be opened.
> >
> > Even if we chose static ports for those (or rather port ranges, because if
> > you
> > have multiple users running, you'd need multiple ports), leaving only those
> > ports
> > opened wouldn't stop other random applications from choosing those ports to
> > do something nefarious. You're just limiting the availability of ports
> > without
> > increasing security.
> 
> There's no predefined port. So rather than picking one, which would be
> perfectly possible, any port is asked for. Yes, limiting it to one
> means only one user can use it without changing those scary settings,
> but how often is that actually done?

It's relevant enough that it's a problem.

> Having the other ports closed
> prevents unintentional exposure and also makes life harder for any
> nefarious use. But this has all been pointed out already. It also, if
> I understand correctly, means policies could be shipped with the
> package.

firewalld maintainers didn't want policy to be anywhere but in firewalld
itself (or in sub-packages).

> But if you really want to use a random port, this is what firewalld
> was for, dynamic firewall changes. In fact, a quick google finds this
> bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=626188
> Which was showing progress towards rygel being able to do that. But
> it's been closed 'next release', because apparently the ports above
> 1024 have been unblocked in the firewall. Except this is not a fix, as
> (as we've learned) it doesn't apply to Fedora other than Desktop and
> Cloud. That's an interesting move, perhaps you would like to suggest a
> 'fixed in product X' resolution for use in future.

There's absolutely no way that firewalld is going to be anything but a
Fedora-only thing, which is a first problem in getting any patches to
upstream projects. Which is the first problem.

Adding support for firewalld's D-Bus APIs to every application, even
just the ones we ship by default, would demand huge amounts of work
(I think you'd be looking at a full cycle for one person just doing that).

And, as firewalld won't have application whitelists (probably because we
still can't detect applications securely), or port whitelists (because if you
don't require a root password, any app can poke holes, even behind your back),
there's not a lot of leeway in terms of user interface.

Yeah, it's fixable, it's only code, except that I don't want to make this my
life's work. We can certainly revisit when any of the above changes.

Cheers