"Workstation" Product defaults to wide-open firewall

[Ian Malone]

On 10 December 2014 at 11:47, Bastien Nocera <bnocera at redhat.com> wrote:
>
>
> ----- Original Message -----
>> On 10 December 2014 at 00:43, Bastien Nocera <bnocera at redhat.com> wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> On 9 December 2014 at 13:47, Matthew Miller <mattdm at fedoraproject.org>
>> >> wrote:
>> >> > On Tue, Dec 09, 2014 at 01:11:33PM +0000, Ian Malone wrote:
>> >> >> > have a proposal for a new spin focused on privacy and security — the
>> >> >> > Netizen Spin. (If you're interested, I think that could use
>> >> >> > additional
>> >> >> > contributors.)
>> >> >> I was under the impression spins were to be phased out. I could be
>> >> >> wrong, the discussion was about the time of the product proposal.
>> >> >
>> >> > That's wrong; the clear outcome of that discussion was that we want to
>> >> > keep them, and provide more flexiblity and opportunity for spins
>> >> > maintainers as well.
>> >> >
>> >>
>> >> Well that's some good news to come out of this at least.
>> >>
>> >> > Everyone knows that there are improvements to be made, but it's _not_
>> >> > an easy problem. Contributions are welcome towards making that better
>> >> > for F22 and beyond. (Use cases. Design mockups. Code....)
>> >> >
>> >>
>> >> Rather time poor at the moment and not a gnome developer
>> >> unfortunately. Does rather sound like things like rygel need fixed,
>> >> but as I have no intention of ever using it I'm not highly motivated
>> >> to do something about it.
>> >
>> > Just like Reindl you make the mistake of thinking that rygel needs to be
>> > fixed
>> > or that it's the only service impacted by this scheme. It's not, and it was
>> > pointed out in earlier mails.
>> >
>>
>> You're sniping at me now, and making assumptions. So I get to do this,
>> please read the fedora code of conduct and be awesome!
>> http://fedoraproject.org/code-of-conduct
>
> Given the amount of time I've thrown into this dead-end thread, I think
> I'm already pretty awesome.
>
>> I have skimmed the links you listed. Like I said, time poor.
>
> You'll accuse me of being rude again, but if you can't read 3 pages of text
> because of the lack of time, maybe spending that time throwing factually
> and technically incorrect suggestions on the list shouldn't top of your
> TODO list.
>

Well, there are different levels I suppose. There's, "I don't have
time before work to read through three pages of chaff AND COMMENTS in
detail." As it turned out the only salient point was in a comment. The
rest was pretty irrelevant.
There's, "I don't have time in the foreseeable future to spend
learning sufficient information about the internals of the various
systems to help out with this particular problem." There's, "I used to
spend time doing spin QA, but hardware requirements are currently such
that I can't virtualise recent releases and don't have time for bare
metal testing which may change in the new year."
And there's, "I do have time to respond to an email accusing me of
making factually and technically incorrect suggestions." Because I'd
have walked away at this point if you hadn't felt like padding out
your wonderful life coaching.
(I note that I'm a saddo who doesn't know how to manage time, but
you're awesome for spending time on exactly the same thread.)

You answered precisely half of this:

>> 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? 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.

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.

-- 
imalone
http://ibmalone.blogspot.co.uk