On Thu, 2019-05-16 at 01:29 -0400, Arvind Sankar wrote:
> I think that's a separate issue. If you want to allow people to be able
> to put files onto the system that will be IMA verified, they need to
> have some way to locally sign them whether it's inside an initramfs or
> on a real root
On 5/16/2019 7:29 AM, Arvind Sankar wrote:
On Wed, May 15, 2019 at 07:06:52PM +0200, Roberto Sassu wrote:
On 5/15/2019 6:08 PM, Arvind Sankar wrote:
On Wed, May 15, 2019 at 01:19:04PM +0200, Roberto Sassu wrote:
On 5/15/2019 2:52 AM, Arvind Sankar wrote:
I don't understand what you mean? The
On Wed, May 15, 2019 at 07:06:52PM +0200, Roberto Sassu wrote:
> On 5/15/2019 6:08 PM, Arvind Sankar wrote:
> > On Wed, May 15, 2019 at 01:19:04PM +0200, Roberto Sassu wrote:
> >> On 5/15/2019 2:52 AM, Arvind Sankar wrote:
> > I don't understand what you mean? The IMA hashes are signed by some
On 5/15/2019 6:08 PM, Arvind Sankar wrote:
On Wed, May 15, 2019 at 01:19:04PM +0200, Roberto Sassu wrote:
On 5/15/2019 2:52 AM, Arvind Sankar wrote:
You can specify multiple initrd's to the boot loader, and they get
loaded in sequence into memory and parsed by the kernel before /init is
On Wed, May 15, 2019 at 01:19:04PM +0200, Roberto Sassu wrote:
> On 5/15/2019 2:52 AM, Arvind Sankar wrote:
> > You can specify multiple initrd's to the boot loader, and they get
> > loaded in sequence into memory and parsed by the kernel before /init is
> > launched. Currently I believe later
On 5/15/2019 2:52 AM, Arvind Sankar wrote:
On Tue, May 14, 2019 at 04:54:12PM -0700, James Bottomley wrote:
On Tue, 2019-05-14 at 18:39 -0500, Rob Landley wrote:
On 5/14/19 2:18 PM, James Bottomley wrote:
I think Rob is right here. If /init was statically built into
the kernel image, it has
On Tue, May 14, 2019 at 07:44:42PM +0200, Roberto Sassu wrote:
> On 5/14/2019 5:57 PM, Arvind Sankar wrote:
> > On Tue, May 14, 2019 at 11:27:04AM -0400, Arvind Sankar wrote:
> >> It's also much easier to change/customize it for the end
> >> system's requirements rather than setting the process in
On Tue, May 14, 2019 at 04:54:12PM -0700, James Bottomley wrote:
> On Tue, 2019-05-14 at 18:39 -0500, Rob Landley wrote:
> > On 5/14/19 2:18 PM, James Bottomley wrote:
> > > > I think Rob is right here. If /init was statically built into
> > > > the kernel image, it has no more ability to
On Tue, May 14, 2019 at 07:20:15PM +0200, Roberto Sassu wrote:
> On 5/14/2019 6:58 PM, Greg KH wrote:
> > On Tue, May 14, 2019 at 06:33:29PM +0200, Roberto Sassu wrote:
> >> Right, the measurement/signature verification of the kernel image is
> >> sufficient.
> >>
> >> Now, assuming that we defer
On Tue, 2019-05-14 at 18:39 -0500, Rob Landley wrote:
> On 5/14/19 2:18 PM, James Bottomley wrote:
> > > I think Rob is right here. If /init was statically built into
> > > the kernel image, it has no more ability to compromise the kernel
> > > than anything else in the kernel. What's the
On 5/14/19 2:18 PM, James Bottomley wrote:
>> I think Rob is right here. If /init was statically built into the
>> kernel image, it has no more ability to compromise the kernel than
>> anything else in the kernel. What's the problem here?
>
> The specific problem is that unless you own the
On Tue, 2019-05-14 at 08:19 -0700, Andy Lutomirski wrote:
> On Mon, May 13, 2019 at 5:47 AM Roberto Sassu om> wrote:
> > On 5/13/2019 11:07 AM, Rob Landley wrote:
[...]
> > > > The only reason why opening .xattr-list works is that IMA is
> > > > not yet initialized (late_initcall vs
On 5/14/2019 5:57 PM, Arvind Sankar wrote:
On Tue, May 14, 2019 at 11:27:04AM -0400, Arvind Sankar wrote:
It's also much easier to change/customize it for the end
system's requirements rather than setting the process in stone by
putting it inside the kernel.
As an example, if you allow
On 5/14/2019 6:58 PM, Greg KH wrote:
On Tue, May 14, 2019 at 06:33:29PM +0200, Roberto Sassu wrote:
On 5/14/2019 5:19 PM, Andy Lutomirski wrote:
On Mon, May 13, 2019 at 5:47 AM Roberto Sassu wrote:
On 5/13/2019 11:07 AM, Rob Landley wrote:
On 5/13/19 2:49 AM, Roberto Sassu wrote:
On
On Tue, May 14, 2019 at 06:33:29PM +0200, Roberto Sassu wrote:
> On 5/14/2019 5:19 PM, Andy Lutomirski wrote:
> > On Mon, May 13, 2019 at 5:47 AM Roberto Sassu
> > wrote:
> > >
> > > On 5/13/2019 11:07 AM, Rob Landley wrote:
> > > >
> > > >
> > > > On 5/13/19 2:49 AM, Roberto Sassu wrote:
> >
On 5/14/2019 5:19 PM, Andy Lutomirski wrote:
On Mon, May 13, 2019 at 5:47 AM Roberto Sassu wrote:
On 5/13/2019 11:07 AM, Rob Landley wrote:
On 5/13/19 2:49 AM, Roberto Sassu wrote:
On 5/12/2019 9:43 PM, Arvind Sankar wrote:
On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
On
On Tue, May 14, 2019 at 11:27:04AM -0400, Arvind Sankar wrote:
> It's also much easier to change/customize it for the end
> system's requirements rather than setting the process in stone by
> putting it inside the kernel.
As an example, if you allow unverified external initramfs, it seems to
me
On Tue, May 14, 2019 at 01:52:42PM +0200, Roberto Sassu wrote:
> On 5/14/2019 8:06 AM, Rob Landley wrote:
> > On 5/13/19 7:47 AM, Roberto Sassu wrote:
> >> On 5/13/2019 11:07 AM, Rob Landley wrote:
> > Wouldn't the below work even before enforcing signatures on external
> > initramfs:
>
On Mon, May 13, 2019 at 5:47 AM Roberto Sassu wrote:
>
> On 5/13/2019 11:07 AM, Rob Landley wrote:
> >
> >
> > On 5/13/19 2:49 AM, Roberto Sassu wrote:
> >> On 5/12/2019 9:43 PM, Arvind Sankar wrote:
> >>> On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
> On 5/12/19 7:52 AM,
On 5/14/19 6:52 AM, Roberto Sassu wrote:
> On 5/14/2019 8:06 AM, Rob Landley wrote:
>> On 5/13/19 7:47 AM, Roberto Sassu wrote:
>>> On 5/13/2019 11:07 AM, Rob Landley wrote:
>> Wouldn't the below work even before enforcing signatures on external
>> initramfs:
>> 1. Create an embedded
On Tue, May 14, 2019 at 01:06:45AM -0500, Rob Landley wrote:
> On 5/13/19 5:09 PM, Mimi Zohar wrote:
> >> Ok, but wouldn't my idea still work? Leave the default compiled-in
> >> policy set to not appraise initramfs. The embedded /init sets all the
> >> xattrs, changes the policy to appraise tmpfs,
On 5/14/2019 8:06 AM, Rob Landley wrote:
On 5/13/19 7:47 AM, Roberto Sassu wrote:
On 5/13/2019 11:07 AM, Rob Landley wrote:
Wouldn't the below work even before enforcing signatures on external
initramfs:
1. Create an embedded initramfs with an /init that does the xattr
parsing/setting. This
On 5/13/19 5:09 PM, Mimi Zohar wrote:
>> Ok, but wouldn't my idea still work? Leave the default compiled-in
>> policy set to not appraise initramfs. The embedded /init sets all the
>> xattrs, changes the policy to appraise tmpfs, and then exec's the real
>> init? Then everything except the
On 5/13/19 7:47 AM, Roberto Sassu wrote:
> On 5/13/2019 11:07 AM, Rob Landley wrote:
Wouldn't the below work even before enforcing signatures on external
initramfs:
1. Create an embedded initramfs with an /init that does the xattr
parsing/setting. This will be verified as part
On Mon, 2019-05-13 at 14:47 -0400, Arvind Sankar wrote:
> On Mon, May 13, 2019 at 02:36:24PM -0400, Mimi Zohar wrote:
> >
> > > > How does this work today then? Is it actually the case that initramfs
> > > > just cannot be used on an IMA-enabled system, or it can but it leaves
> > > > the
On Mon, May 13, 2019 at 02:36:24PM -0400, Mimi Zohar wrote:
>
> > > How does this work today then? Is it actually the case that initramfs
> > > just cannot be used on an IMA-enabled system, or it can but it leaves
> > > the initramfs unverified and we're trying to fix that? I had assumed the
> >
> > How does this work today then? Is it actually the case that initramfs
> > just cannot be used on an IMA-enabled system, or it can but it leaves
> > the initramfs unverified and we're trying to fix that? I had assumed the
> > latter.
> Oooh, it's done not by starting IMA appraisal later, but
On Mon, May 13, 2019 at 01:20:08PM -0400, Arvind Sankar wrote:
> On Mon, May 13, 2019 at 02:47:04PM +0200, Roberto Sassu wrote:
> > On 5/13/2019 11:07 AM, Rob Landley wrote:
> > >
> > >
> > > On 5/13/19 2:49 AM, Roberto Sassu wrote:
> > >> On 5/12/2019 9:43 PM, Arvind Sankar wrote:
> > >>> On
On Mon, May 13, 2019 at 01:20:08PM -0400, Arvind Sankar wrote:
> On Mon, May 13, 2019 at 02:47:04PM +0200, Roberto Sassu wrote:
> > On 5/13/2019 11:07 AM, Rob Landley wrote:
> > >
> > >
> > > On 5/13/19 2:49 AM, Roberto Sassu wrote:
> > >> On 5/12/2019 9:43 PM, Arvind Sankar wrote:
> > >>> On
On Mon, May 13, 2019 at 02:47:04PM +0200, Roberto Sassu wrote:
> On 5/13/2019 11:07 AM, Rob Landley wrote:
> >
> >
> > On 5/13/19 2:49 AM, Roberto Sassu wrote:
> >> On 5/12/2019 9:43 PM, Arvind Sankar wrote:
> >>> On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
> On 5/12/19
On 5/13/2019 11:07 AM, Rob Landley wrote:
On 5/13/19 2:49 AM, Roberto Sassu wrote:
On 5/12/2019 9:43 PM, Arvind Sankar wrote:
On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
On 5/12/19 7:52 AM, Mimi Zohar wrote:
On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
On
On Mon, 2019-05-13 at 04:07 -0500, Rob Landley wrote:
> > Allowing a kernel with integrity enforcement to parse the CPIO image
> > without verifying it first is the weak point.
>
> If you don't verify the CPIO image then in theory it could have anything in
> it,
> yes. You seem to believe that
On 5/13/19 2:49 AM, Roberto Sassu wrote:
> On 5/12/2019 9:43 PM, Arvind Sankar wrote:
>> On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
>>> On 5/12/19 7:52 AM, Mimi Zohar wrote:
On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
> On Thu, May 09, 2019 at
On 5/12/2019 9:43 PM, Arvind Sankar wrote:
On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
On 5/12/19 7:52 AM, Mimi Zohar wrote:
On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
This proposal consists in
On May 12, 2019 8:31:05 AM PDT, Dominik Brodowski
wrote:
>On Sun, May 12, 2019 at 03:18:16AM -0700, h...@zytor.com wrote:
>> > Couldn't this parsing of the .xattr-list file and the setting of
>the xattrs
>> > be done equivalently by the initramfs' /init? Why is kernel
>involvement
>> > actually
On May 12, 2019 5:02:30 PM PDT, Mimi Zohar wrote:
>On Sun, 2019-05-12 at 17:31 +0200, Dominik Brodowski wrote:
>> On Sun, May 12, 2019 at 08:52:47AM -0400, Mimi Zohar wrote:
>
>
>> > It's too late. The /init itself should be signed and verified.
>>
>> Could you elaborate a bit more about the
On Sun, 2019-05-12 at 17:31 +0200, Dominik Brodowski wrote:
> On Sun, May 12, 2019 at 08:52:47AM -0400, Mimi Zohar wrote:
> > It's too late. The /init itself should be signed and verified.
>
> Could you elaborate a bit more about the threat model, and why deferring
> this to the initramfs is
On Sun, May 12, 2019 at 05:05:48PM +, Rob Landley wrote:
> On 5/12/19 7:52 AM, Mimi Zohar wrote:
> > On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
> >> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
> >>> This proposal consists in marshaling pathnames and xattrs
On 5/12/19 7:52 AM, Mimi Zohar wrote:
> On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
>> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
>>> This proposal consists in marshaling pathnames and xattrs in a file called
>>> .xattr-list. They are unmarshaled by the CPIO
On Sun, May 12, 2019 at 03:18:16AM -0700, h...@zytor.com wrote:
> > Couldn't this parsing of the .xattr-list file and the setting of the xattrs
> > be done equivalently by the initramfs' /init? Why is kernel involvement
> > actually required here?
>
> There are a lot of things that could/should
On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
> > This proposal consists in marshaling pathnames and xattrs in a file called
> > .xattr-list. They are unmarshaled by the CPIO parser after all files have
> > been
On May 12, 2019 2:17:48 AM PDT, Dominik Brodowski
wrote:
>On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
>> This proposal consists in marshaling pathnames and xattrs in a file
>called
>> .xattr-list. They are unmarshaled by the CPIO parser after all files
>have
>> been extracted.
On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
> This proposal consists in marshaling pathnames and xattrs in a file called
> .xattr-list. They are unmarshaled by the CPIO parser after all files have
> been extracted.
Couldn't this parsing of the .xattr-list file and the setting
On 5/11/19 11:04 PM, Rob Landley wrote:
> P.P.S. Sadly, if you want an actually standardized standard format where
> implementations adhere to the standard: IETF RFC 1991 was published in 1996
> and
Nope, darn it, checked my notes and that wasn't it. I thought zip had an RFC,
it's just zlib,
On 5/11/19 5:44 PM, Andy Lutomirski wrote:
> I read some of those emails. ISTM that adding TAR support should be
> seriously considered. Sure, it's baroque, but it's very, very well
> supported, and it does exactly what we need.
Which means you now have two parsers supported in parallel
On Thu, May 9, 2019 at 4:27 AM Roberto Sassu wrote:
>
> This patch set aims at solving the following use case: appraise files from
> the initial ram disk. To do that, IMA checks the signature/hash from the
> security.ima xattr. Unfortunately, this use case cannot be implemented
> currently, as
On Fri, 2019-05-10 at 15:46 -0500, Rob Landley wrote:
> On 5/10/19 6:49 AM, Mimi Zohar wrote:
> > On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote:
> >> On 5/9/2019 8:34 PM, Rob Landley wrote:
> >>> On 5/9/19 6:24 AM, Roberto Sassu wrote:
> >
> The difference with another proposal
>
On 5/10/19 6:49 AM, Mimi Zohar wrote:
> On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote:
>> On 5/9/2019 8:34 PM, Rob Landley wrote:
>>> On 5/9/19 6:24 AM, Roberto Sassu wrote:
>
The difference with another proposal
(https://lore.kernel.org/patchwork/cover/888071/) is that xattrs
On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote:
> On 5/9/2019 8:34 PM, Rob Landley wrote:
> > On 5/9/19 6:24 AM, Roberto Sassu wrote:
> >> The difference with another proposal
> >> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
> >> included in an image without
On 5/9/2019 8:34 PM, Rob Landley wrote:
On 5/9/19 6:24 AM, Roberto Sassu wrote:
This patch set aims at solving the following use case: appraise files from
the initial ram disk. To do that, IMA checks the signature/hash from the
security.ima xattr. Unfortunately, this use case cannot be
On 5/9/19 6:24 AM, Roberto Sassu wrote:
> This patch set aims at solving the following use case: appraise files from
> the initial ram disk. To do that, IMA checks the signature/hash from the
> security.ima xattr. Unfortunately, this use case cannot be implemented
> currently, as the CPIO format
This patch set aims at solving the following use case: appraise files from
the initial ram disk. To do that, IMA checks the signature/hash from the
security.ima xattr. Unfortunately, this use case cannot be implemented
currently, as the CPIO format does not support xattrs.
This proposal consists
52 matches
Mail list logo
