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
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 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
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
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
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
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
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
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
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.
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
On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin h...@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
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 keesc...@chromium.org wrote:
On Fri, Feb 8,
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.
On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett
matthew.garr...@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
On 02/08/2013 01:02 PM, Kees Cook wrote:
On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
matthew.garr...@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
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
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+a...@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. :)
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
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 Fri, Feb 8, 2013 at 5:29 PM, Matthew Garrett
matthew.garr...@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
21 matches
Mail list logo
