* [PATCH] x86: Lock down MSR writing in secure boot @ 2013-02-08 19:12 Kees Cook 2013-02-08 19:17 ` H. Peter Anvin 2013-02-08 19:17 ` Matthew Garrett 0 siblings, 2 replies; 49+ messages in thread From: Kees Cook @ 2013-02-08 19:12 UTC (permalink / raw) To: linux-kernel Cc: Matthew Garrett, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is set since it could lead to execution of arbitrary code in kernel mode. Signed-off-by: Kees Cook <keescook@chromium.org> --- This would be used on top of Matthew Garrett's existing "Secure boot policy support" patch series. --- arch/x86/kernel/msr.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c index 4929502..adaab3d 100644 --- a/arch/x86/kernel/msr.c +++ b/arch/x86/kernel/msr.c @@ -103,6 +103,9 @@ static ssize_t msr_write(struct file *file, const char __user *buf, int err = 0; ssize_t bytes = 0; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (count % 8) return -EINVAL; /* Invalid chunk size */ @@ -150,6 +153,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg) err = -EBADF; break; } + if (!capable(CAP_COMPROMISE_KERNEL)) { + err = -EPERM; + break; + } if (copy_from_user(®s, uregs, sizeof regs)) { err = -EFAULT; break; -- 1.7.9.5 -- Kees Cook Chrome OS Security ^ permalink raw reply related [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:12 [PATCH] x86: Lock down MSR writing in secure boot Kees Cook @ 2013-02-08 19:17 ` H. Peter Anvin 2013-02-08 19:18 ` Kees Cook 2013-02-08 19:17 ` Matthew Garrett 1 sibling, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-08 19:17 UTC (permalink / raw) To: Kees Cook, linux-kernel Cc: Matthew Garrett, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module We already have CAP_RAWIO for this in mainline; I am not sure if this should be harder than that... Kees Cook <keescook@chromium.org> wrote: >Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is >set since it could lead to execution of arbitrary code in kernel mode. > >Signed-off-by: Kees Cook <keescook@chromium.org> >--- >This would be used on top of Matthew Garrett's existing "Secure boot >policy support" patch series. >--- > arch/x86/kernel/msr.c | 7 +++++++ > 1 file changed, 7 insertions(+) > >diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c >index 4929502..adaab3d 100644 >--- a/arch/x86/kernel/msr.c >+++ b/arch/x86/kernel/msr.c >@@ -103,6 +103,9 @@ static ssize_t msr_write(struct file *file, const >char __user *buf, > int err = 0; > ssize_t bytes = 0; > >+ if (!capable(CAP_COMPROMISE_KERNEL)) >+ return -EPERM; >+ > if (count % 8) > return -EINVAL; /* Invalid chunk size */ > >@@ -150,6 +153,10 @@ static long msr_ioctl(struct file *file, unsigned >int ioc, unsigned long arg) > err = -EBADF; > break; > } >+ if (!capable(CAP_COMPROMISE_KERNEL)) { >+ err = -EPERM; >+ break; >+ } > if (copy_from_user(®s, uregs, sizeof regs)) { > err = -EFAULT; > break; -- Sent from my mobile phone. Please excuse brevity and lack of formatting. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:17 ` H. Peter Anvin @ 2013-02-08 19:18 ` Kees Cook 2013-02-08 19:42 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Kees Cook @ 2013-02-08 19:18 UTC (permalink / raw) To: H. Peter Anvin Cc: LKML, Matthew Garrett, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module No. CAP_RAWIO is for reading. Writing needs a much stronger check. -Kees On Fri, Feb 8, 2013 at 11:17 AM, H. Peter Anvin <hpa@zytor.com> wrote: > We already have CAP_RAWIO for this in mainline; I am not sure if this should be harder than that... > > Kees Cook <keescook@chromium.org> wrote: > >>Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is >>set since it could lead to execution of arbitrary code in kernel mode. >> >>Signed-off-by: Kees Cook <keescook@chromium.org> >>--- >>This would be used on top of Matthew Garrett's existing "Secure boot >>policy support" patch series. >>--- >> arch/x86/kernel/msr.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >>diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c >>index 4929502..adaab3d 100644 >>--- a/arch/x86/kernel/msr.c >>+++ b/arch/x86/kernel/msr.c >>@@ -103,6 +103,9 @@ static ssize_t msr_write(struct file *file, const >>char __user *buf, >> int err = 0; >> ssize_t bytes = 0; >> >>+ if (!capable(CAP_COMPROMISE_KERNEL)) >>+ return -EPERM; >>+ >> if (count % 8) >> return -EINVAL; /* Invalid chunk size */ >> >>@@ -150,6 +153,10 @@ static long msr_ioctl(struct file *file, unsigned >>int ioc, unsigned long arg) >> err = -EBADF; >> break; >> } >>+ if (!capable(CAP_COMPROMISE_KERNEL)) { >>+ err = -EPERM; >>+ break; >>+ } >> if (copy_from_user(®s, uregs, sizeof regs)) { >> err = -EFAULT; >> break; > > -- > Sent from my mobile phone. Please excuse brevity and lack of formatting. -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:18 ` Kees Cook @ 2013-02-08 19:42 ` H. Peter Anvin 2013-02-08 20:14 ` Kees Cook 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-08 19:42 UTC (permalink / raw) To: Kees Cook Cc: LKML, Matthew Garrett, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/08/2013 11:18 AM, Kees Cook wrote: > No. CAP_RAWIO is for reading. Writing needs a much stronger check. > > -Kees If so, I suspect we need to do this for *all* raw I/O... but I keep wondering how much more sensitive writing really is than reading. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:42 ` H. Peter Anvin @ 2013-02-08 20:14 ` Kees Cook 2013-02-08 20:18 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Kees Cook @ 2013-02-08 20:14 UTC (permalink / raw) To: H. Peter Anvin Cc: LKML, Matthew Garrett, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin <hpa@zytor.com> wrote: > On 02/08/2013 11:18 AM, Kees Cook wrote: >> >> No. CAP_RAWIO is for reading. Writing needs a much stronger check. > > If so, I suspect we need to do this for *all* raw I/O... but I keep > wondering how much more sensitive writing really is than reading. Well, I think there's a reasonable distinction between systems that expect to strictly enforce user-space/kernel-space separation (CAP_COMPROMISE_KERNEL) and things that are fiddling with hardware (CAP_SYS_RAWIO). For example, even things like /dev/mem already have this separation (although it is stronger). You can't open /dev/mem without CAP_SYS_RAWIO, but if you do, you still can't write to RAM in /dev/mem. This might be one of the earliest examples of this distinction, actually. I think it's likely that after a while, we can convert some of these proposed CAP_COMPROMISE_KERNEL checks in always-deny once we figure out how to deal with those areas more safely. -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 20:14 ` Kees Cook @ 2013-02-08 20:18 ` H. Peter Anvin 2013-02-08 20:28 ` Kees Cook 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-08 20:18 UTC (permalink / raw) To: Kees Cook Cc: LKML, Matthew Garrett, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module Analogy fail. The /dev/mem lockout applies to system RAM, not MMIO. I fear COMPROMISE_KERNEL is becoming the new SYS_ADMIN, which in turn is the new root. Why? Because it is inhebtly about a usage model, not about a specific resource. Kees Cook <keescook@chromium.org> wrote: >On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin <hpa@zytor.com> wrote: >> On 02/08/2013 11:18 AM, Kees Cook wrote: >>> >>> No. CAP_RAWIO is for reading. Writing needs a much stronger check. >> >> If so, I suspect we need to do this for *all* raw I/O... but I keep >> wondering how much more sensitive writing really is than reading. > >Well, I think there's a reasonable distinction between systems that >expect to strictly enforce user-space/kernel-space separation >(CAP_COMPROMISE_KERNEL) and things that are fiddling with hardware >(CAP_SYS_RAWIO). > >For example, even things like /dev/mem already have this separation >(although it is stronger). You can't open /dev/mem without >CAP_SYS_RAWIO, but if you do, you still can't write to RAM in >/dev/mem. This might be one of the earliest examples of this >distinction, actually. > >I think it's likely that after a while, we can convert some of these >proposed CAP_COMPROMISE_KERNEL checks in always-deny once we figure >out how to deal with those areas more safely. > >-Kees > >-- >Kees Cook >Chrome OS Security -- Sent from my mobile phone. Please excuse brevity and lack of formatting. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 20:18 ` H. Peter Anvin @ 2013-02-08 20:28 ` Kees Cook 2013-02-08 20:34 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: Kees Cook @ 2013-02-08 20:28 UTC (permalink / raw) To: H. Peter Anvin Cc: LKML, Matthew Garrett, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 8, 2013 at 12:18 PM, H. Peter Anvin <hpa@zytor.com> wrote: > Analogy fail. The /dev/mem lockout applies to system RAM, not MMIO. Well, that's what I meant by it being "stronger". > I fear COMPROMISE_KERNEL is becoming the new SYS_ADMIN, which in turn is the new root. Why? Because it is inhebtly about a usage model, not about a specific resource. I can see where you're coming from, but I don't agree. Roughly speaking, uids should be about organization and filesystem DAC (uid 0 shouldn't be special). SYS_ADMIN is about broad-ranging configuration/resource access (generally still all in userspace). There hasn't been a strong distinction between user/kernel space for uid-0 just because it didn't seem valuable. But now it's clearer, and COMPROMISE_KERNEL can mark where these lines need to be drawn. Maybe a capability isn't the right way to go, I'm not sure. I'll leave that to Matthew. Whatever the flag, it should be an immutable state of the boot. Though, it probably makes sense as a cap just so that non-secure-boot systems can still remove it from containers, etc. -Kees > Kees Cook <keescook@chromium.org> wrote: > >>On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin <hpa@zytor.com> wrote: >>> On 02/08/2013 11:18 AM, Kees Cook wrote: >>>> >>>> No. CAP_RAWIO is for reading. Writing needs a much stronger check. >>> >>> If so, I suspect we need to do this for *all* raw I/O... but I keep >>> wondering how much more sensitive writing really is than reading. >> >>Well, I think there's a reasonable distinction between systems that >>expect to strictly enforce user-space/kernel-space separation >>(CAP_COMPROMISE_KERNEL) and things that are fiddling with hardware >>(CAP_SYS_RAWIO). >> >>For example, even things like /dev/mem already have this separation >>(although it is stronger). You can't open /dev/mem without >>CAP_SYS_RAWIO, but if you do, you still can't write to RAM in >>/dev/mem. This might be one of the earliest examples of this >>distinction, actually. >> >>I think it's likely that after a while, we can convert some of these >>proposed CAP_COMPROMISE_KERNEL checks in always-deny once we figure >>out how to deal with those areas more safely. >> >>-Kees >> >>-- >>Kees Cook >>Chrome OS Security > > -- > Sent from my mobile phone. Please excuse brevity and lack of formatting. -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 20:28 ` Kees Cook @ 2013-02-08 20:34 ` Matthew Garrett 2013-02-08 21:02 ` Kees Cook 0 siblings, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-08 20:34 UTC (permalink / raw) To: Kees Cook Cc: H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1039 bytes --] On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote: > Maybe a capability isn't the right way to go, I'm not sure. I'll leave > that to Matthew. Whatever the flag, it should be an immutable state of > the boot. Though, it probably makes sense as a cap just so that > non-secure-boot systems can still remove it from containers, etc. There was interest in ensuring that this wasn't something special-cased to UEFI Secure Boot, so using a capability seemed like the most straightforward way - it's fundamentally a restriction on what an otherwise privileged user is able to do, so it seemed like it fit the model. But I'm not wed to it in the slightest, and in fact it causes problems for some userspace (anything that drops all capabilities suddenly finds itself unable to do something that it expects to be able to do), so if anyone has any suggestions for a better approach… ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 20:34 ` Matthew Garrett @ 2013-02-08 21:02 ` Kees Cook 2013-02-08 21:07 ` Matthew Garrett 2013-02-08 22:30 ` H. Peter Anvin 0 siblings, 2 replies; 49+ messages in thread From: Kees Cook @ 2013-02-08 21:02 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett <matthew.garrett@nebula.com> wrote: > On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote: > >> Maybe a capability isn't the right way to go, I'm not sure. I'll leave >> that to Matthew. Whatever the flag, it should be an immutable state of >> the boot. Though, it probably makes sense as a cap just so that >> non-secure-boot systems can still remove it from containers, etc. > > There was interest in ensuring that this wasn't something special-cased > to UEFI Secure Boot, so using a capability seemed like the most > straightforward way - it's fundamentally a restriction on what an > otherwise privileged user is able to do, so it seemed like it fit the > model. But I'm not wed to it in the slightest, and in fact it causes > problems for some userspace (anything that drops all capabilities > suddenly finds itself unable to do something that it expects to be able > to do), so if anyone has any suggestions for a better approach… 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. -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 21:02 ` Kees Cook @ 2013-02-08 21:07 ` Matthew Garrett 2013-02-08 21:14 ` Josh Boyer 2013-02-08 22:30 ` H. Peter Anvin 1 sibling, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-08 21:07 UTC (permalink / raw) To: Kees Cook Cc: H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 661 bytes --] 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. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 21:07 ` Matthew Garrett @ 2013-02-08 21:14 ` Josh Boyer 2013-02-08 23:09 ` Andy Lutomirski 0 siblings, 1 reply; 49+ messages in thread From: Josh Boyer @ 2013-02-08 21:14 UTC (permalink / raw) To: Matthew Garrett Cc: Kees Cook, H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett <matthew.garrett@nebula.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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 21:14 ` Josh Boyer @ 2013-02-08 23:09 ` Andy Lutomirski 0 siblings, 0 replies; 49+ messages in thread From: Andy Lutomirski @ 2013-02-08 23:09 UTC (permalink / raw) To: jwboyer Cc: Matthew Garrett, Kees Cook, H. Peter Anvin, Linux Kernel Mailing List, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module 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@public.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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 21:02 ` Kees Cook 2013-02-08 21:07 ` Matthew Garrett @ 2013-02-08 22:30 ` H. Peter Anvin 2013-02-08 23:06 ` Borislav Petkov 1 sibling, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-08 22:30 UTC (permalink / raw) To: Kees Cook Cc: Matthew Garrett, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/08/2013 01:02 PM, Kees Cook wrote: > On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett > <matthew.garrett@nebula.com> wrote: >> On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote: >> >>> Maybe a capability isn't the right way to go, I'm not sure. I'll leave >>> that to Matthew. Whatever the flag, it should be an immutable state of >>> the boot. Though, it probably makes sense as a cap just so that >>> non-secure-boot systems can still remove it from containers, etc. >> >> There was interest in ensuring that this wasn't something special-cased >> to UEFI Secure Boot, so using a capability seemed like the most >> straightforward way - it's fundamentally a restriction on what an >> otherwise privileged user is able to do, so it seemed like it fit the >> model. But I'm not wed to it in the slightest, and in fact it causes >> problems for some userspace (anything that drops all capabilities >> suddenly finds itself unable to do something that it expects to be able >> to do), so if anyone has any suggestions for a better approach… > > 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. > Caps are fine; the problem is the "putting it all under one cap". The semi-problem here is that to preserve backwards compatibility we really should have a way to have hierarchical caps in Linux (which we currently don't), but it is not really an issue for this. Also, keep in mind that there is a very simple way to deny MSR access completely, which is to not include the driver in your kernel (and not allow module loading, but if you can load modules you can just load a module to muck with whatever MSR you want.) I am still wondering if there are any legitimate uses of CAP_RAWIO & ~CAP_COMPROMISE_KERNEL that can't be used to subvert the latter. I am not sure there are. -hpa ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 22:30 ` H. Peter Anvin @ 2013-02-08 23:06 ` Borislav Petkov 2013-02-08 23:26 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: Borislav Petkov @ 2013-02-08 23:06 UTC (permalink / raw) To: H. Peter Anvin Cc: Kees Cook, Matthew Garrett, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 08, 2013 at 02:30:52PM -0800, H. Peter Anvin wrote: > Also, keep in mind that there is a very simple way to deny MSR access > completely, which is to not include the driver in your kernel (and not > allow module loading, but if you can load modules you can just load a > module to muck with whatever MSR you want.) I was contemplating that too. What is the use case of having msr.ko in a secure boot environment? Isn't that an all-no-tools, you-can't-do-sh*t-except-what-you're-explicitly-allowed-to environment which simply doesn't need to write MSRs in the first place? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 23:06 ` Borislav Petkov @ 2013-02-08 23:26 ` Matthew Garrett 2013-02-09 1:22 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-08 23:26 UTC (permalink / raw) To: Borislav Petkov Cc: H. Peter Anvin, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 921 bytes --] On Sat, 2013-02-09 at 00:06 +0100, Borislav Petkov wrote: > On Fri, Feb 08, 2013 at 02:30:52PM -0800, H. Peter Anvin wrote: > > Also, keep in mind that there is a very simple way to deny MSR access > > completely, which is to not include the driver in your kernel (and not > > allow module loading, but if you can load modules you can just load a > > module to muck with whatever MSR you want.) > > I was contemplating that too. What is the use case of having > msr.ko in a secure boot environment? Isn't that an all-no-tools, > you-can't-do-sh*t-except-what-you're-explicitly-allowed-to environment which > simply doesn't need to write MSRs in the first place? Well, sure, distributions could build every kernel twice. That seems a little excessive, though. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 23:26 ` Matthew Garrett @ 2013-02-09 1:22 ` H. Peter Anvin 2013-02-09 1:29 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-09 1:22 UTC (permalink / raw) To: Matthew Garrett Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/08/2013 03:26 PM, Matthew Garrett wrote: > On Sat, 2013-02-09 at 00:06 +0100, Borislav Petkov wrote: >> On Fri, Feb 08, 2013 at 02:30:52PM -0800, H. Peter Anvin wrote: >>> Also, keep in mind that there is a very simple way to deny MSR access >>> completely, which is to not include the driver in your kernel (and not >>> allow module loading, but if you can load modules you can just load a >>> module to muck with whatever MSR you want.) >> >> I was contemplating that too. What is the use case of having >> msr.ko in a secure boot environment? Isn't that an all-no-tools, >> you-can't-do-sh*t-except-what-you're-explicitly-allowed-to environment which >> simply doesn't need to write MSRs in the first place? > > Well, sure, distributions could build every kernel twice. That seems a > little excessive, though. > You don't have to build the kernel twice to exclude a loadable module. -hpa ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-09 1:22 ` H. Peter Anvin @ 2013-02-09 1:29 ` Matthew Garrett 2013-02-09 6:45 ` Kees Cook 0 siblings, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-09 1:29 UTC (permalink / raw) To: H. Peter Anvin Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 436 bytes --] On Fri, 2013-02-08 at 17:22 -0800, H. Peter Anvin wrote: > You don't have to build the kernel twice to exclude a loadable module. I guess you could just strip the signatures off any modules you don't want to support under Secure Boot, but that breaks some other use cases. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-09 1:29 ` Matthew Garrett @ 2013-02-09 6:45 ` Kees Cook 2013-02-09 9:29 ` Borislav Petkov 0 siblings, 1 reply; 49+ messages in thread From: Kees Cook @ 2013-02-09 6:45 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, Borislav Petkov, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 8, 2013 at 5:29 PM, Matthew Garrett <matthew.garrett@nebula.com> wrote: > On Fri, 2013-02-08 at 17:22 -0800, H. Peter Anvin wrote: > >> You don't have to build the kernel twice to exclude a loadable module. > > I guess you could just strip the signatures off any modules you don't > want to support under Secure Boot, but that breaks some other use cases. Also, _reading_ MSRs from userspace arguably has utility that doesn't compromise ring-0. So excluding the driver entirely seems like overkill. -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-09 6:45 ` Kees Cook @ 2013-02-09 9:29 ` Borislav Petkov 2013-02-09 15:10 ` Kees Cook 2013-02-09 15:11 ` Matthew Garrett 0 siblings, 2 replies; 49+ messages in thread From: Borislav Petkov @ 2013-02-09 9:29 UTC (permalink / raw) To: Kees Cook Cc: Matthew Garrett, H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote: > Also, _reading_ MSRs from userspace arguably has utility that doesn't > compromise ring-0. And to come back to the original question: what is that utility, who would need it on a secure boot system and why? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-09 9:29 ` Borislav Petkov @ 2013-02-09 15:10 ` Kees Cook 2013-02-09 15:11 ` Matthew Garrett 1 sibling, 0 replies; 49+ messages in thread From: Kees Cook @ 2013-02-09 15:10 UTC (permalink / raw) To: Borislav Petkov, Kees Cook, Matthew Garrett, H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Sat, Feb 9, 2013 at 1:29 AM, Borislav Petkov <bp@alien8.de> wrote: > On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote: >> Also, _reading_ MSRs from userspace arguably has utility that doesn't >> compromise ring-0. > > And to come back to the original question: what is that utility, who > would need it on a secure boot system and why? I have used it for double-checking the state of VMX (is it disabled and locked), and for making sure that XD isn't masked, checking thermal stuff, etc. I'm not arguing to keep the MSR driver while in secure mode, mind you, I was just pointing out that like /dev/mem there could be some utility to keeping the read half around. That said, it could also be seen as an info leak. *shrug* My goal was just to make sure it wasn't writable in the secure boot mode. -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-09 9:29 ` Borislav Petkov 2013-02-09 15:10 ` Kees Cook @ 2013-02-09 15:11 ` Matthew Garrett 2013-02-13 0:48 ` H. Peter Anvin 1 sibling, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-09 15:11 UTC (permalink / raw) To: Borislav Petkov Cc: Kees Cook, H. Peter Anvin, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 603 bytes --] On Sat, 2013-02-09 at 10:29 +0100, Borislav Petkov wrote: > On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote: > > Also, _reading_ MSRs from userspace arguably has utility that doesn't > > compromise ring-0. > > And to come back to the original question: what is that utility, who > would need it on a secure boot system and why? Things like Turbostat are useful, although perhaps that information should be exposed in a better way. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-09 15:11 ` Matthew Garrett @ 2013-02-13 0:48 ` H. Peter Anvin 2013-02-13 5:39 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 0:48 UTC (permalink / raw) To: Matthew Garrett Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/09/2013 07:11 AM, Matthew Garrett wrote: > On Sat, 2013-02-09 at 10:29 +0100, Borislav Petkov wrote: >> On Fri, Feb 08, 2013 at 10:45:35PM -0800, Kees Cook wrote: >>> Also, _reading_ MSRs from userspace arguably has utility that doesn't >>> compromise ring-0. >> >> And to come back to the original question: what is that utility, who >> would need it on a secure boot system and why? > > Things like Turbostat are useful, although perhaps that information > should be exposed in a better way. > OK... what none of this gets into: Why should CAP_RAWIO be allowed on a secure boot system, when there are 2^n known ways of compromise a system with CAP_RAWIO? -hpa ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 0:48 ` H. Peter Anvin @ 2013-02-13 5:39 ` Matthew Garrett 2013-02-13 6:12 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-13 5:39 UTC (permalink / raw) To: H. Peter Anvin Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 832 bytes --] On Tue, 2013-02-12 at 16:48 -0800, H. Peter Anvin wrote: > OK... what none of this gets into: > > Why should CAP_RAWIO be allowed on a secure boot system, when there are > 2^n known ways of compromise a system with CAP_RAWIO? CAP_SYS_RAWIO seems to have ended up being a catchall of "Maybe someone who isn't entirely root should be able to do this", and not everything it covers is equivalent to being able to compromise the running kernel. I wouldn't argue with the idea that maybe we should just reappraise most of the current uses of CAP_SYS_RAWIO, but removing capability checks from places that currently have them seems like an invitation for userspace breakage. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 5:39 ` Matthew Garrett @ 2013-02-13 6:12 ` H. Peter Anvin 2013-02-13 6:27 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 6:12 UTC (permalink / raw) To: Matthew Garrett Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/12/2013 09:39 PM, Matthew Garrett wrote: > On Tue, 2013-02-12 at 16:48 -0800, H. Peter Anvin wrote: > >> OK... what none of this gets into: >> >> Why should CAP_RAWIO be allowed on a secure boot system, when there are >> 2^n known ways of compromise a system with CAP_RAWIO? > > CAP_SYS_RAWIO seems to have ended up being a catchall of "Maybe someone > who isn't entirely root should be able to do this", and not everything > it covers is equivalent to being able to compromise the running kernel. > I wouldn't argue with the idea that maybe we should just reappraise most > of the current uses of CAP_SYS_RAWIO, but removing capability checks > from places that currently have them seems like an invitation for > userspace breakage. > Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a huge difference between MSRs and I/O control registers... just different address spaces. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 6:12 ` H. Peter Anvin @ 2013-02-13 6:27 ` Matthew Garrett 2013-02-13 6:33 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-13 6:27 UTC (permalink / raw) To: H. Peter Anvin Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 606 bytes --] On Tue, 2013-02-12 at 22:12 -0800, H. Peter Anvin wrote: > Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a > huge difference between MSRs and I/O control registers... just different > address spaces. Not having CAP_SYS_RAWIO blocks various SCSI commands, for instance. These might result in the ability to write individual blocks or destroy the device firmware, but do any of them permit modifying the running kernel? ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 6:27 ` Matthew Garrett @ 2013-02-13 6:33 ` H. Peter Anvin 2013-02-13 6:41 ` Matthew Garrett 2013-02-13 8:27 ` Paolo Bonzini 0 siblings, 2 replies; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 6:33 UTC (permalink / raw) To: Matthew Garrett Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/12/2013 10:27 PM, Matthew Garrett wrote: > On Tue, 2013-02-12 at 22:12 -0800, H. Peter Anvin wrote: > >> Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a >> huge difference between MSRs and I/O control registers... just different >> address spaces. > > Not having CAP_SYS_RAWIO blocks various SCSI commands, for instance. > These might result in the ability to write individual blocks or destroy > the device firmware, but do any of them permit modifying the running > kernel? That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() which means you can reprogram your northbridge, at which point you most definitely *can* modify the running kernel. And some SCSI driver requires this??! -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 6:33 ` H. Peter Anvin @ 2013-02-13 6:41 ` Matthew Garrett 2013-02-13 17:20 ` H. Peter Anvin 2013-02-13 8:27 ` Paolo Bonzini 1 sibling, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-13 6:41 UTC (permalink / raw) To: H. Peter Anvin Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 860 bytes --] On Tue, 2013-02-12 at 22:33 -0800, H. Peter Anvin wrote: > That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() > which means you can reprogram your northbridge, at which point you most > definitely *can* modify the running kernel. Well right, that's the point of this patchset - it adds some extra permission checks to some of the existing CAP_SYS_RAWIO checks. CAP_SYS_RAWIO hasn't meant "I can perform arbitrary pio and mmio" for years - it means "I can do things that might maybe break something somehow". So sure, removing CAP_SYS_RAWIO would give us basically all the security we want in a secure boot environment, but it would also block things that we *want* to work. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 6:41 ` Matthew Garrett @ 2013-02-13 17:20 ` H. Peter Anvin 2013-02-13 17:26 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 17:20 UTC (permalink / raw) To: Matthew Garrett Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/12/2013 10:41 PM, Matthew Garrett wrote: > On Tue, 2013-02-12 at 22:33 -0800, H. Peter Anvin wrote: > >> That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() >> which means you can reprogram your northbridge, at which point you most >> definitely *can* modify the running kernel. > > Well right, that's the point of this patchset - it adds some extra > permission checks to some of the existing CAP_SYS_RAWIO checks. > CAP_SYS_RAWIO hasn't meant "I can perform arbitrary pio and mmio" for > years - it means "I can do things that might maybe break something > somehow". So sure, removing CAP_SYS_RAWIO would give us basically all > the security we want in a secure boot environment, but it would also > block things that we *want* to work. > So, let 's see... Problem: Someone adds SYS_CAP_RAWIO to some places it definitely does not belong. Solution: Break all the *appropriate* (as defined)uses of SYS_CAP_RAWIO? What the heck? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 17:20 ` H. Peter Anvin @ 2013-02-13 17:26 ` Matthew Garrett 2013-02-13 17:51 ` Casey Schaufler 0 siblings, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-13 17:26 UTC (permalink / raw) To: H. Peter Anvin Cc: Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 958 bytes --] On Wed, 2013-02-13 at 09:20 -0800, H. Peter Anvin wrote: > Problem: > > Someone adds SYS_CAP_RAWIO to some places it definitely does not > belong. > > Solution: > > Break all the *appropriate* (as defined)uses of SYS_CAP_RAWIO? Problem: CAP_SYS_RAWIO has been used in a bunch of arguably inappropriate places. Removing CAP_SYS_RAWIO from the set of possible capabilities on a system will prevent userspace from doing things that userspace should be permitted to do. Removing CAP_SYS_RAWIO from the places that it currently exists will allow userspace to do too much. Replacing CAP_SYS_RAWIO with CAP_SYS_ADMIN will prevent userspace from doing things that it can currently do. Solution: Admit that CAP_SYS_RAWIO is fucked up beyond rescue. Add a new capability with well-defined semantics. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 17:26 ` Matthew Garrett @ 2013-02-13 17:51 ` Casey Schaufler 2013-02-13 17:56 ` Matthew Garrett 2013-02-13 22:26 ` H. Peter Anvin 0 siblings, 2 replies; 49+ messages in thread From: Casey Schaufler @ 2013-02-13 17:51 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 2/13/2013 9:26 AM, Matthew Garrett wrote: > On Wed, 2013-02-13 at 09:20 -0800, H. Peter Anvin wrote: > >> Problem: >> >> Someone adds SYS_CAP_RAWIO to some places it definitely does not >> belong. >> >> Solution: >> >> Break all the *appropriate* (as defined)uses of SYS_CAP_RAWIO? > Problem: > > CAP_SYS_RAWIO has been used in a bunch of arguably inappropriate places. > Removing CAP_SYS_RAWIO from the set of possible capabilities on a system > will prevent userspace from doing things that userspace should be > permitted to do. Removing CAP_SYS_RAWIO from the places that it > currently exists will allow userspace to do too much. Replacing > CAP_SYS_RAWIO with CAP_SYS_ADMIN will prevent userspace from doing > things that it can currently do. > > Solution: > > 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. If you tried to "fix" CAP_SYS_RAWIO and/or CAP_SYS_ADMIN you'd end up with hundreds of capabilities. Your particular problem is *not* so important that you get a capability all to yourself. > N�����r��y���b�X��ǧv�^�){.n�+����{���.�+r��n�觶\x17��ܨ}���Ơz�&j:+v���\a����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[fl=== ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 17:51 ` Casey Schaufler @ 2013-02-13 17:56 ` Matthew Garrett 2013-02-13 18:44 ` H. Peter Anvin 2013-02-13 22:26 ` H. Peter Anvin 1 sibling, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-13 17:56 UTC (permalink / raw) To: Casey Schaufler Cc: H. Peter Anvin, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 833 bytes --] 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. -- Matthew Garrett | mjg59@srcf.ucam.org ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 17:56 ` Matthew Garrett @ 2013-02-13 18:44 ` H. Peter Anvin 2013-02-13 18:51 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 18:44 UTC (permalink / raw) To: Matthew Garrett Cc: Casey Schaufler, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 18:44 ` H. Peter Anvin @ 2013-02-13 18:51 ` Matthew Garrett 0 siblings, 0 replies; 49+ messages in thread From: Matthew Garrett @ 2013-02-13 18:51 UTC (permalink / raw) To: H. Peter Anvin Cc: Casey Schaufler, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 959 bytes --] On Wed, 2013-02-13 at 10:44 -0800, H. Peter Anvin wrote: > 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. Yeah. Like I said, it's approximately useless. > 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. Like I said, I'm not wed to a capability-based model. However, it does seem marginally more attractive than sprinkling if (!secure_boot) all over the place. If anyone has alternatives, this would be a great time to raise them. -- Matthew Garrett | mjg59@srcf.ucam.org ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 17:51 ` Casey Schaufler 2013-02-13 17:56 ` Matthew Garrett @ 2013-02-13 22:26 ` H. Peter Anvin 2013-02-13 22:58 ` Casey Schaufler 1 sibling, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 22:26 UTC (permalink / raw) To: Casey Schaufler Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/13/2013 09:51 AM, Casey Schaufler wrote: > > You can't add a new capability where there is an existing capability > that can be remotely argued to be appropriate. > > If you tried to "fix" CAP_SYS_RAWIO and/or CAP_SYS_ADMIN you'd end > up with hundreds of capabilities. > > Your particular problem is *not* so important that you get a > capability all to yourself. > {facepalm} This is exactly the kind of thinking which has led to the capability system being so bloody useless. Capabilities need to be associated with resources, not use cases. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 22:26 ` H. Peter Anvin @ 2013-02-13 22:58 ` Casey Schaufler 2013-02-14 0:25 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Casey Schaufler @ 2013-02-13 22:58 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module, Casey Schaufler On 2/13/2013 2:26 PM, H. Peter Anvin wrote: > On 02/13/2013 09:51 AM, Casey Schaufler wrote: >> >> You can't add a new capability where there is an existing capability >> that can be remotely argued to be appropriate. >> >> If you tried to "fix" CAP_SYS_RAWIO and/or CAP_SYS_ADMIN you'd end >> up with hundreds of capabilities. >> >> Your particular problem is *not* so important that you get a >> capability all to yourself. >> > > {facepalm} > > This is exactly the kind of thinking which has led to the capability > system being so bloody useless. The reason the capability system is "bloody useless" is that no one wants to update the core system applications to use it in favor of good old fashioned worked for dad and works for me too superuser. > > Capabilities need to be associated with resources, not use cases. There is no such thing as a "resource" in the Linux security policy model. The Linux security policy model is based on subjects (tasks) accessing objects (e.g. files). Capabilities provide a granular mechanism for granting privilege to violate the Linux security policy. Because in the Bad Old days of Unix "superuser privilege" also granted rights to preform configuration activities it was not possible to eliminate the superuser without extending the capability mechanism to include these. Thus, there are two sorts of capabilities, those controlling privileged access and those controlling restricted activities. In both cases what you are controlling is an activity. Sorry, but that is the way it is defined. I understand that you want capabilities to be associated with resources. That is *not* what we have, and arguing that its what we should have is pointless because Linux does not even have a concept of resources. > > -hpa > > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 22:58 ` Casey Schaufler @ 2013-02-14 0:25 ` H. Peter Anvin 2013-02-14 0:44 ` Casey Schaufler 0 siblings, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-14 0:25 UTC (permalink / raw) To: Casey Schaufler Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/13/2013 02:58 PM, Casey Schaufler wrote: >> >> This is exactly the kind of thinking which has led to the capability >> system being so bloody useless. > > The reason the capability system is "bloody useless" is > that no one wants to update the core system applications to > use it in favor of good old fashioned worked for dad and > works for me too superuser. > Because, in large part because a bunch of the capabilities are so close to equivalent to "superuser" that the distinction is meaningless... so why go through the hassle? (This is especially so since it was a *long* time before the filesystem had any notion of capabilities, and so you had to make your app run as root anyway before you could drop the capabilities... and some of the people who tried failed spectacularly and opened up new security holes.) > > I understand that you want capabilities to be associated with > resources. That is *not* what we have, and arguing that its > what we should have is pointless because Linux does not even > have a concept of resources. > OK, fine, call it "activities". This is still distinct from "usage models", and that's where we're just broken. I may look into seeing if there is any sane way we can use the existing API to define hierarchical capabilities, which at least should let us split existing capabilities just like we used capabilities to split root. -hpa ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-14 0:25 ` H. Peter Anvin @ 2013-02-14 0:44 ` Casey Schaufler 2013-02-14 1:04 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: Casey Schaufler @ 2013-02-14 0:44 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module, Casey Schaufler On 2/13/2013 4:25 PM, H. Peter Anvin wrote: > On 02/13/2013 02:58 PM, Casey Schaufler wrote: >>> This is exactly the kind of thinking which has led to the capability >>> system being so bloody useless. >> The reason the capability system is "bloody useless" is >> that no one wants to update the core system applications to >> use it in favor of good old fashioned worked for dad and >> works for me too superuser. >> > Because, in large part because a bunch of the capabilities are so close > to equivalent to "superuser" that the distinction is meaningless... so > why go through the hassle? (This is especially so since it was a *long* > time before the filesystem had any notion of capabilities, and so you > had to make your app run as root anyway before you could drop the > capabilities... and some of the people who tried failed spectacularly > and opened up new security holes.) Yes. I know. I was one of the people who wrote the P1003.1e/2c spec. I implemented a rootless Unix system. The infamous sendmail capability blowup was not my code, but it was my fault. In the Linux world we have had a terrible problem with no one implementing the next step because no one is eager to have the next bit because you can't do everything without that next step. >> I understand that you want capabilities to be associated with >> resources. That is *not* what we have, and arguing that its >> what we should have is pointless because Linux does not even >> have a concept of resources. >> > OK, fine, call it "activities". This is still distinct from "usage > models", and that's where we're just broken. > > I may look into seeing if there is any sane way we can use the existing > API to define hierarchical capabilities, which at least should let us > split existing capabilities just like we used capabilities to split root. If you want that sort of granularity throw yourself on the SELinux bandwagon. Fine grained capabilities are insane and unmanageable and will only lead to tears. Security is despised because of the notion that making systems impossible to use is a good thing. > > -hpa > > ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-14 0:44 ` Casey Schaufler @ 2013-02-14 1:04 ` Matthew Garrett 2013-02-14 1:08 ` H. Peter Anvin 2013-02-14 1:34 ` Casey Schaufler 0 siblings, 2 replies; 49+ messages in thread From: Matthew Garrett @ 2013-02-14 1:04 UTC (permalink / raw) To: Casey Schaufler Cc: H. Peter Anvin, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 585 bytes --] On Wed, 2013-02-13 at 16:44 -0800, Casey Schaufler wrote: > If you want that sort of granularity throw yourself on the SELinux > bandwagon. Fine grained capabilities are insane and unmanageable > and will only lead to tears. Security is despised because of the > notion that making systems impossible to use is a good thing. SELinux is completely unusable for this specific case. -- Matthew Garrett | mjg59@srcf.ucam.org ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-14 1:04 ` Matthew Garrett @ 2013-02-14 1:08 ` H. Peter Anvin 2013-02-14 2:46 ` Matthew Garrett 2013-02-14 1:34 ` Casey Schaufler 1 sibling, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-14 1:08 UTC (permalink / raw) To: Matthew Garrett Cc: Casey Schaufler, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/13/2013 05:04 PM, Matthew Garrett wrote: > On Wed, 2013-02-13 at 16:44 -0800, Casey Schaufler wrote: > >> If you want that sort of granularity throw yourself on the SELinux >> bandwagon. Fine grained capabilities are insane and unmanageable >> and will only lead to tears. Security is despised because of the >> notion that making systems impossible to use is a good thing. > > SELinux is completely unusable for this specific case. > Well, for at least things with device nodes (/dev/mem, /dev/msr and so on) it should be possible, no? ioperm() and iopl() are another matter. -hpa ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-14 1:08 ` H. Peter Anvin @ 2013-02-14 2:46 ` Matthew Garrett 0 siblings, 0 replies; 49+ messages in thread From: Matthew Garrett @ 2013-02-14 2:46 UTC (permalink / raw) To: H. Peter Anvin Cc: Casey Schaufler, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 573 bytes --] On Wed, 2013-02-13 at 17:08 -0800, H. Peter Anvin wrote: > Well, for at least things with device nodes (/dev/mem, /dev/msr and so > on) it should be possible, no? ioperm() and iopl() are another matter. Sure, if we can guarantee that a signed userspace loads a signed SELinux policy before any unsigned code runs. But, realistically, that's not going to be possible. -- Matthew Garrett | mjg59@srcf.ucam.org ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-14 1:04 ` Matthew Garrett 2013-02-14 1:08 ` H. Peter Anvin @ 2013-02-14 1:34 ` Casey Schaufler 1 sibling, 0 replies; 49+ messages in thread From: Casey Schaufler @ 2013-02-14 1:34 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module, Casey Schaufler On 2/13/2013 5:04 PM, Matthew Garrett wrote: > On Wed, 2013-02-13 at 16:44 -0800, Casey Schaufler wrote: > >> If you want that sort of granularity throw yourself on the SELinux >> bandwagon. Fine grained capabilities are insane and unmanageable >> and will only lead to tears. Security is despised because of the >> notion that making systems impossible to use is a good thing. > SELinux is completely unusable for this specific case. > Well, you'll get no argument from me there. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 6:33 ` H. Peter Anvin 2013-02-13 6:41 ` Matthew Garrett @ 2013-02-13 8:27 ` Paolo Bonzini 2013-02-13 17:21 ` H. Peter Anvin 2013-02-13 17:22 ` H. Peter Anvin 1 sibling, 2 replies; 49+ messages in thread From: Paolo Bonzini @ 2013-02-13 8:27 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module Il 13/02/2013 07:33, H. Peter Anvin ha scritto: >> >>> Sounds like you are thinking of CAP_SYS_ADMIN, but I don't really see a >>> huge difference between MSRs and I/O control registers... just different >>> address spaces. >> >> Not having CAP_SYS_RAWIO blocks various SCSI commands, for instance. >> These might result in the ability to write individual blocks or destroy >> the device firmware, but do any of them permit modifying the running >> kernel? No, they cannot. > That is just batshit crazy. If you have CAP_SYS_RAWIO you can do iopl() > which means you can reprogram your northbridge, at which point you most > definitely *can* modify the running kernel. > > And some SCSI driver requires this??! No, and that's why there is a patchset floating that lets you toggle this ability with a sysfs control. This way you do not need CAP_SYS_RAWIO anymore. On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially when coupled with file DAC. Paolo ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 8:27 ` Paolo Bonzini @ 2013-02-13 17:21 ` H. Peter Anvin 2013-02-13 17:22 ` H. Peter Anvin 1 sibling, 0 replies; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 17:21 UTC (permalink / raw) To: Paolo Bonzini Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/13/2013 12:27 AM, Paolo Bonzini wrote: > > On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially > when coupled with file DAC. > "File DAC"? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 8:27 ` Paolo Bonzini 2013-02-13 17:21 ` H. Peter Anvin @ 2013-02-13 17:22 ` H. Peter Anvin 2013-02-13 19:55 ` Paolo Bonzini 1 sibling, 1 reply; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 17:22 UTC (permalink / raw) To: Paolo Bonzini Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/13/2013 12:27 AM, Paolo Bonzini wrote: > > On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially > when coupled with file DAC. > Either way, I think you are at best deluded and more like you just completely wrong about CAP_SYS_RAWIO being "less dangerous on non-x86 machines". With the possible exception of s390 I suspect it is, in fact, more dangerous. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 17:22 ` H. Peter Anvin @ 2013-02-13 19:55 ` Paolo Bonzini 2013-02-13 22:24 ` H. Peter Anvin 0 siblings, 1 reply; 49+ messages in thread From: Paolo Bonzini @ 2013-02-13 19:55 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module Il 13/02/2013 18:22, H. Peter Anvin ha scritto: >> >> On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially >> when coupled with file DAC. Discretionary Access Control. > Either way, I think you are at best deluded and more like you just > completely wrong about CAP_SYS_RAWIO being "less dangerous on non-x86 > machines". With the possible exception of s390 I suspect it is, in > fact, more dangerous. I may well be wrong, but as a quick data point CAP_SYS_RAWIO has no occurrences in arch/ except arch/x86. Of course a lot of driver functionality will be limited to CAP_SYS_RAWIO, but usually this requires having a file descriptor for some file. Paolo ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-13 19:55 ` Paolo Bonzini @ 2013-02-13 22:24 ` H. Peter Anvin 0 siblings, 0 replies; 49+ messages in thread From: H. Peter Anvin @ 2013-02-13 22:24 UTC (permalink / raw) To: Paolo Bonzini Cc: Matthew Garrett, Borislav Petkov, Kees Cook, LKML, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On 02/13/2013 11:55 AM, Paolo Bonzini wrote: > Il 13/02/2013 18:22, H. Peter Anvin ha scritto: >>> >>> On non-x86 machines CAP_SYS_RAWIO is much less dangerous, especially >>> when coupled with file DAC. > > Discretionary Access Control. > >> Either way, I think you are at best deluded and more like you just >> completely wrong about CAP_SYS_RAWIO being "less dangerous on non-x86 >> machines". With the possible exception of s390 I suspect it is, in >> fact, more dangerous. > > I may well be wrong, but as a quick data point CAP_SYS_RAWIO has no > occurrences in arch/ except arch/x86. Of course a lot of driver > functionality will be limited to CAP_SYS_RAWIO, but usually this > requires having a file descriptor for some file. > Well, yes, although that could include /dev/mem. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:12 [PATCH] x86: Lock down MSR writing in secure boot Kees Cook 2013-02-08 19:17 ` H. Peter Anvin @ 2013-02-08 19:17 ` Matthew Garrett 2013-02-08 19:21 ` Kees Cook 1 sibling, 1 reply; 49+ messages in thread From: Matthew Garrett @ 2013-02-08 19:17 UTC (permalink / raw) To: Kees Cook Cc: linux-kernel, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 595 bytes --] On Fri, 2013-02-08 at 11:12 -0800, Kees Cook wrote: > Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is > set since it could lead to execution of arbitrary code in kernel mode. Willing to buy this, but do you have a description of one potential approach? We should probably also figure out what's writing to MSRs at the moment (anything other than energy_perf_bias?) and decide what the best thing to do there is. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:17 ` Matthew Garrett @ 2013-02-08 19:21 ` Kees Cook 2013-02-08 19:27 ` Matthew Garrett 0 siblings, 1 reply; 49+ messages in thread From: Kees Cook @ 2013-02-08 19:21 UTC (permalink / raw) To: Matthew Garrett Cc: linux-kernel, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module On Fri, Feb 8, 2013 at 11:17 AM, Matthew Garrett <matthew.garrett@nebula.com> wrote: > On Fri, 2013-02-08 at 11:12 -0800, Kees Cook wrote: >> Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is >> set since it could lead to execution of arbitrary code in kernel mode. > > Willing to buy this, but do you have a description of one potential > approach? We should probably also figure out what's writing to MSRs at > the moment (anything other than energy_perf_bias?) and decide what the > best thing to do there is. Yes, change the SYSENTER entry point to where-ever you like. There are examples already written: http://grsecurity.net/~spender/msr32.c IMO, _writing_ an MSR from userspace should be considered a bug. If writing is needed, a kernel driver should be mediating the change. wrmsr (and rdmsr) are ring-0 only for good reason. :) -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: [PATCH] x86: Lock down MSR writing in secure boot 2013-02-08 19:21 ` Kees Cook @ 2013-02-08 19:27 ` Matthew Garrett 0 siblings, 0 replies; 49+ messages in thread From: Matthew Garrett @ 2013-02-08 19:27 UTC (permalink / raw) To: Kees Cook Cc: linux-kernel, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, x86, linux-efi, linux-security-module [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 952 bytes --] On Fri, 2013-02-08 at 11:21 -0800, Kees Cook wrote: > On Fri, Feb 8, 2013 at 11:17 AM, Matthew Garrett > <matthew.garrett@nebula.com> wrote: > > On Fri, 2013-02-08 at 11:12 -0800, Kees Cook wrote: > >> Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is > >> set since it could lead to execution of arbitrary code in kernel mode. > > > > Willing to buy this, but do you have a description of one potential > > approach? We should probably also figure out what's writing to MSRs at > > the moment (anything other than energy_perf_bias?) and decide what the > > best thing to do there is. > > Yes, change the SYSENTER entry point to where-ever you like. There are > examples already written: > http://grsecurity.net/~spender/msr32.c Cool. Yup, this sounds like a good plan. ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2013-02-14 2:47 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-08 19:12 [PATCH] x86: Lock down MSR writing in secure boot Kees Cook 2013-02-08 19:17 ` H. Peter Anvin 2013-02-08 19:18 ` Kees Cook 2013-02-08 19:42 ` H. Peter Anvin 2013-02-08 20:14 ` Kees Cook 2013-02-08 20:18 ` H. Peter Anvin 2013-02-08 20:28 ` Kees Cook 2013-02-08 20:34 ` Matthew Garrett 2013-02-08 21:02 ` Kees Cook 2013-02-08 21:07 ` Matthew Garrett 2013-02-08 21:14 ` Josh Boyer 2013-02-08 23:09 ` Andy Lutomirski 2013-02-08 22:30 ` H. Peter Anvin 2013-02-08 23:06 ` Borislav Petkov 2013-02-08 23:26 ` Matthew Garrett 2013-02-09 1:22 ` H. Peter Anvin 2013-02-09 1:29 ` Matthew Garrett 2013-02-09 6:45 ` Kees Cook 2013-02-09 9:29 ` Borislav Petkov 2013-02-09 15:10 ` Kees Cook 2013-02-09 15:11 ` Matthew Garrett 2013-02-13 0:48 ` H. Peter Anvin 2013-02-13 5:39 ` Matthew Garrett 2013-02-13 6:12 ` H. Peter Anvin 2013-02-13 6:27 ` Matthew Garrett 2013-02-13 6:33 ` H. Peter Anvin 2013-02-13 6:41 ` Matthew Garrett 2013-02-13 17:20 ` H. Peter Anvin 2013-02-13 17:26 ` Matthew Garrett 2013-02-13 17:51 ` Casey Schaufler 2013-02-13 17:56 ` Matthew Garrett 2013-02-13 18:44 ` H. Peter Anvin 2013-02-13 18:51 ` Matthew Garrett 2013-02-13 22:26 ` H. Peter Anvin 2013-02-13 22:58 ` Casey Schaufler 2013-02-14 0:25 ` H. Peter Anvin 2013-02-14 0:44 ` Casey Schaufler 2013-02-14 1:04 ` Matthew Garrett 2013-02-14 1:08 ` H. Peter Anvin 2013-02-14 2:46 ` Matthew Garrett 2013-02-14 1:34 ` Casey Schaufler 2013-02-13 8:27 ` Paolo Bonzini 2013-02-13 17:21 ` H. Peter Anvin 2013-02-13 17:22 ` H. Peter Anvin 2013-02-13 19:55 ` Paolo Bonzini 2013-02-13 22:24 ` H. Peter Anvin 2013-02-08 19:17 ` Matthew Garrett 2013-02-08 19:21 ` Kees Cook 2013-02-08 19:27 ` Matthew Garrett
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).