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 un
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 b
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 despise
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 impossib
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 cor
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 o
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 wi
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 *no
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
comp
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
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 approximate
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 the
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 ca
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:
>
>
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 inapp
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".
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.
--
To unsubscribe
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.
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.
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 patchs
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 blo
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.
Th
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
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 someon
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 ori
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 n
On Sat, Feb 9, 2013 at 1:29 AM, 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 i
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.
On Fri, Feb 8, 2013 at 5:29 PM, Matthew Garrett
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 Boo
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.
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
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,
On 02/08/2013 01:14 PM, Josh Boyer wrote:
> On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett
> 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 c
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 w
On 02/08/2013 01:02 PM, Kees Cook wrote:
> On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
> 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 immutabl
On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett
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 e
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 mes
On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
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
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 stil
On Fri, Feb 8, 2013 at 12:18 PM, H. Peter Anvin 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 inhebtl
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 wrote:
>On Fri, Feb 8, 2013 at 11:42 AM, H. P
On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin 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 t
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
On Fri, 2013-02-08 at 11:21 -0800, Kees Cook wrote:
> On Fri, Feb 8, 2013 at 11:17 AM, Matthew Garrett
> 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
On Fri, Feb 8, 2013 at 11:17 AM, Matthew Garrett
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
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 wrote:
> We already have CAP_RAWIO for this in mainline; I am not sure if this should
> be harder than that...
>
> Kees Cook wrote:
>
>>Writing to MSRs should not be allowed
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
We already have CAP_RAWIO for this in mainline; I am not sure if this should be
harder than that...
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.
>
>Signed-off-by: Kees Cook
>---
>
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
---
This would be used on top of Matthew Garrett's existing "Secure boot
policy support" patch series.
---
arch/x86/kernel/msr.c |
49 matches
Mail list logo
