From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932549Ab3BMSqD (ORCPT <rfc822;w@1wt.eu>);
	Wed, 13 Feb 2013 13:46:03 -0500
Received: from terminus.zytor.com ([198.137.202.10]:43030 "EHLO mail.zytor.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757122Ab3BMSp7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 13 Feb 2013 13:45:59 -0500
Message-ID: <511BDF0F.2000005@zytor.com>
Date: Wed, 13 Feb 2013 10:44:31 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
MIME-Version: 1.0
To: Matthew Garrett <matthew.garrett@nebula.com>
CC: Casey Schaufler <casey@schaufler-ca.com>, Borislav Petkov <bp@alien8.de>,
        Kees Cook <keescook@chromium.org>, LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
        linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot
References: <dee64752-850c-4d78-b703-f47a985bc13e@email.android.com>       <CAGXu5jLAufTRm=sDST0br_WEkn4o0Hpjv2jDP2Na=cCvuM+MGg@mail.gmail.com>       <1360355671.18083.18.camel@x230.lan>       <CAGXu5jKo2PfMBO4A0ZgQcrPuj8OHNaff+CjAesOAWkZc0vB9+Q@mail.gmail.com>       <51157C9C.6030501@zytor.com> <20130208230655.GB28990@pd.tnic>       <1360366012.18083.21.camel@x230.lan> <5115A4CC.3080102@zytor.com>       <1360373383.18083.23.camel@x230.lan>       <CAGXu5j+xvJ3L5ejxtZ-Jw3F6rV7OsrE0_HZCGu_er0rH2_PwKA@mail.gmail.com>       <20130209092925.GA17728@pd.tnic> <1360422712.18083.24.camel@x230.lan>      <511AE2CC.5040705@zytor.com> <1360733962.18083.30.camel@x230.lan>     <511B2EB9.5070406@zytor.com> <1360736860.18083.33.camel@x230.lan>    <511B33BC.9080307@zytor.com> <1360737709.18083.36.camel@x230.lan>   <511BCB6E.8080102@zytor.com> <1360776399.18083.39.camel@x230.lan>  <511BD291.1040003@schaufler-ca.com> <1360778179.18083.42.camel@x230.lan>
In-Reply-To: <1360778179.18083.42.camel@x230.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 02/13/2013 09:56 AM, Matthew Garrett wrote:
> On Wed, 2013-02-13 at 09:51 -0800, Casey Schaufler wrote:
>> On 2/13/2013 9:26 AM, Matthew Garrett wrote:
>>> Admit that CAP_SYS_RAWIO is fucked up beyond rescue. Add a new
>>> capability with well-defined semantics.
>>
>> You can't add a new capability where there is an existing capability
>> that can be remotely argued to be appropriate.
>
> CAP_SYS_RAWIO can't be argued to be appropriate. It covers a range of
> functionality that doesn't permit the running kernel to be modified and
> which is required to provide a functional Linux system. Using it would
> require redefining its existing usage, which would break existing
> userspace.
>

So people have piggybacked complete inappropriate junk onto 
CAP_SYS_RAWIO.  Great.  What the hell do we do now?  We can't break 
apart CAP_SYS_RAWIO because we don't have hierarchical capabilities.

We thus have a bunch of unpalatable choices, **all of which are wrong**.

This, incidentally, is *exactly* the reason I object to 
CAP_COMPROMISE_KERNEL as well... it describes a usage model, not a resource.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.