----- Original Message ----- > On 10 December 2014 at 11:47, Bastien Nocera <bnocera@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
