[ Note: I have reordered the quoted text blocks. ] On 1/29/20 8:28 AM, Marvin Renich wrote: > On the other hand, I do agree with using unstable and testing to > determine the level of disruption, on the condition that there is a > _commitment_ to removing the feature before stable release if the > impact on usability is more than minor.
+1 I don't think we're that far apart here. There are plenty of shades of grey in this, and what counts as "minimal", "medium", or "massive" is going to be at least somewhat subjective. > Even medium disruption is the > wrong balance for a general distribution's default. I'm willing to go a bit further than you, as I would take (again, my subjective) "medium" disruption for a real security win, generally speaking. > I would like to give big kudos to the AppArmor team for providing > Debian developers and users with an exemplary experience while adding > a security feature as a distribution default. +1 AppArmor had the potential to cause massive breakage, and has not, primarily due to it being opt-in. I think this has been a big success. I would characterize AppArmor as being on the low end of "medium" breakage. AppArmor is something that I need to care about on an on-going basis as a sysadmin. I need to be aware it exists, how its problems will manifest, how to debug it, and how to fix it. I can't completely ignore it, as it does break things from time to time. This is not to say it breaks things out-of-the-blue. It breaks things when I change configurations away from the default. That's totally fine. I figure it out and go add the appropriate bit to the local/tunable file. Something minimally disruptive would be something like Address Space Layout Randomization (ASLR). While that may have impacts on maintainers enabling/disabling compiler flags, it is not something I ever have to think about as a sysadmin. It is never the problem. I never need to do anything related to it (as a sysadmin). Something like SELinux in the RedHat world is probably still at least on the high end of "medium" these days and could probably be characterized as "massive breakage" in its early days. "Massive breakage" is the sort of thing where large numbers of experienced sysadmins respond with "just turn it off". With what I know about this particular change right now, my assumption is that it will cause little to no breakage. I would characterize the expected impact as "minor". Further, I expect that any breakage will be "one-time" breakage that can be addressed by application developers and/or package maintainers, and it will not cause on-going work for system administrators. > > Unless massive breakage is expected, the default should > > be the most secure option. > The above > statement implies that the default should be the maximum security that > does _not_ cause _maximum_ disruption. I'd say that "massive breakage" (breaking lots of things) is not the same as "maximal disruption" (the most disruption). Maximum disruption would be, for example, breaking things that were "fully correct" (not doing something "dodgy") before the change. This would be a "flag day" change. That level of disruption needs to be avoided if at all possible, and carefully managed if completely unavoidable and worth the pain. > Time and time again I see security expert "wannabes" pushing for the > most security possible. Even real experts sometimes lose sight of the > balance between usability and security. Unfortunately, there are a lot > more "wannabes" than real experts, and the "wannabes" are typically much > more vocal. While I understand your point, I think it would be better to focus on the arguments rather than the people making them. -- Richard
signature.asc
Description: OpenPGP digital signature
