Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758272Ab3CTQtl (ORCPT ); Wed, 20 Mar 2013 12:49:41 -0400 Received: from mail-db8lp0187.outbound.messaging.microsoft.com ([213.199.154.187]:35008 "EHLO db8outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751207Ab3CTQtk (ORCPT ); Wed, 20 Mar 2013 12:49:40 -0400 X-Forefront-Antispam-Report: CIP:157.56.236.101;KIP:(null);UIP:(null);IPV:NLI;H:BY2PRD0510HT004.namprd05.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz98dI936eIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dhz2fh2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) From: Matthew Garrett To: Mimi Zohar CC: James Morris , "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-efi@vger.kernel.org" , "kexec@lists.infradead.org" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Thread-Topic: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Thread-Index: AQHOJCAqmvU0usyXI0yxxCAslUbX+ZiscZuAgAJZ0ICAAAIXAA== Date: Wed, 20 Mar 2013 16:49:26 +0000 Message-ID: <1363798166.2553.29.camel@x230.sbx07502.somerma.wayport.net> References: <1363642353-30749-1-git-send-email-matthew.garrett@nebula.com> <1363797717.2580.10.camel@falcor1.watson.ibm.com> In-Reply-To: <1363797717.2580.10.camel@falcor1.watson.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.84.4] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: nebula.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id r2KGne1a001097 Content-Length: 666 Lines: 14 On Wed, 2013-03-20 at 12:41 -0400, Mimi Zohar wrote: > Matthrew, perhaps you could clarify whether this will be tied to MAC > security. Based on the kexec thread, I'm under the impression that is > not the intention, or at least not for kexec. As root isn't trusted, > neither is the boot command line, nor any policy that is loaded by root, > including those for MAC. The work done on signed initramfs fragments would seem to be the best option here so far? -- Matthew Garrett | mjg59@srcf.ucam.org ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?