On Thu, Mar 21, 2013 at 11:19:52AM -0500, Serge E. Hallyn wrote:
[..]
> > I am hoping I did not miss your point entirely.
>
> No, you didn't. If replay attacks are not a concern then that bit
> doesn't matter. But if^Wwhen there is a vulnerability in a signed kernel,
> and a user has a copy of
Revocation is in the kernel.
--
Matthew Garrett |
matthew.garr...@nebula.comn�r��yb�X��ǧv�^�){.n�+{�y^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Quoting Vivek Goyal (vgo...@redhat.com):
> On Thu, Mar 21, 2013 at 10:58:23AM -0500, Serge E. Hallyn wrote:
> > Quoting Vivek Goyal (vgo...@redhat.com):
> > > On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> > > > Quoting Vivek Goyal (vgo...@redhat.com):
> > > > ...
> > > > > Givi
On Thu, Mar 21, 2013 at 10:58:23AM -0500, Serge E. Hallyn wrote:
> Quoting Vivek Goyal (vgo...@redhat.com):
> > On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> > > Quoting Vivek Goyal (vgo...@redhat.com):
> > > ...
> > > > Giving CAP_MODIFY_KERNEL to processess upon signature ver
Quoting Vivek Goyal (vgo...@redhat.com):
> On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> > Quoting Vivek Goyal (vgo...@redhat.com):
> > ...
> > > Giving CAP_MODIFY_KERNEL to processess upon signature verification
> > > will simplify things a bit.
> > >
> > > Only thing is that
On Thu, Mar 21, 2013 at 10:37:25AM -0500, Serge E. Hallyn wrote:
> Quoting Vivek Goyal (vgo...@redhat.com):
> ...
> > Giving CAP_MODIFY_KERNEL to processess upon signature verification
> > will simplify things a bit.
> >
> > Only thing is that signature verification alone is not sufficient. We
> >
Quoting Vivek Goyal (vgo...@redhat.com):
...
> Giving CAP_MODIFY_KERNEL to processess upon signature verification
> will simplify things a bit.
>
> Only thing is that signature verification alone is not sufficient. We
> also need to make sure after signature verification executable can
> not be mo
On Wed, Mar 20, 2013 at 09:18:10PM +, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote:
> > On Wed, 2013-03-20 at 20:37 +, Matthew Garrett wrote:
> > > Right, that'd be the rough idea. Any further runtime policy updates
> > > would presumably need to be signed wi
On Wed, 20 Mar 2013, Mimi Zohar wrote:
> On Tue, 2013-03-19 at 15:47 +1100, James Morris wrote:
> > On Mon, 18 Mar 2013, Matthew Garrett wrote:
> >
> > > This patch introduces CAP_COMPROMISE_KERNEL.
> >
> > I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and
> > less emoti
On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote:
> On Wed, 2013-03-20 at 20:37 +, Matthew Garrett wrote:
> > Right, that'd be the rough idea. Any further runtime policy updates
> > would presumably need to be signed with a trusted key.
>
> I'm really sorry to belabor this point, but can ke
On Wed, 2013-03-20 at 20:37 +, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 15:16 -0400, Mimi Zohar wrote:
> > On Wed, 2013-03-20 at 18:12 +, Matthew Garrett wrote:
> > > Well, in the absence of hardcoded in-kernel policy, there needs to be
> > > some mechanism for ensuring the integrity
On Wed, 2013-03-20 at 15:16 -0400, Mimi Zohar wrote:
> On Wed, 2013-03-20 at 18:12 +, Matthew Garrett wrote:
> > Well, in the absence of hardcoded in-kernel policy, there needs to be
> > some mechanism for ensuring the integrity of a policy. Shipping a signed
> > policy initramfs fragment and h
On Wed, 2013-03-20 at 18:12 +, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 14:01 -0400, Mimi Zohar wrote:
>
> > Sorry, I'm not sure to which work you're referring. If you're referring
> > to Dmitry's "initramfs with digital signature protection" patches, then
> > we're speaking about enforc
On Wed, 2013-03-20 at 14:01 -0400, Mimi Zohar wrote:
> Sorry, I'm not sure to which work you're referring. If you're referring
> to Dmitry's "initramfs with digital signature protection" patches, then
> we're speaking about enforcing integrity, not MAC security.
Well, in the absence of hardcode
On Wed, 2013-03-20 at 16:49 +, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 12:41 -0400, Mimi Zohar wrote:
>
> > Matthrew, perhaps you could clarify whether this will be tied to MAC
> > security. Based on the kexec thread, I'm under the impression that is
> > not the intention, or at least
On Wed, 2013-03-20 at 12:41 -0400, Mimi Zohar wrote:
> Matthrew, perhaps you could clarify whether this will be tied to MAC
> security. Based on the kexec thread, I'm under the impression that is
> not the intention, or at least not for kexec. As root isn't trusted,
> neither is the boot command
On 03/20/2013 08:14 AM, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 08:03 -0700, H. Peter Anvin wrote:
>> CAP_SYS_RAWIO is definitely inappropriate there.
>
> Ok. How do we fix that without breaking userspace that expects
> CAP_SYS_RAWIO to be sufficient?
>
I don't think we can to some way, b
On Tue, 2013-03-19 at 15:47 +1100, James Morris wrote:
> On Mon, 18 Mar 2013, Matthew Garrett wrote:
>
> > This patch introduces CAP_COMPROMISE_KERNEL.
>
> I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and
> less emotive. Otherwise I think core kernel developers will be
On Wed, 2013-03-20 at 08:03 -0700, H. Peter Anvin wrote:
> CAP_SYS_RAWIO is definitely inappropriate there.
Ok. How do we fix that without breaking userspace that expects
CAP_SYS_RAWIO to be sufficient?
--
Matthew Garrett | mj...@srcf.ucam.org
N�r��yb�X��ǧv�^�){.n�+{�y^n�r���z�
CAP_SYS_RAWIO is definitely inappropriate there.
Matthew Garrett wrote:
>On Tue, 2013-03-19 at 18:02 -0700, H. Peter Anvin wrote:
>
>> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the
>possibility
>> of compromising the kernel, because they let device drivers be
>bypassed,
>> which m
On Tue, 2013-03-19 at 18:02 -0700, H. Peter Anvin wrote:
> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility
> of compromising the kernel, because they let device drivers be bypassed,
> which means arbitrary DMA, which means you have everything.
Having checked again, I don'
On Tue, 2013-03-19 at 20:22 -0700, H. Peter Anvin wrote:
> On 03/19/2013 08:18 PM, Alex Williamson wrote:
> >>
> >> The "pinning" process needs to involve a call to the kernel to process
> >> the page for DMA (pinning the page and opening it in the iommu) and
> >> return a transaction address, of c
On 03/19/2013 08:18 PM, Alex Williamson wrote:
>>
>> The "pinning" process needs to involve a call to the kernel to process
>> the page for DMA (pinning the page and opening it in the iommu) and
>> return a transaction address, of course.
>>
>> I think we have the interface for that in vfio, but I
On Tue, 2013-03-19 at 20:08 -0700, H. Peter Anvin wrote:
> On 03/19/2013 07:48 PM, H. Peter Anvin wrote:
> > On 03/19/2013 06:28 PM, Matthew Garrett wrote:
> >> Mm. The question is whether we can reliably determine the ranges a
> device should be able to access without having to trust userspace
> (
On 03/19/2013 07:48 PM, H. Peter Anvin wrote:
> On 03/19/2013 06:28 PM, Matthew Garrett wrote:
>> Mm. The question is whether we can reliably determine the ranges a device
>> should be able to access without having to trust userspace (and, ideally,
>> without having to worry about whether iommu v
On 03/19/2013 06:28 PM, Matthew Garrett wrote:
> Mm. The question is whether we can reliably determine the ranges a device
> should be able to access without having to trust userspace (and, ideally,
> without having to worry about whether iommu vendors have done their job).
> It's pretty importa
Mm. The question is whether we can reliably determine the ranges a device
should be able to access without having to trust userspace (and, ideally,
without having to worry about whether iommu vendors have done their job). It's
pretty important for PCI passthrough, so we do need to care.
--
Mat
On 03/19/2013 06:07 PM, Matthew Garrett wrote:
> Yeah, I'd like the option of relaxing restrictions when drivers explicitly
> opt in based on iommu support.
When drivers opt in they can provide an interface. The interesting case
becomes non-drivers.
-hpa
--
H. Peter Anvin, Intel Open
The cases I'd looked at seemed to mostly involve obsolete hardware or only
allow command submission to SCSI targets, so I wasn't too worried about them -
but, like I said, I've no inherent objection to using CAP_SYS_RAWIO as long as
we modify any cases where userspace really does need that acces
Yeah, I'd like the option of relaxing restrictions when drivers explicitly opt
in based on iommu support.
--
Matthew Garrett | matthew.garr...@nebula.com
On 03/19/2013 06:02 PM, H. Peter Anvin wrote:
>
> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility
> of compromising the kernel, because they let device drivers be bypassed,
> which means arbitrary DMA, which means you have everything.
>
Well, *unless* you have an iommu t
On 03/18/2013 09:47 PM, James Morris wrote:
> On Mon, 18 Mar 2013, Matthew Garrett wrote:
>
>> This patch introduces CAP_COMPROMISE_KERNEL.
>
> I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and
> less emotive. Otherwise I think core kernel developers will be scratching
On 03/18/2013 02:32 PM, Matthew Garrett wrote:
>
> This means we can return our focus to the kernel. There's currently a number
> of kernel interfaces that permit privileged userspace to modify the running
> kernel. These are currently protected by CAP_SYS_RAWIO, but unfortunately
> the semantics
On lun., 2013-03-18 at 17:32 -0400, Matthew Garrett wrote:
> This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability
> indicates that a process is empowered to perform tasks that may result
> in
> modification of the running kernel. While aimed at handling the
> specific
> use-case of
On Mon, 18 Mar 2013, Matthew Garrett wrote:
> This patch introduces CAP_COMPROMISE_KERNEL.
I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and
less emotive. Otherwise I think core kernel developers will be scratching
their head over where to sprinkle this.
Apart from tha
Caring about protecting the kernel from UID 0 was previously relatively
uninteresting, since an attacker could simply modify the kernel, a module
or an earlier part of the boot chain in order to insert new code. However,
there are now a range of widely-deployed mechanisms for ensuring the
authentic
36 matches
Mail list logo
