linux-kernel - Re: Trusted kernel patchset for Secure Boot lockdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140315001542.769cff6c@alan.etchedpixels.co.uk>
Date:	Sat, 15 Mar 2014 00:15:42 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"jwboyer@...oraproject.org" <jwboyer@...oraproject.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown

> So as far as the narrow question of whether we should accept these
> patches, I think it's a good thing.  Personally, I'm always going to
> be disabling UEFI secure boot (even if it doesn't brick my laptop),
> because for me, the security guarantees it provides isn't worth it.
> But there will be people who want to be able to install Linux on
> Windows 8 certified PC's without tweaking BIOS settings, so merging
> the UEFI secure boot is a good thing, so long as those of use who
> don't want to have anything to do with UEFI secure boot can disable
> it.

I definitely think we want the feature and there are a lot of non UEFI
reasons for this (eg running trusted_kernel() virtual namespaces). I have
three specific issues

1. The implementation is a mess in part because it propogates more policy
all over the place that should be separated. Root cause capable() mixes
policy and activity. Fix suggested in my previous emails (and offer to do
the work)

2. It's likely to lead to more bugs and errors because of the way it has
been done and it doesn't break old code that gets added without
considering the issue. It fails insecure which is bad. Fixed by doing
what I suggested (and offered to do)

3. For things like module options we should be white not blacklisting
'bad' ones.

I've offered to go and fix up the capability stuff - I'm just waiting for
Matthew to actually confirm the question I specifically asked him - does
this solve that bit of his problem. If it does great, I'll go and sort
the capability bits out so we can keep the policy in the right place and
we don't have the kernel festooned with && !trusted_kernel() everywhere.

There is a question of completeness but its very clear we get there with
a combination of two things - whitelisting so we catch stuff we missed
rather than leave holes, and just accepting the reality that it'll take a
few kernels once its upstream until we get them all.

I care about security, we should do the job properly. We have a
further magnitude shift in security needs coming that's going to be at
least equivalent to the scale of shift between the old 'university,
everyone is nice' internet and today.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/