On Wed, Dec 10, 2014 at 08:13:54AM +1030, William B wrote: > * Exploited applications are now more easily able to communicate back > to C&C 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. Note that we weren't blocking _outgoing_ connections before. > * The reason for this choice seems to stem from resistance to > creating a UI that asks users for their permission. I think this is a misconception (not in an adversarial way; I think that there's a communication breakdown that's part of what's causing people to talk past each other). This is harder than it seems for technical reasons, and very hard to get right for user interaction reasons in a way that provides real security. If someone wants to work on this problem, _awesome_. > * 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. "Intentionally deceived" ascribes malicious intent where clearly none is intented. That's not helpful. Additionally, the argument that we are taking control away from our users does not follow even if that were true. > * 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. And this is *definitely* a misconception. The change proposal was rejected with the note "ask the proposal owners to work with firewalld developers and reframe proposal based around current contingency plan" approved by FESCo (+5, -1), and the "current contingency plan" as described was to use the "home" zone — which is similar to the way it ended up. > 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 This isn't a packaging issue so the best place to take this to would be back to FESCo, asking us to reconsider the earlier decision. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
