Re: [PATCH 00/12] One more attempt at useful kernel lockdown

David Lang
2013-09-09T20:10:36Z

On Mon, 9 Sep 2013, Josh Boyer wrote:

> On Mon, Sep 9, 2013 at 3:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 09/09/2013 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
>>> On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said:
>>>
>>>> Given that we know that people want signed binaries without
>>>> blocking kexec, you should have '1' just enforce module signing
>>>> and '2' (or higher) implement a full lockdown including kexec.
>>>
>>>> Or, eliminate the -1 permanently insecure option and make this a
>>>> bitmask, if someone wants to enable every possible lockdown, have
>>>> them set it to "all 1's", define the bits only as you need them.
>>>
>>> This strikes me as much more workable than one big sledgehammer.
>>>
>>
>> I.e. capabilities ;)
>
> Circles. All I see here are circles.

the thing is that these are not circles. they are separate orthoginal things
that you may or may not want to allow.

If this was a simple set of circles, then this could be defined as a vector
instead of bitmap, the further you go the more secure you are.

But there are always going to be cases where you want to keep most of the
lockdown, but relax just one specific aspect of it, so you want it to be a
bitmap instead nested circles.

Now, I know that some people are going to argue that if you relax one portion
you have a hole in your secureity so it's not worth having any security at all.
but I've been doing security for banks for the last 16 years and I can say that
security is not a binary thing, just because there is one hole it isn't
worthless to close another one. Attackers are not omnificent, they don't know
everything there is to know about your system. If you block some holes you will
make those attaches worthless. some holes you need to leave open to avoid
breaking the business, and you either mitigate the risk in other ways (as
discussed in this thread, by only loading modules from media that was tested to
be intact, even if they aren't signed), or you accept that risk and factor the
cost of cleanup into your cusiness plans.

David Lang

> Having lived an entire release with a capabilities based mechanism for
> this in Fedora, please no.
>
> And if you are talking about non-POSIX capabilities as you mentioned
> earlier, that seems to be no different than having securelevel being a
> bitmask of, well, levels. I don't have much opinion on securelevel
> being a big hammer or a bitmask of finer grained things, but I do
> think it's a more manageable way forward. Calling the implementation
> "capabilities" seems to just be unnecessarily confusing.
>
> josh
>