<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-15 18:13 GMT+02:00 Andrew Lutomirski <span dir="ltr"><<a href="mailto:luto@mit.edu" target="_blank">luto@mit.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
> Example: user installs software X... but oops, they didn't realize it<br>
> was going to listen on port Y.... but that's okay, because no firewall<br>
> rule has been enabled to allow traffic on port Y, so the user is<br>
> secure.<br>
<br>
</div></div>This sounds like a problem that should be separately fixed.</blockquote><div><br></div><div>Well, yes, but then <i>we really need to be 100% sure we have fixed it</i>. See also your own report that installing gnome-boxes pulls in running services with open ports.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With firewalls, a service, system or otherwise, can be in one of three<br>
states: a) listening w/ firewall open, b) listening w/ firewall<br>
closed, c) and not listening.<br></blockquote><div>d) not listening, actively opening connections to the outside, and sending users' private data over there, or receiving commands from there to send arbitrary data.<br>
<br></div><div>Just so we are clear on the relative threat levels, malicious applications (if you are lucky, "only collecting data for the purpose of advertising") are so frequent nowadays that <i>they</i> are the primary threat of unwanted network communication, perhaps comparable only to automated ssh password guessing bots. Linux has so far been "lucky" in not having enough third-party applications for this to be a threat yet, but Workstation intends that to change. (And no, a firewall won't help you at all for d) ).<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I keep thinking that, if I had unlimited time, I'd write a totally<br>
different kind of firewall. It would allow some policy (userspace<br>
daemon or rules loaded into the kernel) to determine when programs can<br>
listen on what sockets and when connections can be accepted on those<br>
sockets.</blockquote><div><br></div><div>Similarly, ports (what I assume you mean) are getting less and less important nowadays. So much happens multiplexed over HTTP, and there are various "zero-config" browsing/advertising mechanisms that don't require use of fixed ports, only the privilege to advertise a port through the browsing mechanism.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wouldn't it be great if, when you start some program that wants to<br>
listen globally, your system could prompt you and ask whether it was<br>
okay, even if that program didn't know about firewalld?<br></blockquote><div><br></div><div>In general (assuming "unknown software" and not just specific 3 services that can be individually handled in control-center, or software specifically adjusted by Fedora to know about firewalld), no. I have no idea what the program is going to send over that connection, so I don't know how to answer, and the program can send the same data through an outgoing connection without ever interacting with the restricted listening functionality; I simply must trust the author of that program—or to prevent the program from accessing my data at all, and then the answer doesn't matter.</div>
</div> Mirek<br></div></div>