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: <5115859F.8070805@amacapital.net>
Date:	Fri, 08 Feb 2013 15:09:19 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	jwboyer@...il.com
CC:	Matthew Garrett <mjg@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, x86@...nel.org,
	linux-efi@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot

On 02/08/2013 01:14 PM, Josh Boyer wrote:
> On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett
> <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@...lic.gmane.org> 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.

Why not require CAP_COMPROMISE_KERNEL to open (with O_RDWR or O_WRONLY)
/dev/msr?  After all, sudo </dev/null >/dev/msr will cause a privileged
write() call on the fd as long as the capability is in your bounding set.

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