And even if they implemented it your way you are expecting that the developer of the application and all the libraries it uses have written perfect bug free code with zero vulnerabilities. By that logic we should set selinux to disabled since it sometimes causes things to break, can be difficult to diagnose, and everyone should have written perfect code. It should be the users decision based on what they know (are they on a private network they trust or a public network they don't and so on) to decide if the risk is worth the convenience. I have also never seen anywhere on a download page that there are security implications for downloading Workstation instead of Server. On Mon, Aug 26, 2019 at 7:10 PM Björn Persson <Bjorn@rombobjörn.se> wrote: > > Jason Montleon wrote: > >Imagine starting up VNC, having no intention of opening port 59xx, and > >intending to use SSH tunneling to connect to the service. > > > >You think you're being more diligent only to later find out the service > >is actually exposed by the default firewall policy. > > When I looked at VNC many years ago it was one of those programs that > think "I don't need to bother with security. Someone else makes me > secure somehow. I don't know how and I don't care.". Your wording > suggests that the VNC you refer to still works that way. > > You have to be very careful and know exactly what you're doing if you > use such programs. That "someone else" who makes them secure, that's > you, the user, because no one else is doing it. If you fail to check > whether you have a packet filter, then you're not being careful enough. > > The problem isn't that you're careless. The insecure program is the > problem. Programs like that should come with big red warning labels > saying not to touch them unless you know exactly what you're doing – > but they don't, because they assume that someone else takes care of > everything security-related. > > The better solution is for VNC to take responsibility for its own > security. It could do so by using TLS, by integrating with SSH, or by > requesting IPsec from the operating system. It should refuse to > communicate without one of those encryption protocols, or at the very > least require the user to explicitly turn off security. These days > there seem to be several VNC variants that support some form of > encryption. I don't know what their defaults are, but maybe some of > them are responsible enough to not communicate insecurely. > > Björn Persson > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx -- Jason Montleon | email: jmontleo@xxxxxxxxxx Red Hat, Inc. | gpg key: 0x069E3022 Cell: 508-496-0663 | irc: jmontleo / jmontleon _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
