On 8/27/19 7:36 AM, Björn Persson wrote:
Jason Montleon wrote:
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.
You wanted to block VNC with a packet filter and kludge it into an SSH
tunnel. One of my suggestions was that VNC could integrate with SSH to
support that without the need for the kludge and the blocking. Any
vulnerabilities in VNC or SSH that would affect my approach would affect
yours just the same. If I'm expecting perfect code then so are you.
You tried a strawman argument, and got knocked out by your own strawman.
Björn Persson
What strawman? If VNC is behind an SSH tunnel TODAY and not exposed on
the local network and has a vulnerability how will it be taken advantage
of without first abusing a vulnerability or authenticating via SSH.
Today. Not in a year when someone has maybe added the features you're
dreaming of.
It's not like this is a Linux only problem with desktop sharing services
either. See recent Windows vulnerabilities:
https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/
Your whole idea is premised on every application being written
perfectly, which they're not, or we'd never have to do a dnf update to
get security fixes. And you're really hung up on the example of VNC for
some reason.
What about a rails developer who starts up mysql or postgres to do some
development and suddenly their DB is exposed to the world without their
explicitly opening the port and expecting it? What if their is a
vulnerability in one of those now?
This firewall policy of having all these services exposed by default is
just plain awful any way you look at it.
_______________________________________________
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
Software Engineer | gpg key: 0x069E3022
Red Hat, Inc. | irc: jmontleo
desk: 978-392-3930 | cell: 508-496-0663
_______________________________________________
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
