Adding security features (was: Kernel parameters protecting fifos and regular files)
I have no opinion about this specific feature; at first glance it looks
like it might be a reasonable thing to do. On the other hand, I
strongly disagree with this statement as a general rule:
> Unless massive breakage is expected, the default should
> be the most secure option.
This is the wrong way around. In a general distribution, the default
should be to use the maximum amount of security that can reasonably be
expected to cause _minimal_ disruption to usability. The above
statement implies that the default should be the maximum security that
does _not_ cause _maximum_ disruption. (Even medium disruption is the
wrong balance for a general distribution's default.)
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.
If you change "Unless massive breakage is expected" to "If breakage is
expected to be minimal", than I would agree.
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.
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. I think the rollout went so
smoothly that the AppArmor team did not get enough attention for the
terrific job they did. That transition should be held up as a model for
implementing any big feature change in Debian.
...Marvin
Reply to: