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 2013-03-20 04:41, Matt Fleming wrote:
On 03/19/2013 08:36 PM, s...@shealevy.com wrote:
Hello,
When there is an EFI variable with a forward slash in its name,
/sys/firmware/efi/efivars contains a directory entry with a forward
slash, which of course causes all sorts of problems (e.g. EINVAL
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 Wed, Mar 20, 2013 at 08:00:03AM +, James Bottomley wrote:
> I agree with this. But I do think the volatile secret key scheme, where
> you discard the key immediately after use is the more secure one because
> it relies on fewer secrets (and, indeed, no secrets at all after the
> event). I
On 03/18/2013 08:40 AM, James Bottomley wrote:
> From: James Bottomley
>
> The object here is to make the NV+BS variables accessible (at least read only)
> at runtime so we can get a full picture of the state of the EFI variables for
> debugging and secure boot purposes.
This should definitely b
On Mon, 2013-03-18 at 16:02 +, Matthew Garrett wrote:
> On Mon, 2013-03-18 at 11:36 +, Matt Fleming wrote:
> > On Fri, 2013-03-15 at 08:57 +, David Woodhouse wrote:
> > > True. It probably doesn't *matter* because the size is zero so the
> > > firmware is just going to ignore the pointe
On Wed, Mar 20, 2013 at 08:44:35AM +, Matt Fleming wrote:
> On 03/18/2013 04:02 PM, Matthew Garrett wrote:
> > On Mon, 2013-03-18 at 11:36 +, Matt Fleming wrote:
> >> On Fri, 2013-03-15 at 08:57 +, David Woodhouse wrote:
> >>> True. It probably doesn't *matter* because the size is zero
On 03/18/2013 04:02 PM, Matthew Garrett wrote:
> On Mon, 2013-03-18 at 11:36 +, Matt Fleming wrote:
>> On Fri, 2013-03-15 at 08:57 +, David Woodhouse wrote:
>>> True. It probably doesn't *matter* because the size is zero so the
>>> firmware is just going to ignore the pointer anyway. Althou
On 03/19/2013 08:36 PM, s...@shealevy.com wrote:
> Hello,
>
> When there is an EFI variable with a forward slash in its name,
> /sys/firmware/efi/efivars contains a directory entry with a forward
> slash, which of course causes all sorts of problems (e.g. EINVAL from
> stat(2)). Off the top of
On Tue, 2013-03-19 at 23:17 +, Matthew Garrett wrote:
> On Tue, Mar 19, 2013 at 11:00:31PM +, James Bottomley wrote:
> > On Tue, 2013-03-19 at 18:50 +, Matthew Garrett wrote:
> > > Well, that somewhat complicates implementation - we'd be encrypting the
> > > entire contents of memory e
21 matches
Mail list logo
