[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Adding security features (was: Kernel parameters protecting fifos and regular files)
From:       Richard Laager <rlaager () wiktel ! com>
Date:       2020-01-30 0:04:34
Message-ID: ba2a3d71-aa5d-997b-f4c6-da216a941487 () wiktel ! com
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


[ 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" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]