Re: F22 System Wide Change: Default Local DNS Resolver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. snip ... People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust. I have a number of concerns about the readiness of the proposal. Right now, enabled unbound and dnssec-trigger on a laptop is an extremely difficult experience. I have since taking up this challenge found that turn it off and on again, has become the default solution on my linux install now as a result of these problems. For example, crashes in unbound that are not caught in abrt, forwarders that do not get added (but they display in the list), queries that don't ever get replies (But they work when you by-pass unbound to your glibc forwarder), inability to flush dnscache without sudo, and that dns caches are held over network boundaries to name a few of my concerns. As a result, at this time, enabling this on your system is actually more of a deteriment that the benefit being touted. I would prefer working DNS over non working secure dns. (I guess it's secure because I can send any traffic out). Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) Unbound creates more flakiness than it solves. Unbound caches no answer as a negative cache entry. If your wireless blips for an instant, that's it, result vanishes. I think that there should be a large amount of QA focus on this change. Configurations involving split-view dns should be involved in testing, testing stability of unbound between suspend/resume, or even NetworkManager restarts, testing that quieries resolve in esoteric networks (IE networks that capture and redirect DNS traffic). This is a change, that currently, has the potential to seriously damage the user experience of anyone using fedora. I think that much more rigorous testing and thought should go into this before we just steam ahead. If in it's current state you install unbound, you will begin to notice little issues quickly, especially on laptops. That is not a defalt we should aim for. NOTE: I'm not just raging here, I actually have opened BZ's for these issues that I have. I think that awareness of these issues is low, and that it should be brought to light. I hope that more thorough testing is carried out in a wider set of environments to eventually get this to a point where it's a seamless change to enable this service. However at this time, that is not the case. - -- Sincerely, William Brown -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUtQq/AAoJEO/EFteBqAmav6QP/iol4/Mk9VGWJDFIuUqlDPDH gHFtlFw3DnFQvQ6bZZXWQLOCQ058ao5fuaRAnr1cxu7cFbrdqnZtYC8cry4SbRGs EQsA2OziHdcULnBxWRXF7JgCJx1785A1TzYLduPb7GnxHteWEZFVHF4DvYvEHHa+ 5/gTZoG8SdlzKTWx5NDzjOlwYw0KlF9tLOP1afOsmDGiMPyDBqRADJxJO0dvFmQ+ sxNziW+0RJ98jhrQnhyvBvf6P2Txb5B/KM/1KUysiR0UcVa0r/ta/bPD1AEnOOSK a/bwju78zSohdrYpsCgJdlj5ccBDSiLtURNS9R/lYgBgU+IjcmkpBp0VKrrurnvF 579vCjoKo7eUx0SE9c8rb19RtbilrqItWrxe2laSGU5M8BWB35uPzGApbGEJNbmQ 7Em7SBkXzbwHuPDVDE7Qahh8bEAj8ExN8iUzaqa4THX+NrUVWWPahg+KvWdM0zPS LtOHjOP8PoIfzxVLC8Cw+pp1CBVqOTLjFgkEy9aFNecI50FtGKxoV3OZyRzhv0iv iRbsSQrMOlzfHVGZjtDBGrDygs/LDjMCgKJs9k9tjH9upHPDR34KA1KVhrrz985y PKEBOW+El9tbCwKGOJ5WVGWDR/+fo3BCb6C+zow0x2jLHXa4XQI4rQKcXBD5FM7M KAHX33yz8C0KqFkdVo79 =xIFE -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Default Local DNS Resolver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jan 2015 21:02:09 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 13.01.2015 um 20:56 schrieb William B: Unbound creates more flakiness than it solves. Unbound caches no answer as a negative cache entry. If your wireless blips for an instant, that's it, result vanishes simply not true there is a *huge* difference between a NXDOMAIN response and not reaching the NS, that said from somebody managing DNS and mail for some hundret domains over many years That is the case, but unbound certainly likes to cache no response in it's negative cache in my experience. It treats them as equivalent. - -- Sincerely, William Brown -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUtYJ+AAoJEO/EFteBqAmaEHEP/1xrnJoJgASCYNwByrYdyXU7 8lBYoZp4Cr9+oJXb/GuQqx+y9Dr4zWt8phQjg/osAYSLwTfbrD+2LxdGbPYWhv75 kBM09EEjEY85OwmU2dsdFNCcQ6ZHuybKmTvaWjo9eAsxQcLsD8Ksa7NcLV/DthqO STHTyz+TPA9HjP4uFnRcYy123bhVnUDFYpiUUBkuiF9Nidz3QxT6gvK7aqB5cRqy ib+CVGuPY5ahhNtXB0khpo+0tsetZ++9zIeh9XoVP6c2lNaK+eNHPb7Ef7Lhq2Ca qwXOrmsXWUhJMoTaRBUrCbpjw425WssIYwK6eZawpF6RTRwZhZLYTRiYSU8gBvyN ODoQ5rLHzZJ1Tw6eDFYLBG5o3smSMgUo4U41HEmNe87EtzPA1o1G0y+0BrORz28q q5hjdj9ynxIuBeyUybC4JHSiBfzC+z6nqv5FLC8GzJ8BxbDJfBJOdzwIZl3Mexhv qpNsI31g8ehxfPM6mQqyfMrd6Xkf1vPjBWhckmFUkLx/uPGfY/qIm76YK6sXRni1 Ck6lckpX70vPkw/wnj1m5qAu6MuZ3KkdRYxhNWhhfYOhwKbJ67GtM+iMGhQxt/Uq z4q62ZA/1YZOzSX25xxOIB7iOO+3U2uVoQGsekvTivGOZ4gGmRTu/1dj5DSS79lU TMpxq/+dHQGNm1aYkgqR =9QZk -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 09 Dec 2014 10:08:06 +0100 Nikos Mavrogiannopoulos n...@redhat.com wrote: On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better. Can you personally, with 100% confidence tell me you completely understand the inner workings and firewall of your home? Your work? Have you pen tested them? Are you sure that they are open in some way you don't expect? If you answer no to any of these, you should probably reconsider how open your systems firewall is. I think that sacrificing security for convinence is not an option. Sometimes security can be hard, and the convinence look nice, but I want to strongly reiterate that the solution is not to open all ports and fool our users, but to create a secure by default os, that gives users control of that. If that means we need to face the hard truths and write some code to make a better firewalld ui, then so be it. - -- Sincerely, William Brown -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUhvTSAAoJEO/EFteBqAmal44QAL3P0aVXGwoFzJbqpJI6EVjQ QvCHacmmgPpaCo0gs71SUdDWt0ku53ywCdPBatnEo/umLHCwRqS2UrgodGONnx8r bCAeyt6VADoxu50cYIQ/k/eHLz54fkr/QlkUq31wGzgM47lHASYpOmenIYHepCTD uEjt3SOeByPWyvoa5WOuKe7NkixvOutazYVhSqZvsPkgYaDqwzDi/MMP1ClMVNtm m5E4h0WYbiYVYmIvbkbfu60s12/jnVhfvMdyYSA3ZdGenjuz413EYTxpCtaLpyci om4YSN9D18vDGWrUMNeX56r2p1u3ZvL+a+fFRtWE7cJq4tEG8ix4/sr3wpR1JtPg xsU6+PdPW9RMGcbeeQ5BHc5w1SB6fWQvhEkx3XeLaeD5htEq3c+FqVaSlo8yQDMj /1x8QMwVDVmlbeA8vkvcwAsdO5jRok/R57Rj7r076v3laQp4QCVf9dURHuJ95pCP m3Ln2TguVOohV6jtMPtvCrqJQ1C1VUeSkCWTPo9kW4PgiN4O8w0EbBjB6M9B4GZB 0GjrKVJx4SPRK5sJfSL9HFSYEqvvudmGcij8swjjKldiVd/t4Y1bHyY7z4j2TvVp uNoN3/eZDR5rbkvlcBwoT82NStzpLEpPBIw3Znw7g2gp8jQLH5Xt7XM7Pa30v2Iv ZvR2kTt08xqjGzXeLYUi =6dr/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If by opening up some ports that would have hampered the user, rather than protect them[1], we avoid the users disabling the firewall, and exposing security critical services (such as exposing rpcbind, or ntpd, or any other root service), then it's a win for me. [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. Arm flailing looks more like this: Err mah gosh, dey touck ourz firewallz away, how's will I be totes secure now? I am not arm flailing. I have provided some logical examples of why this is bad: * Exploited applications are now more easily able to communicate back to CC systems. Most applications are not sandboxed, and even if they were, this sandboxing is not an excuse to open up other parts of the system. * In some circumstances the impact may be wider than the local network especially when you consideripv6. * The reason for this choice seems to stem from resistance to creating a UI that asks users for their permission. * You cannot make any assumptions about the client software a user will run or about wheter it is secure, no as in does it use SSL, but as in does it have remote exploits or other issues?. What if rhythmbox has an RCE? What about pidgin? Evolution? * Users are intentionally decived. When they look they will see firewall is active without realising that it practically amounts to open. We are taking control away from our users. * This very loose firewall policy appears to fly directly in the face of the FESCO descision that disallowed you from disabling the firewall. You may as well have disabled it with the policy that is in place now. Right now however, I believe that this issue will not be sorted on the mailing list. You Bastien have bunkered down and are defending this as much as possible, and I do not believe you are willing to have a discussion about this matter. At this stage the only way to move forward is to raise a critically rated bugzilla security issue within fedora, or to create a FESCO ticket. https://bugzilla.redhat.com/show_bug.cgi?id=1172353 I have used some of my points from above in this ticket. - -- Sincerely, William Brown -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUh20aAAoJEO/EFteBqAmafnUQAJmAT3ri9WcgwQq2EUQ5H2Mp sMCPHPrn89cBmQMgw4lCl+028u3pq+EErYBj1v0yLqh/BMWBRlfeCxJ/KDwfoPXG 8BUbDzPnphZRfcEpYdRbyQldob/IiQfG6gbC83OXgPCgvYwyCLNwqpsPoonGlefl Irg21TnQiSannOOz8k2VbagEMeql67srtMN2ZhKJYA+AEDDJf99a6Qa3JrUM9OXN 7xLeB57lO0FQqbUCsflpmiQx6w4sYc9caDiZQZZvoXC8IKTnXybSmj19R9/jbPBu bXmWYo40f74Wai0NE0R6JZtQ6z6otiTYM6VEg6dpJUopZzZfdTJSL/lkHWEn2WK7 u6otx3+BK8gizW4w0enT7AdJNEf3uPOgRP78k7c4eK107vfnWZsJB4Y7O84Vnw6E HneEwqbW/h1hGPhbw5Mkg5/Jzhz13So4qFOo1H1kxrmepk/7gxY6kW1/jL97Zp2i N5UE+ebR/Tpfm6cS1mgtgJlPVeHDASBQAK7Wm0oEQIJPSzJ/K5BKIY1/pzwdnzes TSPQ9oMR2Ib/gSYkETPEv3MDHz1tmEymtAozfFz+bPCNzCjsC9C5M6421SPqjNVR ZDoHnvuROgGaXSCH9BGSetCxPMNgowZsRznrpL1Vj4sKfkk+QKZo+Icu0lTJIl8f qqhv1h0stjrlejAMQSvY =gj17 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. There are no services listening on upper ports enabled by default, all the sharing services in Fedora will require actual enabling. See: http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html Yes, but it only takes one service to be open to cause issues. Things like pidgin are walking swiss cheese and once you get owned, the attacker has a choice of around 60,000 or more ports to choose from to open a reverse shell up on. I hope that this shows in summary that this idea is bad. As both a home user and enterprise user of fedora, I cannot accept that this is a default in a workstation product that will one day be used by students and the like. The worst part is not as much that the ports are open, but by the deception that a user who investigates will see The firewall is turned on, therefore I have security on incoming traffic. This is a lie with this configuration. The true crux of this issue is the over complexity that firewalld has brought to fedora, and the fact that a quality UI for managing it does not exist yet. OSX solves this issue by having an on or off button, and a list of applications that are allowed access. When the application first requests access, a prompt is given to add the application to the allow list. Why are we so against such a UI? - -- Sincerely, William Brown -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUhp3JAAoJEO/EFteBqAmaduEP/3Y01L7jUgo0OljnS2pQVUUn jdYbfUBchuPMO3sOEV7aryzMiKxtVE24vLklD7yN2O7VC+5KEVN29VyjiAI73IeH A3llYnDiGBzcx4EYorNH39PQuolsvplYFvNYz+WrreccYbWnyAr79bVUSBHYSA4C vSz3k2jFcl7TB3MozV5tV2OThv/7fKSEeYQwOVGaCRE4wnwedwu/mbaqQMd1QlJf AN7BVvvNU+oYBFpNPcL0RTKR2cXwoQWT66Yb+GPVnYbgLYpPqVTumPZACtlo1ltu IVW/pLBd2porYXM8gRfFovEwUv2LfOJOHapesz3iaGmt1DCk7dxNm6T2Mg08HPD4 rGgPAfU5awer/jTCwpjkydZe2JvzVm+BrpvYxAG61mHpRh7Cve8lYzbo14E54gVI NYT+TjHvlxFiTwONYMNkOxP88G7UlKmzWXKJRFLYeh5x6TB3pm8HPUjEkeEdfD6V ES/4DF2OmST6YanIJ0QMNEwB2xK+nNOP6EPCm9HofI1TeoxnyvWqgX2j5saWgPbi pkN5KrvL8M2xecXG7ZgSTyDyvrhUJlE0T8M+yf4T8+Q+FiY9wX7ug0cxmPgCf4UB wIZPIAtqjgD8wYDTcNjjXhN8e9Ytckvyk2YjUNX4uUG3R8NZUUJptJuyXHBkct9x sJkYBC+bun9YprSqgWkF =H8FB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
