| 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
| ||
|
Date: Fri, 14 Mar 2014 15:58:02 +0000 From: Matthew Garrett <matthew.garrett@...ula.com> To: "keescook@...omium.org" <keescook@...omium.org> CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "jmorris@...ei.org" <jmorris@...ei.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>, "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>, "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 On Fri, 2014-03-14 at 08:54 -0700, Kees Cook wrote: > All the more reason to ignore command line at this point. For Chrome > OS, it's part of our boot state, so we don't care about it. For > generic Secure Boot, we can add checks for dangerous stuff as we go > forward. That's why I like this interface -- we can add to it as we > identify bad stuff, and it stay separate from other semantics. Sure, it's just another reason not to want to use a capability-based interface - not all the policy we want to impose is related to processes, so capabilities really don't make sense. The current patchset adds a restriction to the acpi_rsdp argument, and I've no objection to adding one to limit the use of mem=. -- Matthew Garrett <matthew.garrett@...ula.com>
Powered by blists - more mailing lists