linux-kernel - Re: [PATCH] x86: Lock down MSR writing in secure boot

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: <CA+5PVA4EbgBRgg+ZDa4+vG0Ngw8wJ3kH6NcmDvZ=+CP=kH82_A@mail.gmail.com>
Date:	Fri, 8 Feb 2013 16:14:07 -0500
From:	Josh Boyer <jwboyer@...il.com>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	Kees Cook <keescook@...omium.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot

On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett
<matthew.garrett@...ula.com> wrote:
> On Fri, 2013-02-08 at 13:02 -0800, Kees Cook wrote:
>
>> I don't find it unreasonable to drop all caps and lose access to
>> sensitive things. :) That's sort of the point, really. I think a cap
>> is the best match. It seems like it should either be a cap or a
>> namespace flag, but the latter seems messy.
>
> Yeah, I think it's an expected outcome, but it means that if (say) qemu
> drops privileges, qemu can no longer access PCI resources - even on
> non-secure boot systems. That breaks existing userspace.

Right.  We've had a few reports in Fedora of things breaking on non-SB
systems because of this.  The qemu one is the latest, but the general
problem is people think dropping all caps blindly is making their apps
safer.  Then they find they can't do things they could do before the new
cap was added.  It's messy.

I've thought of treating CAP_COMPROMISE_KERNEL as a hidden cap, where
only the kernel can grant or drop it.  Peter Jones suggested it might
work to allow it to be dropped iff it is the only cap being changed.
Either way, it's a "special" cap and I have no idea how acceptable
something like that would be.

Really though, the main issue is that you cannot introduce new caps to
enforce finer grained access without breaking something.

josh
--
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/