Re: Kdump with signed images

Re: Kdump with signed images

[Vivek Goyal]

On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
> >
> > [..]
> >> > >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> >> > >> and it is conceivable to have ELF note sections with signatures for
> >> > >> executables.
> >> > >
> >> > > Can you please tell more about what is EMA and IMA. I did quick google
> >> > > and could not find much.
> >> > 
> >> > That should have been EVM and IMA.  Look under security/integrity/.  I
> >> > don't know much about them but they appear to be security modules with a
> >> > focus on verifying checksum or perhaps encrypted hashes of executables
> >> > are consistent.
> >> 
> >> I will do some quick search there and I see if I can understand something.
> >> 
> >
> > Ok, I quickly went through following paper.
> >
> > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> >
> > So it looks like that IMA can store the hashes of files and at execute
> > time ensure those hashes are unchanged to protect against the possibility
> > of modification of files.
> >
> > But what about creation of a new program which can call kexec_load()
> > and execute an unsigned kernel. Doesn't look like that will be
> > prevented using IMA.
> >
> > Whole idea behind UEFI secure boot seems to be that all signing happens
> > outside the running system and now only signed code can run with higher
> > priviliges.
> 
> No.  UEFI secure boot has absolutely nothing todo with this.
> 
> UEFI secure boot is about not being able to hijack the code EFI runs
> directly.  Full stop.
> 
> Some people would like to implment a security policy that says
> you can't boot an untrusted version of windows from linux if you have
> booted with UEFI secure boot, so they don't get their bootloader
> signatures revoked by microsoft.
> 
> A security model relying on Microsoft's key is totally uniteresting to
> me.  Either signing at the UEFI level is of no use or Microsofts key
> will fall again to the combined assult of every cracker and every
> governmental dirty cyber ops division attacking it.  Not to mention that
> Microsoft has little incentive to keep linux booting.
> 
> I think it is reasonable to be able to support a policy where we can't
> boot unsigned versions of Microsoft windows.  However beyond being able
> to exclude booting windows being one criteria for our policy mechanism
> please don't even start to justify things with that ridiculous security
> policy even indirectly.
> 
> > IMA seems to be only protecting against only making sure
> > existing binaries are not modifed but it does not seem to prevent against
> > installation of new binaries and these binaries take advantage of kexec
> > system call to load an unsigned kernel. 
> 
> I believe you can combine IMA with EVM signed security attributes where
> the EVM signing key is offline, and the verification key is in the
> kernel.
> 
> The combination of IMA and EVM gets very close to being able to sign
> executables offline and be able to update them.

[ Again CCing lkml and IMA/EVM folks ]

After little reading, my understanding is EVM also does not support
offline signing. 

http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page

Given the fact EVM protects IMA data (security.ima), which is generated
inline, I am not sure how EVM can sign images offline.

I might have misunderstood things, please correct me if that's not the
case.

Thanks
Vivek

Re: Kdump with signed images

[Mimi Zohar]

On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote:
> On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> > 
> > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
> > >
> > > [..]
> > >> > >> There are 3 options for trusting /sbin/kexec.  There are IMA and EMA,
> > >> > >> and it is conceivable to have ELF note sections with signatures for
> > >> > >> executables.
> > >> > >
> > >> > > Can you please tell more about what is EMA and IMA. I did quick google
> > >> > > and could not find much.
> > >> > 
> > >> > That should have been EVM and IMA.  Look under security/integrity/.  I
> > >> > don't know much about them but they appear to be security modules with a
> > >> > focus on verifying checksum or perhaps encrypted hashes of executables
> > >> > are consistent.
> > >> 
> > >> I will do some quick search there and I see if I can understand something.
> > >> 
> > >
> > > Ok, I quickly went through following paper.
> > >
> > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> > >
> > > So it looks like that IMA can store the hashes of files and at execute
> > > time ensure those hashes are unchanged to protect against the possibility
> > > of modification of files.

IMA-appraisal originally was hashed based, but Dmitry Kasatkin added
digital signature support.  Both have been upstreamed.

> > > But what about creation of a new program which can call kexec_load()
> > > and execute an unsigned kernel. Doesn't look like that will be
> > > prevented using IMA.

Assuming the IMA policy syntax is updated to require 'security.ima' to
contain a digital signature, then it is only a question of protecting
the _ima and _evm keyrings. (Dmitry has such a patch waiting to be
reviewed.)  So the new program would have to be vetted by someone
trusted.

> > > Whole idea behind UEFI secure boot seems to be that all signing happens
> > > outside the running system and now only signed code can run with higher
> > > priviliges.
> > 
> > No.  UEFI secure boot has absolutely nothing todo with this.
> > 
> > UEFI secure boot is about not being able to hijack the code EFI runs
> > directly.  Full stop.
> > 
> > Some people would like to implment a security policy that says
> > you can't boot an untrusted version of windows from linux if you have
> > booted with UEFI secure boot, so they don't get their bootloader
> > signatures revoked by microsoft.
> > 
> > A security model relying on Microsoft's key is totally uniteresting to
> > me.  Either signing at the UEFI level is of no use or Microsofts key
> > will fall again to the combined assult of every cracker and every
> > governmental dirty cyber ops division attacking it.  Not to mention that
> > Microsoft has little incentive to keep linux booting.
> > 
> > I think it is reasonable to be able to support a policy where we can't
> > boot unsigned versions of Microsoft windows.  However beyond being able
> > to exclude booting windows being one criteria for our policy mechanism
> > please don't even start to justify things with that ridiculous security
> > policy even indirectly.
> > 
> > > IMA seems to be only protecting against only making sure
> > > existing binaries are not modifed but it does not seem to prevent against
> > > installation of new binaries and these binaries take advantage of kexec
> > > system call to load an unsigned kernel. 

The IMA/IMA-appraisal policy dictates what needs to be appraised.  The
default ima-appraisal policy appraises all files owned by root.
 
> > I believe you can combine IMA with EVM signed security attributes where
> > the EVM signing key is offline, and the verification key is in the
> > kernel.
> > 
> > The combination of IMA and EVM gets very close to being able to sign
> > executables offline and be able to update them.
> 
> [ Again CCing lkml and IMA/EVM folks ]
> 
> After little reading, my understanding is EVM also does not support
> offline signing. 
> 
> http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page
> 
> Given the fact EVM protects IMA data (security.ima), which is generated
> inline, I am not sure how EVM can sign images offline.
> 
> I might have misunderstood things, please correct me if that's not the
> case.
> 
> Thanks
> Vivek
> 

IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata, such as LSM and IMA-appraisal
labels.  Both 'security.ima' and 'security.evm' can contain digital
signatures.

thanks,

Mimi

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:

[..]
> IMA-appraisal verifies the integrity of file data, while EVM verifies
> the integrity of the file metadata, such as LSM and IMA-appraisal
> labels.  Both 'security.ima' and 'security.evm' can contain digital
> signatures.

But the private key for creating these digital signature needs to be
on the target system?

Thanks
Vivek

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
> 
> [..]
> > IMA-appraisal verifies the integrity of file data, while EVM verifies
> > the integrity of the file metadata, such as LSM and IMA-appraisal
> > labels.  Both 'security.ima' and 'security.evm' can contain digital
> > signatures.
> 
> But the private key for creating these digital signature needs to be
> on the target system?
> 
> Thanks
> Vivek

Absolutely not.  The public key needs to be added to the _ima or _evm
keyrings.  Roberto Sassu modified dracut and later made equivalent
changes to systemd.  Both have been upstreamed.  Dmitry has a package
that labels the filesystem called ima-evm-utils, which supports hash
(IMA), hmac(EVM) and digital signatures(both).

We're hoping that distro's would label all immutable files, not only elf
executables, with digital signatures and mutable files with a hash.

thanks,

Mimi

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote:
> On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
> > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
> > 
> > [..]
> > > IMA-appraisal verifies the integrity of file data, while EVM verifies
> > > the integrity of the file metadata, such as LSM and IMA-appraisal
> > > labels.  Both 'security.ima' and 'security.evm' can contain digital
> > > signatures.
> > 
> > But the private key for creating these digital signature needs to be
> > on the target system?
> > 
> > Thanks
> > Vivek
> 
> Absolutely not.  The public key needs to be added to the _ima or _evm
> keyrings.  Roberto Sassu modified dracut and later made equivalent
> changes to systemd.  Both have been upstreamed.

Putting public key in _ima or _evm keyring is not the problem. This is
just the verification part.

> Dmitry has a package
> that labels the filesystem called ima-evm-utils, which supports hash
> (IMA), hmac(EVM) and digital signatures(both).
> 
> We're hoping that distro's would label all immutable files, not only elf
> executables, with digital signatures and mutable files with a hash.

So this labeling (digital signing) can happen at build time?

I suspect you need labeling to happen at system install time? If yes,
installer does not have the private key to sign anything.

IOW, if distro sign a file, they will most likely put signatures in
ELF header (something along the lines of signing PE/COFF binaries). But
I think you need digital signatures to be put in security.ima which are
stored in xattrs and xattrs are not generated till you put file in
question on target file system.

Thanks
Vivek

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-10-25 at 14:55 -0400, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote:
> > On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote:
> > > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote:
> > > 
> > > [..]
> > > > IMA-appraisal verifies the integrity of file data, while EVM verifies
> > > > the integrity of the file metadata, such as LSM and IMA-appraisal
> > > > labels.  Both 'security.ima' and 'security.evm' can contain digital
> > > > signatures.
> > > 
> > > But the private key for creating these digital signature needs to be
> > > on the target system?
> > > 
> > > Thanks
> > > Vivek
> > 
> > Absolutely not.  The public key needs to be added to the _ima or _evm
> > keyrings.  Roberto Sassu modified dracut and later made equivalent
> > changes to systemd.  Both have been upstreamed.
> 
> Putting public key in _ima or _evm keyring is not the problem. This is
> just the verification part.
> 
> > Dmitry has a package
> > that labels the filesystem called ima-evm-utils, which supports hash
> > (IMA), hmac(EVM) and digital signatures(both).
> > 
> > We're hoping that distro's would label all immutable files, not only elf
> > executables, with digital signatures and mutable files with a hash.
> 
> So this labeling (digital signing) can happen at build time?

There is nothing inherently preventing it from happening at build time.
Elana Reshetova gave a talk at LSS 2012 on modifying RPM
http://lwn.net/Articles/518265/. 

> I suspect you need labeling to happen at system install time? If yes,
> installer does not have the private key to sign anything.

The installed system needs to be labeled, but how that occurs is
dependent on your environment (eg. flash, rpm based install).  Neither
of these mechanisms would require the build private key.

On a running system, the package installer, after verifying the package
integrity, would install each file with the associated 'security.ima'
extended attribute.  The 'security.evm' digital signature would be
installed with an HMAC, calculated using a system unique key. 

> IOW, if distro sign a file, they will most likely put signatures in
> ELF header (something along the lines of signing PE/COFF binaries). 

Rusty was definitely against putting the signature in the ELF header for
kernel modules.  Why would this be any different?

> But
> I think you need digital signatures to be put in security.ima which are
> stored in xattrs and xattrs are not generated till you put file in
> question on target file system.
> 
> Thanks
> Vivek

The 'security.ima' digital signature would be created as part of the
build process and stored as an extended attribute with the file, like
other metadata.  On install, the file, extended attributes and other
metadata would be copied to the target file system.

Mimi
 

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:

> On a running system, the package installer, after verifying the package
> integrity, would install each file with the associated 'security.ima'
> extended attribute.  The 'security.evm' digital signature would be
> installed with an HMAC, calculated using a system unique key. 

The idea isn't to prevent /sbin/kexec from being modified after 
installation - it's to prevent it from being possible to install a 
system that has a modified /sbin/kexec. Leaving any part of this up to 
the package installer means that it doesn't solve the problem we're 
trying to solve here. It must be impossible for the kernel to launch any 
/sbin/kexec that hasn't been signed by a trusted key that's been built 
into the kernel, and it must be impossible for anything other than 
/sbin/kexec to make the kexec system call.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kdump with signed images

[Eric W. Biederman]

Matthew Garrett <mjg@redhat.com> writes:

> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
>
>> On a running system, the package installer, after verifying the package
>> integrity, would install each file with the associated 'security.ima'
>> extended attribute.  The 'security.evm' digital signature would be
>> installed with an HMAC, calculated using a system unique key. 
>
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec. Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

The 'security.capability' attribute modulo weirdness with the security
bounding set gives us the necessary tools to allow /sbin/kexec to make
the system call.

The primary trick with this is to limit the installer in such as way
that we can trust the installer even on a system on which root has been
compromised.

Trusting the installer is the same class of problem as trusting
/sbin/kexec, and to me a much more interesting problem as it keeps
critical system files from being tampered with.

It sounds like there are some tricky details to work through but this
direction of system integrity looks like it is worth pursuing,
regardless of how we handle a signed /sbin/kexec.

Eric

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> 
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute.  The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key. 
> 
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec. Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

I am kind of lost now so just trying to summarize whatever I have
learned so far from this thread.

- So say we can sign /sbin/kexec at build time and distros can do that.
- Verify the signature at exec time using kernel keyring and if
  verification happens successfully, say process gains extra capability.
- Use this new capability to determine whether kexec_load() will be
  successful or not.

Even if we can do all this, it still has the issue of being able to
stop the process in user space and replace the code at run time
and be able to launch unsigned kernel.

So until and unless we have a good solution to verify application's
integrity/authneticity at the time of kexec_load() system call we
still have the problem. And I don't think we have come up with a
solution for that yet (until and unless I missed something).
  
Thanks
Vivek

Re: Kdump with signed images

[Mimi Zohar]

On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote:
> On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> > 
> > > On a running system, the package installer, after verifying the package
> > > integrity, would install each file with the associated 'security.ima'
> > > extended attribute.  The 'security.evm' digital signature would be
> > > installed with an HMAC, calculated using a system unique key. 
> > 
> > The idea isn't to prevent /sbin/kexec from being modified after 
> > installation - it's to prevent it from being possible to install a 
> > system that has a modified /sbin/kexec. Leaving any part of this up to 
> > the package installer means that it doesn't solve the problem we're 
> > trying to solve here. It must be impossible for the kernel to launch any 
> > /sbin/kexec that hasn't been signed by a trusted key that's been built 
> > into the kernel, and it must be impossible for anything other than 
> > /sbin/kexec to make the kexec system call.
> 
> I am kind of lost now so just trying to summarize whatever I have
> learned so far from this thread.

Thanks for summarizing.

> - So say we can sign /sbin/kexec at build time and distros can do that.
> - Verify the signature at exec time using kernel keyring and if
>   verification happens successfully, say process gains extra capability.
> - Use this new capability to determine whether kexec_load() will be
>   successful or not.
> 
> Even if we can do all this, it still has the issue of being able to
> stop the process in user space and replace the code at run time
> and be able to launch unsigned kernel.
> 
> So until and unless we have a good solution to verify application's
> integrity/authneticity at the time of kexec_load() system call we
> still have the problem. And I don't think we have come up with a
> solution for that yet (until and unless I missed something).
>   
> Thanks
> Vivek
> 

Agreed, you need a new LSM/integrity hook.

thanks,

Mimi

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Oct 26, 2012 at 02:37:29PM -0400, Mimi Zohar wrote:
> On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote:
> > On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> > > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> > > 
> > > > On a running system, the package installer, after verifying the package
> > > > integrity, would install each file with the associated 'security.ima'
> > > > extended attribute.  The 'security.evm' digital signature would be
> > > > installed with an HMAC, calculated using a system unique key. 
> > > 
> > > The idea isn't to prevent /sbin/kexec from being modified after 
> > > installation - it's to prevent it from being possible to install a 
> > > system that has a modified /sbin/kexec. Leaving any part of this up to 
> > > the package installer means that it doesn't solve the problem we're 
> > > trying to solve here. It must be impossible for the kernel to launch any 
> > > /sbin/kexec that hasn't been signed by a trusted key that's been built 
> > > into the kernel, and it must be impossible for anything other than 
> > > /sbin/kexec to make the kexec system call.
> > 
> > I am kind of lost now so just trying to summarize whatever I have
> > learned so far from this thread.
> 
> Thanks for summarizing.
> 
> > - So say we can sign /sbin/kexec at build time and distros can do that.
> > - Verify the signature at exec time using kernel keyring and if
> >   verification happens successfully, say process gains extra capability.
> > - Use this new capability to determine whether kexec_load() will be
> >   successful or not.
> > 
> > Even if we can do all this, it still has the issue of being able to
> > stop the process in user space and replace the code at run time
> > and be able to launch unsigned kernel.

Thinking more about it. Can we just keep track whether a process was
ptraced or not and disallow kexec_load() syscall if it was ptraced.
(I am assuming that ptrace is the only way to change process code/data).

So binaries can be signed offline. Signature verification can take place
using kernel keyring at exec() time. And we can keep track of ptraced
processes and disallow calling kexec_load() for such processes. If this
is implementable, this should take care of following requirement raised
by matthew.

************************************************************************
It must be impossible for the kernel to launch any /sbin/kexec that hasn't
been signed by a trusted key that's been built into the kernel, and it
must be impossible for anything other than /sbin/kexec to make the kexec
system call.
*************************************************************************

Thoughts?

Thanks
Vivek

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:

[..]
> > 
> > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > - Verify the signature at exec time using kernel keyring and if
> > >   verification happens successfully, say process gains extra capability.
> > > - Use this new capability to determine whether kexec_load() will be
> > >   successful or not.
> > > 
> > > Even if we can do all this, it still has the issue of being able to
> > > stop the process in user space and replace the code at run time
> > > and be able to launch unsigned kernel.
> 
> Thinking more about it. Can we just keep track whether a process was
> ptraced or not and disallow kexec_load() syscall if it was ptraced.
> (I am assuming that ptrace is the only way to change process code/data).
> 
> So binaries can be signed offline. Signature verification can take place
> using kernel keyring at exec() time. And we can keep track of ptraced
> processes and disallow calling kexec_load() for such processes. If this
> is implementable, this should take care of following requirement raised
> by matthew.
> 
> ************************************************************************
> It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> been signed by a trusted key that's been built into the kernel, and it
> must be impossible for anything other than /sbin/kexec to make the kexec
> system call.
> *************************************************************************
> 
> Thoughts?

Eric responded but my mistake he responded to only me. So I will quickly 
put his idea here.

[start quote]

You can't ptrace a process that has a capability you don't.

That should be enforced in security/commoncap/

[end quote]

This looks like a good idea. Upon verification signed binaries will be
assigned special capability and then no unsigned binary should be able
to ptrace signed/verified processes

Thanks
Vivek

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> 
> [..]
> > > 
> > > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > > - Verify the signature at exec time using kernel keyring and if
> > > >   verification happens successfully, say process gains extra capability.
> > > > - Use this new capability to determine whether kexec_load() will be
> > > >   successful or not.
> > > > 
> > > > Even if we can do all this, it still has the issue of being able to
> > > > stop the process in user space and replace the code at run time
> > > > and be able to launch unsigned kernel.
> > 
> > Thinking more about it. Can we just keep track whether a process was
> > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > (I am assuming that ptrace is the only way to change process code/data).
> > 
> > So binaries can be signed offline. Signature verification can take place
> > using kernel keyring at exec() time. And we can keep track of ptraced
> > processes and disallow calling kexec_load() for such processes. If this
> > is implementable, this should take care of following requirement raised
> > by matthew.
> > 
> > ************************************************************************
> > It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> > been signed by a trusted key that's been built into the kernel, and it
> > must be impossible for anything other than /sbin/kexec to make the kexec
> > system call.
> > *************************************************************************
> > 
> > Thoughts?
> 
> Eric responded but my mistake he responded to only me. So I will quickly 
> put his idea here.
> 
> [start quote]
> 
> You can't ptrace a process that has a capability you don't.
> 
> That should be enforced in security/commoncap/
> 
> [end quote]
> 
> This looks like a good idea. Upon verification signed binaries will be
> assigned special capability and then no unsigned binary should be able
> to ptrace signed/verified processes

That's a good generic solution, which I'm all in favor of, but it
doesn't resolve the latter half of Matthrew's requirement "and it must
be impossible for anything other than /sbin/kexec to make the kexec
system call."

thanks,

Mimi

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote:
> On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> > 
> > [..]
> > > > 
> > > > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > > > - Verify the signature at exec time using kernel keyring and if
> > > > >   verification happens successfully, say process gains extra capability.
> > > > > - Use this new capability to determine whether kexec_load() will be
> > > > >   successful or not.
> > > > > 
> > > > > Even if we can do all this, it still has the issue of being able to
> > > > > stop the process in user space and replace the code at run time
> > > > > and be able to launch unsigned kernel.
> > > 
> > > Thinking more about it. Can we just keep track whether a process was
> > > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > > (I am assuming that ptrace is the only way to change process code/data).
> > > 
> > > So binaries can be signed offline. Signature verification can take place
> > > using kernel keyring at exec() time. And we can keep track of ptraced
> > > processes and disallow calling kexec_load() for such processes. If this
> > > is implementable, this should take care of following requirement raised
> > > by matthew.
> > > 
> > > ************************************************************************
> > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> > > been signed by a trusted key that's been built into the kernel, and it
> > > must be impossible for anything other than /sbin/kexec to make the kexec
> > > system call.
> > > *************************************************************************
> > > 
> > > Thoughts?
> > 
> > Eric responded but my mistake he responded to only me. So I will quickly 
> > put his idea here.
> > 
> > [start quote]
> > 
> > You can't ptrace a process that has a capability you don't.
> > 
> > That should be enforced in security/commoncap/
> > 
> > [end quote]
> > 
> > This looks like a good idea. Upon verification signed binaries will be
> > assigned special capability and then no unsigned binary should be able
> > to ptrace signed/verified processes
> 
> That's a good generic solution, which I'm all in favor of, but it
> doesn't resolve the latter half of Matthrew's requirement "and it must
> be impossible for anything other than /sbin/kexec to make the kexec
> system call."

Only those executables which have extended capability
(say CAP_SIGNATURES_VERIFIED) will be able to call kexec_load() syscall.
Only signed executables will get this capability upon signature verification
(using keys in kernel keyring only).

so any xyz executable will not be able to call kexec_load() until and
unless it is signed with keys kernel trusts. This is similar to signed
module verification.

So I think this does satisfy the requirement matthew specified. Isn't it?
Matthew, what do you think?

Thanks
Vivek

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:

> So I think this does satisfy the requirement matthew specified. Isn't it?
> Matthew, what do you think?

Sure, if you can ensure that. You'll need to figure out how to get the 
build system to sign the userspace binaries and you'll need to ensure 
that they're statically linked and don't dlopen anything (including the 
nsswitch modules), but otherwise that should work.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 02:52:25PM +0000, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
> 
> > So I think this does satisfy the requirement matthew specified. Isn't it?
> > Matthew, what do you think?
> 
> Sure, if you can ensure that. You'll need to figure out how to get the 
> build system to sign the userspace binaries and you'll need to ensure 
> that they're statically linked and don't dlopen anything (including the 
> nsswitch modules), but otherwise that should work.
> 

[ CC peter jones ]

Ok, so even if we build kexec-tools statically with glibc, we have the
issue of name service switch modules. glibc will still do dlopen on
these modules. So what are options now.

- Sign glibc and associated shared libraries. Do not allow unsigned
  shared library to dynamically link with signed executable.

- Peter mentioned that work with uClibc for kexec-tools.

I personally think that however hard it is but first option sounds like
a long term solution. We might have more user space processes which
we might have to trust a generic solution will help with that. For example,
we might have to sign and trust qemu at some point of time.

Are there other ways of handing glibc issue?

Thanks
Vivek

Re: Kdump with signed images

[Balbir Singh]

On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Thu, Nov 01, 2012 at 02:52:25PM +0000, Matthew Garrett wrote:
>> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
>>
>> > So I think this does satisfy the requirement matthew specified. Isn't it?
>> > Matthew, what do you think?
>>
>> Sure, if you can ensure that. You'll need to figure out how to get the
>> build system to sign the userspace binaries and you'll need to ensure
>> that they're statically linked and don't dlopen anything (including the
>> nsswitch modules), but otherwise that should work.
>>
>
> [ CC peter jones ]
>
> Ok, so even if we build kexec-tools statically with glibc, we have the
> issue of name service switch modules. glibc will still do dlopen on
> these modules. So what are options now.
>
> - Sign glibc and associated shared libraries. Do not allow unsigned
>   shared library to dynamically link with signed executable.
>
> - Peter mentioned that work with uClibc for kexec-tools.
>
> I personally think that however hard it is but first option sounds like
> a long term solution. We might have more user space processes which
> we might have to trust a generic solution will help with that. For example,
> we might have to sign and trust qemu at some point of time.
>
> Are there other ways of handing glibc issue?
>

Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically
linked programs need some shared libraries which is not acceptable for
me. What can I do?" Probably, worth trying.

Balbir Singh

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote:
> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, Matthew Garrett wrote:
> >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
> >>
> >> > So I think this does satisfy the requirement matthew specified. Isn't it?
> >> > Matthew, what do you think?
> >>
> >> Sure, if you can ensure that. You'll need to figure out how to get the
> >> build system to sign the userspace binaries and you'll need to ensure
> >> that they're statically linked and don't dlopen anything (including the
> >> nsswitch modules), but otherwise that should work.
> >>
> >
> > [ CC peter jones ]
> >
> > Ok, so even if we build kexec-tools statically with glibc, we have the
> > issue of name service switch modules. glibc will still do dlopen on
> > these modules. So what are options now.
> >
> > - Sign glibc and associated shared libraries. Do not allow unsigned
> >   shared library to dynamically link with signed executable.
> >
> > - Peter mentioned that work with uClibc for kexec-tools.
> >
> > I personally think that however hard it is but first option sounds like
> > a long term solution. We might have more user space processes which
> > we might have to trust a generic solution will help with that. For example,
> > we might have to sign and trust qemu at some point of time.
> >
> > Are there other ways of handing glibc issue?
> >
> 
> Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically
> linked programs need some shared libraries which is not acceptable for
> me. What can I do?" Probably, worth trying.

Yes I have seen this. IIUC, it says that build libc with -enable-static-nss
and then individual programs need to statically build against the nss
modules program will use.

I think building libc with -enable-static-nss part will be unacceptable
for general server as other programs would like to make use of the
existing nss functionality.

Thanks
Vivek

Re: Kdump with signed images

[Balbir Singh]

On Fri, Nov 2, 2012 at 8:06 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote:
>> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, Matthew Garrett wrote:
>> >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
>> >>
>> >> > So I think this does satisfy the requirement matthew specified. Isn't it?
>> >> > Matthew, what do you think?
>> >>
>> >> Sure, if you can ensure that. You'll need to figure out how to get the
>> >> build system to sign the userspace binaries and you'll need to ensure
>> >> that they're statically linked and don't dlopen anything (including the
>> >> nsswitch modules), but otherwise that should work.
>> >>
>> >
>> > [ CC peter jones ]
>> >
>> > Ok, so even if we build kexec-tools statically with glibc, we have the
>> > issue of name service switch modules. glibc will still do dlopen on
>> > these modules. So what are options now.
>> >
>> > - Sign glibc and associated shared libraries. Do not allow unsigned
>> >   shared library to dynamically link with signed executable.
>> >
>> > - Peter mentioned that work with uClibc for kexec-tools.
>> >
>> > I personally think that however hard it is but first option sounds like
>> > a long term solution. We might have more user space processes which
>> > we might have to trust a generic solution will help with that. For example,
>> > we might have to sign and trust qemu at some point of time.
>> >
>> > Are there other ways of handing glibc issue?
>> >
>>
>> Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically
>> linked programs need some shared libraries which is not acceptable for
>> me. What can I do?" Probably, worth trying.
>
> Yes I have seen this. IIUC, it says that build libc with -enable-static-nss
> and then individual programs need to statically build against the nss
> modules program will use.
>
> I think building libc with -enable-static-nss part will be unacceptable
> for general server as other programs would like to make use of the
> existing nss functionality.

No, use that library for static linking only for programs that need to
be signed (kexec-tools), until the base OS gets signature support. Why
does the same library need to be used for general sever programs? The
built library would be used only on the build system.

I also like HPA's suggestion on using klibc, but I am not sure what it
would take to port the tools to use klibc

Balbir

Re: Kdump with signed images

[H. Peter Anvin]

On 11/02/2012 07:29 AM, Balbir Singh wrote:
> 
> Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically
> linked programs need some shared libraries which is not acceptable for
> me. What can I do?" Probably, worth trying.
> 

You can build something with klibc... a static klibc binary can easily
be smaller than a dynamic glibc binary.

	-hpa

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Nov 01, 2012 at 02:52:25PM +0000, Matthew Garrett wrote:
>> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
>> 
>> > So I think this does satisfy the requirement matthew specified. Isn't it?
>> > Matthew, what do you think?
>> 
>> Sure, if you can ensure that. You'll need to figure out how to get the 
>> build system to sign the userspace binaries and you'll need to ensure 
>> that they're statically linked and don't dlopen anything (including the 
>> nsswitch modules), but otherwise that should work.
>> 
>
> [ CC peter jones ]
>
> Ok, so even if we build kexec-tools statically with glibc, we have the
> issue of name service switch modules. glibc will still do dlopen on
> these modules. So what are options now.
>
> - Sign glibc and associated shared libraries. Do not allow unsigned
>   shared library to dynamically link with signed executable.
>
> - Peter mentioned that work with uClibc for kexec-tools.
>
> I personally think that however hard it is but first option sounds like
> a long term solution. We might have more user space processes which
> we might have to trust a generic solution will help with that. For example,
> we might have to sign and trust qemu at some point of time.
>
> Are there other ways of handing glibc issue?

It needs to be checked but /sbin/kexec should not use any functions that
trigger nss switch.  No user or password or host name lookup should be
happening.

This is one part in hardening /sbin/kexec to deal with hostile root
users.  We need to check crazy things like do the files we open on /proc
actually point to /proc after we have opened them.

I believe glibc has some code which triggers for suid root applications
that we should ensure gets triggered that avoid trusting things like
LD_LIBRARY_PATH and company.

Eric

Re: Kdump with signed images

[Vivek Goyal]

On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Nov 01, 2012 at 02:52:25PM +0000, Matthew Garrett wrote:
> >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote:
> >> 
> >> > So I think this does satisfy the requirement matthew specified. Isn't it?
> >> > Matthew, what do you think?
> >> 
> >> Sure, if you can ensure that. You'll need to figure out how to get the 
> >> build system to sign the userspace binaries and you'll need to ensure 
> >> that they're statically linked and don't dlopen anything (including the 
> >> nsswitch modules), but otherwise that should work.
> >> 
> >
> > [ CC peter jones ]
> >
> > Ok, so even if we build kexec-tools statically with glibc, we have the
> > issue of name service switch modules. glibc will still do dlopen on
> > these modules. So what are options now.
> >
> > - Sign glibc and associated shared libraries. Do not allow unsigned
> >   shared library to dynamically link with signed executable.
> >
> > - Peter mentioned that work with uClibc for kexec-tools.
> >
> > I personally think that however hard it is but first option sounds like
> > a long term solution. We might have more user space processes which
> > we might have to trust a generic solution will help with that. For example,
> > we might have to sign and trust qemu at some point of time.
> >
> > Are there other ways of handing glibc issue?
> 
> It needs to be checked but /sbin/kexec should not use any functions that
> trigger nss switch.  No user or password or host name lookup should be
> happening.

I also think that we don't call routines which trigger nss switch but
be probably can't rely on that as somebody might introduce it in
future. So we need more robust mechanism to prevent it than just code
inspection.

> 
> This is one part in hardening /sbin/kexec to deal with hostile root
> users.  We need to check crazy things like do the files we open on /proc
> actually point to /proc after we have opened them.

Can you please explain it more. How can one fiddle with /proc. Also
what's the solution then.

> 
> I believe glibc has some code which triggers for suid root applications
> that we should ensure gets triggered that avoid trusting things like
> LD_LIBRARY_PATH and company.

I guess linking statically with uClibc or klibc (as hpa said), might turn
out to be better option to avoid all the issues w.r.t shared objects
and all the tricky environment variables.

Thanks
Vivek

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
>> 
>> It needs to be checked but /sbin/kexec should not use any functions that
>> trigger nss switch.  No user or password or host name lookup should be
>> happening.
>
> I also think that we don't call routines which trigger nss switch but
> be probably can't rely on that as somebody might introduce it in
> future. So we need more robust mechanism to prevent it than just code
> inspection.

The fact that we shouldn't use those routines is enough to let us
walk down a path where they are not used.  Either with a static glibc
linked told to use no nss modules (--enable-static-nss ?), or with
another more restricted libc.

>> This is one part in hardening /sbin/kexec to deal with hostile root
>> users.  We need to check crazy things like do the files we open on /proc
>> actually point to /proc after we have opened them.
>
> Can you please explain it more. How can one fiddle with /proc. Also
> what's the solution then.

The solution is to just fstat the files and verify the filesystem from
which they came after the files have been opened.

The issue is that an evil root user may have mounted something else on /proc.

>> I believe glibc has some code which triggers for suid root applications
>> that we should ensure gets triggered that avoid trusting things like
>> LD_LIBRARY_PATH and company.
>
> I guess linking statically with uClibc or klibc (as hpa said), might turn
> out to be better option to avoid all the issues w.r.t shared objects
> and all the tricky environment variables.

Linking with a more restricted libc will solve most if not all shared
object issues.

We still need to audit our environment variable issue.  How we interpret
them and how our restricted libc automatically interprets them.

Eric

Re: Kdump with signed images

[Vivek Goyal]

On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> >> 
> >> It needs to be checked but /sbin/kexec should not use any functions that
> >> trigger nss switch.  No user or password or host name lookup should be
> >> happening.
> >
> > I also think that we don't call routines which trigger nss switch but
> > be probably can't rely on that as somebody might introduce it in
> > future. So we need more robust mechanism to prevent it than just code
> > inspection.
> 
> The fact that we shouldn't use those routines is enough to let us
> walk down a path where they are not used.  Either with a static glibc
> linked told to use no nss modules (--enable-static-nss ?), or with
> another more restricted libc.

Is there anything wrong with using uClibc? Trying to link again
customized glibc (with --enable-static-nss) sounds just extra work for
build environments. Are there know restricted libc or we need to create
one with passing more compile time options to libc.

Instead of doing more work in an attempt to create restricted libc,
it might be easier to just link against any already available
restricted library.

Thanks
Vivek

Re: Kdump with signed images

[H. Peter Anvin]

Yes, it is unlikely you can pare thibgs down more than klibc.

Vivek Goyal <vgoyal@redhat.com> wrote:

>On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
>> >> 
>> >> It needs to be checked but /sbin/kexec should not use any
>functions that
>> >> trigger nss switch.  No user or password or host name lookup
>should be
>> >> happening.
>> >
>> > I also think that we don't call routines which trigger nss switch
>but
>> > be probably can't rely on that as somebody might introduce it in
>> > future. So we need more robust mechanism to prevent it than just
>code
>> > inspection.
>> 
>> The fact that we shouldn't use those routines is enough to let us
>> walk down a path where they are not used.  Either with a static glibc
>> linked told to use no nss modules (--enable-static-nss ?), or with
>> another more restricted libc.
>
>Is there anything wrong with using uClibc? Trying to link again
>customized glibc (with --enable-static-nss) sounds just extra work for
>build environments. Are there know restricted libc or we need to create
>one with passing more compile time options to libc.
>
>Instead of doing more work in an attempt to create restricted libc,
>it might be easier to just link against any already available
>restricted library.
>
>Thanks
>Vivek

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: Kdump with signed images

[Vivek Goyal]

On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
> >> 
> >> It needs to be checked but /sbin/kexec should not use any functions that
> >> trigger nss switch.  No user or password or host name lookup should be
> >> happening.
> >
> > I also think that we don't call routines which trigger nss switch but
> > be probably can't rely on that as somebody might introduce it in
> > future. So we need more robust mechanism to prevent it than just code
> > inspection.
> 
> The fact that we shouldn't use those routines is enough to let us
> walk down a path where they are not used.  Either with a static glibc
> linked told to use no nss modules (--enable-static-nss ?), or with
> another more restricted libc.

I installed glibc-static and built kexec-tools using gcc "-static" option.
It built just fine and infact kdump is working with it.

Size of new kexec binary is around 1.4MB.

Did not get any warning w.r.t nss, so I am assuming we are not calling
any relevant functions.

I did try building my own libc using --enable-static-nss but it does not
seem to have built static versions of libnss*. Will look more into it
and try linking kexec with this new glibc and see if that works.

Also tried playing with klibc and uclibc a bit but can't get anything
going quickly.

Thanks
Vivek

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote:
>> >> 
>> >> It needs to be checked but /sbin/kexec should not use any functions that
>> >> trigger nss switch.  No user or password or host name lookup should be
>> >> happening.
>> >
>> > I also think that we don't call routines which trigger nss switch but
>> > be probably can't rely on that as somebody might introduce it in
>> > future. So we need more robust mechanism to prevent it than just code
>> > inspection.
>> 
>> The fact that we shouldn't use those routines is enough to let us
>> walk down a path where they are not used.  Either with a static glibc
>> linked told to use no nss modules (--enable-static-nss ?), or with
>> another more restricted libc.
>
> I installed glibc-static and built kexec-tools using gcc "-static" option.
> It built just fine and infact kdump is working with it.
>
> Size of new kexec binary is around 1.4MB.
>
> Did not get any warning w.r.t nss, so I am assuming we are not calling
> any relevant functions.
>
> I did try building my own libc using --enable-static-nss but it does not
> seem to have built static versions of libnss*. Will look more into it
> and try linking kexec with this new glibc and see if that works.
>
> Also tried playing with klibc and uclibc a bit but can't get anything
> going quickly.

Sounds good.  It has been about a year since I looked but kexec built
uclibc just fine last time I tried it.

Eric

Re: Kdump with signed images

[Vivek Goyal]

On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:

[..]

Thnking more about executable signature verification, I have another question.

While verifyign the signature, we will have to read the whole executable
in memory. That sounds bad as we are in kernel mode and will not be killed
and if sombody is trying to execute a malformed exceptionally large
executable, system will start killing other processess. We can potentially
lock all the memory in kernel just by trying to execute a signed huge
executable. Not good.

I was looking at IMA and they seem to be using kernel_read() for reading
page in and update digest. IIUC, that means page is read from disk,
brought in cache and if needed will be read back from disk. But that
means hacker can try to do some timing tricks and try to replace disk image
after signature verification and run unsigned program.

So how do we go about it. Neither of the approaches sound appealing
to me.

Thanks
Vivek

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> 
> [..]
> 
> Thnking more about executable signature verification, I have another question.
> 
> While verifyign the signature, we will have to read the whole executable
> in memory. That sounds bad as we are in kernel mode and will not be killed
> and if sombody is trying to execute a malformed exceptionally large
> executable, system will start killing other processess. We can potentially
> lock all the memory in kernel just by trying to execute a signed huge
> executable. Not good.
> 

Also, even if we try to read in whole executable, can't an hacker modify
pages in swap disk and then they will be faulted back in and bingo hacker
is running its unsigned code. (assuming root has been compromised otherwise
why do we have to do all this exercise).

Thanks
Vivek

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
>> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
>> 
>> [..]
>> 
>> Thnking more about executable signature verification, I have another question.
>> 
>> While verifyign the signature, we will have to read the whole executable
>> in memory. That sounds bad as we are in kernel mode and will not be killed
>> and if sombody is trying to execute a malformed exceptionally large
>> executable, system will start killing other processess. We can potentially
>> lock all the memory in kernel just by trying to execute a signed huge
>> executable. Not good.
>> 
>
> Also, even if we try to read in whole executable, can't an hacker modify
> pages in swap disk and then they will be faulted back in and bingo hacker
> is running its unsigned code. (assuming root has been compromised otherwise
> why do we have to do all this exercise).

You make a decent case for an implicit mlockall(MCL_FUTURE) being
required of signed executables, that are going to be granted privileges
based on signature verification.

As for size if the executable won't fit in memory, there is no point in
checking the signature.

It should be fairly straight forward to make the signature checking
process preemptable and killable.

Of course this is all hand waving at this point.

Eric

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> >> 
> >> [..]
> >> 
> >> Thnking more about executable signature verification, I have another question.
> >> 
> >> While verifyign the signature, we will have to read the whole executable
> >> in memory. That sounds bad as we are in kernel mode and will not be killed
> >> and if sombody is trying to execute a malformed exceptionally large
> >> executable, system will start killing other processess. We can potentially
> >> lock all the memory in kernel just by trying to execute a signed huge
> >> executable. Not good.
> >> 
> >
> > Also, even if we try to read in whole executable, can't an hacker modify
> > pages in swap disk and then they will be faulted back in and bingo hacker
> > is running its unsigned code. (assuming root has been compromised otherwise
> > why do we have to do all this exercise).
> 
> You make a decent case for an implicit mlockall(MCL_FUTURE) being
> required of signed executables, that are going to be granted privileges
> based on signature verification.

implicity lockall for signed executables sounds reasonable to avoid the
swap hack.

> 
> As for size if the executable won't fit in memory, there is no point in
> checking the signature.

Well I am worried about malformed executables. One can sign a huge
executable (which is never meant to run successfully) and cause all
kind of memory issues. 

Can we first look at the signature, decrypt it using certificates in
kernel ring, and if we find out that executable was signed by any
of the certificates, only then we go on to read in whole executable
and try to calculate the digest. May be at the time of signing we can put
 a string, say "LINUX", along with digest and then sing/encrypt it. Upon
decryption we can check if LINUX is there and if yes, we know it was
signed by the certifcate loaded in kernel and then go on to load the
full executable and calculate digest.

Not sure if above is doable or not but if it is, it might reduce the
risk significantly as we will not try to integrity verify executables
not signed by genuine certificates.

> 
> It should be fairly straight forward to make the signature checking
> process preemptable and killable.

hmm..., not sure how to do this. Will have to read more code to understand
process killing and see what can I do this while I am in kernel mode
and I possibly might have done kernel memory allocations using
vmalloc()/kmalloc() etc.

Thanks
Vivek

Re: Kdump with signed images

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
>> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
>> >> 
>> >> [..]
>> >> 
>> >> Thnking more about executable signature verification, I have another question.
>> >> 
>> >> While verifyign the signature, we will have to read the whole executable
>> >> in memory. That sounds bad as we are in kernel mode and will not be killed
>> >> and if sombody is trying to execute a malformed exceptionally large
>> >> executable, system will start killing other processess. We can potentially
>> >> lock all the memory in kernel just by trying to execute a signed huge
>> >> executable. Not good.
>> >> 
>> >
>> > Also, even if we try to read in whole executable, can't an hacker modify
>> > pages in swap disk and then they will be faulted back in and bingo hacker
>> > is running its unsigned code. (assuming root has been compromised otherwise
>> > why do we have to do all this exercise).
>> 
>> You make a decent case for an implicit mlockall(MCL_FUTURE) being
>> required of signed executables, that are going to be granted privileges
>> based on signature verification.
>
> implicity lockall for signed executables sounds reasonable to avoid the
> swap hack.
>
>> 
>> As for size if the executable won't fit in memory, there is no point in
>> checking the signature.
>
> Well I am worried about malformed executables. One can sign a huge
> executable (which is never meant to run successfully) and cause all
> kind of memory issues. 

Good point what to do with executables with invalid sigantures.  From
another reply it sounded like one of the bits of IMA/EVM had already
addressed part of that.

> Can we first look at the signature, decrypt it using certificates in
> kernel ring, and if we find out that executable was signed by any
> of the certificates, only then we go on to read in whole executable
> and try to calculate the digest. May be at the time of signing we can put
>  a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> decryption we can check if LINUX is there and if yes, we know it was
> signed by the certifcate loaded in kernel and then go on to load the
> full executable and calculate digest.

> Not sure if above is doable or not but if it is, it might reduce the
> risk significantly as we will not try to integrity verify executables
> not signed by genuine certificates.

Known plaintext in the signed blob should allow that.  I would be very
careful with that because it sounds like the kind of thing that opens
you up to plain-text attacks, but that is mostly my parania and lack of
experience speaking.

>> It should be fairly straight forward to make the signature checking
>> process preemptable and killable.
>
> hmm..., not sure how to do this. Will have to read more code to understand
> process killing and see what can I do this while I am in kernel mode
> and I possibly might have done kernel memory allocations using
> vmalloc()/kmalloc() etc.

Well basically it is matter of using the killable version of waits
returning an error code as you unwind, and eventually either
force_sig(SIGKILL) or do_exit().

There are a lot of times where you can support SIGKILL and just cause
the process to exit where you can't handle signals.


Eric

Re: Kdump with signed images

[Mimi Zohar]

On Wed, 2012-11-14 at 21:09 -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
> > On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote:
> >> Vivek Goyal <vgoyal@redhat.com> writes:
> >> 
> >> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote:
> >> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> >> >> 
> >> >> [..]
> >> >> 
> >> >> Thnking more about executable signature verification, I have another question.
> >> >> 
> >> >> While verifyign the signature, we will have to read the whole executable
> >> >> in memory. That sounds bad as we are in kernel mode and will not be killed
> >> >> and if sombody is trying to execute a malformed exceptionally large
> >> >> executable, system will start killing other processess. We can potentially
> >> >> lock all the memory in kernel just by trying to execute a signed huge
> >> >> executable. Not good.
> >> >> 
> >> >
> >> > Also, even if we try to read in whole executable, can't an hacker modify
> >> > pages in swap disk and then they will be faulted back in and bingo hacker
> >> > is running its unsigned code. (assuming root has been compromised otherwise
> >> > why do we have to do all this exercise).
> >> 
> >> You make a decent case for an implicit mlockall(MCL_FUTURE) being
> >> required of signed executables, that are going to be granted privileges
> >> based on signature verification.
> >
> > implicity lockall for signed executables sounds reasonable to avoid the
> > swap hack.
> >
> >> 
> >> As for size if the executable won't fit in memory, there is no point in
> >> checking the signature.
> >
> > Well I am worried about malformed executables. One can sign a huge
> > executable (which is never meant to run successfully) and cause all
> > kind of memory issues. 
> 
> Good point what to do with executables with invalid sigantures.  From
> another reply it sounded like one of the bits of IMA/EVM had already
> addressed part of that.

With IMA-appraisal enabled (enforcing mode), it would not be executed.

> > Can we first look at the signature, decrypt it using certificates in
> > kernel ring, and if we find out that executable was signed by any
> > of the certificates, only then we go on to read in whole executable
> > and try to calculate the digest. May be at the time of signing we can put
> >  a string, say "LINUX", along with digest and then sing/encrypt it. Upon
> > decryption we can check if LINUX is there and if yes, we know it was
> > signed by the certifcate loaded in kernel and then go on to load the
> > full executable and calculate digest.
> 
> > Not sure if above is doable or not but if it is, it might reduce the
> > risk significantly as we will not try to integrity verify executables
> > not signed by genuine certificates.
> 
> Known plaintext in the signed blob should allow that.  I would be very
> careful with that because it sounds like the kind of thing that opens
> you up to plain-text attacks, but that is mostly my parania and lack of
> experience speaking.

Although IMA (measurement and attestation), IMA-appraisal (local
integrity enforcement), and IMA auditing (logging hashes) can be enabled
individually, if any of these functions are enabled, then assuming the
file is in the IMA policy, the file will be hashed.  Remember if all
else fails, measurement and attestation is your last line of defense,
for detecting if your system has been compromised.

Mimi

> >> It should be fairly straight forward to make the signature checking
> >> process preemptable and killable.
> >
> > hmm..., not sure how to do this. Will have to read more code to understand
> > process killing and see what can I do this while I am in kernel mode
> > and I possibly might have done kernel memory allocations using
> > vmalloc()/kmalloc() etc.
> 
> Well basically it is matter of using the killable version of waits
> returning an error code as you unwind, and eventually either
> force_sig(SIGKILL) or do_exit().
> 
> There are a lot of times where you can support SIGKILL and just cause
> the process to exit where you can't handle signals.
> 
> 
> Eric
> 

Re: Kdump with signed images

[Mimi Zohar]

On Thu, 2012-11-08 at 14:40 -0500, Vivek Goyal wrote:
> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote:
> 
> [..]
> 
> Thnking more about executable signature verification, I have another question.
> 
> While verifyign the signature, we will have to read the whole executable
> in memory. That sounds bad as we are in kernel mode and will not be killed
> and if sombody is trying to execute a malformed exceptionally large
> executable, system will start killing other processess. We can potentially
> lock all the memory in kernel just by trying to execute a signed huge
> executable. Not good.
> 
> I was looking at IMA and they seem to be using kernel_read() for reading
> page in and update digest. IIUC, that means page is read from disk,
> brought in cache and if needed will be read back from disk. But that
> means hacker can try to do some timing tricks and try to replace disk image
> after signature verification and run unsigned program.

For the reason you mentioned, the signature verification is deferred to
bprm, after the executable has been locked from modification.  Any
subsequent changes to the file would cause the file to be re-appraised.

The goal of EVM/IMA-appraisal is to detect file tampering and enforce
file data/metadata integrity.  If EVM/IMA-appraisal fail, then as a last
resort, we fall back and rely on IMA measurement/attestation at least to
detect it.

Mimi

> So how do we go about it. Neither of the approaches sound appealing
> to me.
> 
> Thanks
> Vivek

Re: Kdump with signed images

[Vivek Goyal]

On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote:
> On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote:
> > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote:
> > 
> > [..]
> > > > 
> > > > > - So say we can sign /sbin/kexec at build time and distros can do that.
> > > > > - Verify the signature at exec time using kernel keyring and if
> > > > >   verification happens successfully, say process gains extra capability.
> > > > > - Use this new capability to determine whether kexec_load() will be
> > > > >   successful or not.
> > > > > 
> > > > > Even if we can do all this, it still has the issue of being able to
> > > > > stop the process in user space and replace the code at run time
> > > > > and be able to launch unsigned kernel.
> > > 
> > > Thinking more about it. Can we just keep track whether a process was
> > > ptraced or not and disallow kexec_load() syscall if it was ptraced.
> > > (I am assuming that ptrace is the only way to change process code/data).
> > > 
> > > So binaries can be signed offline. Signature verification can take place
> > > using kernel keyring at exec() time. And we can keep track of ptraced
> > > processes and disallow calling kexec_load() for such processes. If this
> > > is implementable, this should take care of following requirement raised
> > > by matthew.
> > > 
> > > ************************************************************************
> > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't
> > > been signed by a trusted key that's been built into the kernel, and it
> > > must be impossible for anything other than /sbin/kexec to make the kexec
> > > system call.
> > > *************************************************************************
> > > 
> > > Thoughts?
> > 
> > Eric responded but my mistake he responded to only me. So I will quickly 
> > put his idea here.
> > 
> > [start quote]
> > 
> > You can't ptrace a process that has a capability you don't.
> > 
> > That should be enforced in security/commoncap/
> > 
> > [end quote]
> > 
> > This looks like a good idea. Upon verification signed binaries will be
> > assigned special capability and then no unsigned binary should be able
> > to ptrace signed/verified processes
> 
> That's a good generic solution, which I'm all in favor of, but it
> doesn't resolve the latter half of Matthrew's requirement "and it must
> be impossible for anything other than /sbin/kexec to make the kexec
> system call."

I think what matthew might have meant that anything other than signed
trusted executable should not be able to call kexec_load(). Matthew?

And if one wants only /sbin/kexec to call it, then just sign that
one so no other executable will be able to call kexec_load(). Though
I don't think that's the requirement here. Requirement is that only
trusted executables should be able to call kexec_load().

Thanks
Vivek

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:

> And if one wants only /sbin/kexec to call it, then just sign that
> one so no other executable will be able to call kexec_load(). Though
> I don't think that's the requirement here. Requirement is that only
> trusted executables should be able to call kexec_load().

Where "trusted executables" means "signed by a key that's present in the 
system firmware or in the kernel that's signed with a key that's present 
in the system firmware", sure.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kdump with signed images

[Khalid Aziz]

On Thu, 2012-11-01 at 14:57 +0000, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
> 
> > And if one wants only /sbin/kexec to call it, then just sign that
> > one so no other executable will be able to call kexec_load(). Though
> > I don't think that's the requirement here. Requirement is that only
> > trusted executables should be able to call kexec_load().
> 
> Where "trusted executables" means "signed by a key that's present in the 
> system firmware or in the kernel that's signed with a key that's present 
> in the system firmware", sure.
> 

This is starting to sound too restrictive (even though I understand the
rationale behind the restrictions). Does this allow for a custom
userspace application that among other things also can kexec_load() a
new kernel and boot it, for example a customer unique health monitoring
app that reboots the system if things are not looking right on the
running system? How would a customer go about getting that userspace
binary signed and re-signed every time they update their app? There is
the option of turning the whole SecureBoot thing off for a system like
that but let us assume customer wants to leave that on or does not have
the option to turn it off?

--
Khalid

Re: Kdump with signed images

[Matthew Garrett]

On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> On Thu, 2012-11-01 at 14:57 +0000, Matthew Garrett wrote:
> > On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
> > 
> > > And if one wants only /sbin/kexec to call it, then just sign that
> > > one so no other executable will be able to call kexec_load(). Though
> > > I don't think that's the requirement here. Requirement is that only
> > > trusted executables should be able to call kexec_load().
> > 
> > Where "trusted executables" means "signed by a key that's present in the 
> > system firmware or in the kernel that's signed with a key that's present 
> > in the system firmware", sure.
> > 
> 
> This is starting to sound too restrictive (even though I understand the
> rationale behind the restrictions). Does this allow for a custom
> userspace application that among other things also can kexec_load() a
> new kernel and boot it, for example a customer unique health monitoring
> app that reboots the system if things are not looking right on the
> running system?

Only if it's signed with a key that the kernel trusts.

> How would a customer go about getting that userspace binary signed and 
> re-signed every time they update their app? There is the option of 
> turning the whole SecureBoot thing off for a system like that but let 
> us assume customer wants to leave that on or does not have the option 
> to turn it off?

There's ongoing work for providing mechanisms for trusting user keys. If 
you want Secure Boot turned on, you don't want any untrusted code 
running in your kernel. If you're happy with untrusted code in your 
kernel, why are you using Secure Boot?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kdump with signed images

[Khalid Aziz]

On Thu, 2012-11-01 at 16:23 +0000, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> > How would a customer go about getting that userspace binary signed and 
> > re-signed every time they update their app? There is the option of 
> > turning the whole SecureBoot thing off for a system like that but let 
> > us assume customer wants to leave that on or does not have the option 
> > to turn it off?
> 
> There's ongoing work for providing mechanisms for trusting user keys. If 
> you want Secure Boot turned on, you don't want any untrusted code 
> running in your kernel. If you're happy with untrusted code in your 
> kernel, why are you using Secure Boot?
> 

I would argue code written by a customer to run on their own systems is
inherently trusted code and does not invalidate need/desire for Secure
Boot. So the customer will still need some way to get their binary
signed very painlessly just so they could use their own binary on their
own system, simply because of a heavily locked down system design by
Linux community.

--
Khalid

Re: Kdump with signed images

[Mimi Zohar]

On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
> 
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute.  The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key. 
> 
> The idea isn't to prevent /sbin/kexec from being modified after 
> installation - it's to prevent it from being possible to install a 
> system that has a modified /sbin/kexec.

Understood.

>  Leaving any part of this up to 
> the package installer means that it doesn't solve the problem we're 
> trying to solve here. It must be impossible for the kernel to launch any 
> /sbin/kexec that hasn't been signed by a trusted key that's been built 
> into the kernel, 

With Dmitry's patch "5e0d1a4 ima: added policy support for security.ima
type", or something similar, we can force 'security.ima' to a specific
type, in this case, a digital signature.  With that patch, this
shouldn't be a problem.

> and it must be impossible for anything other than 
> /sbin/kexec to make the kexec system call.

Permission is a MAC issue. :)

thanks,

Mimi

Re: Kdump with signed images

[Matthew Garrett]

On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote:
> On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
> > and it must be impossible for anything other than 
> > /sbin/kexec to make the kexec system call.
> 
> Permission is a MAC issue. :)

It's a MAC issue that has to be implemented in the kernel. We can't 
depend on userspace loading any kind of policy.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kdump with signed images

[Mimi Zohar]

On Fri, 2012-10-26 at 19:19 +0100, Matthew Garrett wrote:
> On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote:
> > On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote:
> > > and it must be impossible for anything other than 
> > > /sbin/kexec to make the kexec system call.
> > 
> > Permission is a MAC issue. :)
> 
> It's a MAC issue that has to be implemented in the kernel. We can't 
> depend on userspace loading any kind of policy.

Still a MAC issue, that problably could be addressed by capabilities.  I
suggest you post this issue on the LSM mailing list.  Please cc: Serge,
as the capabilities maintainer.

thanks,

Mimi

Re: [RFC] Kdump with signed images

[Vivek Goyal]

On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg@redhat.com> writes:
> 
> > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> >
> >> But what about creation of a new program which can call kexec_load()
> >> and execute an unsigned kernel. Doesn't look like that will be
> >> prevented using IMA.
> >
> > Right. Trusting userspace would require a new system call that passes in 
> > a signature of the userspace binary, and the kernel would then have to 
> > verify the ELF object in memory in order to ensure that it 
> > matches the signature. Verifying that the copy on the filesystem is 
> > unmodified isn't adequate - an attacker could simply have paused the 
> > process and injected code. 
> 
> Verifying the copy on the filesystem at exec time is perfectly adequate
> for gating extra permissions.  Certainly that is the model everywhere
> else in the signed key chain.
> 
> Where IMA falls short is there is no offline signing capability in IMA
> itself.  I think EVM may fix that.

[ CCing lkml. I think it is a good idea to open discussion to wider
audience. Also CCing IMA/EVM folks ]

Based on reading following wiki page, looks like EVM also does not allow
offline signing capability. And EVM is protecting IMA data to protect
against offline attack. If we can assume that unisgned kernels can't be
booted on the platform, then EVM might not be a strict requirement in
this case.

So as you said, one of the main problem with IMA use to verify /sbin/kexec
is that IMA does not provide offline signing capability.

> 
> > Realistically, the only solution here is for 
> > the kernel to verify that the kernel it's about to boot is signed and 
> > for it not to take any untrusted executable code from userspace.
> 
> Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> perfectly reasonable, and realistic.  In fact finding a way to trust
> small bits of userspace even if root is compromised seems a far superior
> model to simply solving the signing problem for /sbin/kexec.
> 
> Although I do admit some part of the kexec process will need to verify
> keys on the images we decide to boot.

It should be an option, isn't it? Either /sbin/kexec can try to verify the
integrity of kernel or we extend try to extend kexec() system call to also
pass the signature of kernel and let kernel verify it (as you mentioned
previously).

Thanks
Vivek

Re: [RFC] Kdump with signed images

[Mimi Zohar]

On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> > Matthew Garrett <mjg@redhat.com> writes:
> > 
> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> > >
> > >> But what about creation of a new program which can call kexec_load()
> > >> and execute an unsigned kernel. Doesn't look like that will be
> > >> prevented using IMA.

Like the existing kernel modules, kexec_load() is not file descriptor
based.  There isn't an LSM or IMA-appraisal hook here.

> > > Right. Trusting userspace would require a new system call that passes in 
> > > a signature of the userspace binary, and the kernel would then have to 
> > > verify the ELF object in memory in order to ensure that it 
> > > matches the signature. Verifying that the copy on the filesystem is 
> > > unmodified isn't adequate - an attacker could simply have paused the 
> > > process and injected code. 

I haven't looked at kexec_load() in detail, but like kernel modules, I
think the better solution would be to pass a file descriptor, especially
if you're discussing a new system call.  (cc'ing Kees.)

> > Verifying the copy on the filesystem at exec time is perfectly adequate
> > for gating extra permissions.  Certainly that is the model everywhere
> > else in the signed key chain.
> > 
> > Where IMA falls short is there is no offline signing capability in IMA
> > itself.  I think EVM may fix that.

I'm not sure what you mean by offline signing capability.  IMA-appraisal
verifies a file's 'security.ima' xattr, which may contain a hash or a
digital signature.  EVM protects a file's metadata, including
'security.ima'.  'security.evm' can be either an hmac or a digital
signature.

> [ CCing lkml. I think it is a good idea to open discussion to wider
> audience. Also CCing IMA/EVM folks ]

thanks!

> Based on reading following wiki page, looks like EVM also does not allow
> offline signing capability. And EVM is protecting IMA data to protect
> against offline attack. If we can assume that unisgned kernels can't be
> booted on the platform, then EVM might not be a strict requirement in
> this case.

> So as you said, one of the main problem with IMA use to verify /sbin/kexec
> is that IMA does not provide offline signing capability.

?
 
> > 
> > > Realistically, the only solution here is for 
> > > the kernel to verify that the kernel it's about to boot is signed and 
> > > for it not to take any untrusted executable code from userspace.

>From an IMA, as opposed to an IMA-appraisal, perspective, kexec is
problematic.  IMA maintains a measurement list and extends a PCR with
the file hash.  The measurement list and PCR value are used to attest to
the integrity of the running system.  As the original measurement list
is lost after kexec, but the PCR value hasn't been reset, the
measuremnet list and PCR value won't agree.

> > Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> > perfectly reasonable, and realistic.  In fact finding a way to trust
> > small bits of userspace even if root is compromised seems a far superior
> > model to simply solving the signing problem for /sbin/kexec.

Huh?  I don't understand what you're suggesting.  Once root has been
compromised, that's it.

> > Although I do admit some part of the kexec process will need to verify
> > keys on the images we decide to boot.

Which keys?  Isn't the kernel module key builtin to the kernel and
included in the kernel image signature?

> It should be an option, isn't it? Either /sbin/kexec can try to verify the
> integrity of kernel or we extend try to extend kexec() system call to also
> pass the signature of kernel and let kernel verify it (as you mentioned
> previously).
> 
> Thanks
> Vivek
> 

As suggested above, please consider passing a file descriptor, at least
in addition, if not in lieu of a signature.

thanks,

Mimi

Re: [RFC] Kdump with signed images

[Kees Cook]

On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
>> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
>> > Matthew Garrett <mjg@redhat.com> writes:
>> >
>> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
>> > >
>> > >> But what about creation of a new program which can call kexec_load()
>> > >> and execute an unsigned kernel. Doesn't look like that will be
>> > >> prevented using IMA.
>
> Like the existing kernel modules, kexec_load() is not file descriptor
> based.  There isn't an LSM or IMA-appraisal hook here.
>
>> > > Right. Trusting userspace would require a new system call that passes in
>> > > a signature of the userspace binary, and the kernel would then have to
>> > > verify the ELF object in memory in order to ensure that it
>> > > matches the signature. Verifying that the copy on the filesystem is
>> > > unmodified isn't adequate - an attacker could simply have paused the
>> > > process and injected code.
>
> I haven't looked at kexec_load() in detail, but like kernel modules, I
> think the better solution would be to pass a file descriptor, especially
> if you're discussing a new system call.  (cc'ing Kees.)

Yeah, it looks like kexec_load could use a nearly identical new
syscall that uses an fd, just like init_module is getting.

Another area, kind of related, is firmware loading. The interface for
that is a bit weird, if the documentation is up to date:

        echo 1 > /sys/$DEVPATH/loading
        cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data
        echo 0 > /sys/$DEVPATH/loading

It looks like there's a filp on the reader:

static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj,
                                  struct bin_attribute *bin_attr,
                                  char *buffer, loff_t offset, size_t count)

But it's not clear to me yet if we'll actually get the firmware file,
or if we'll get a random pipe we can't evaluate. Has anyone looked at
handling "signed" firmware loading yet?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [RFC] Kdump with signed images

[Mimi Zohar]

On Wed, 2012-10-24 at 23:44 -0700, Kees Cook wrote:
> On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> >> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> >> > Matthew Garrett <mjg@redhat.com> writes:
> >> >
> >> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> >> > >
> >> > >> But what about creation of a new program which can call kexec_load()
> >> > >> and execute an unsigned kernel. Doesn't look like that will be
> >> > >> prevented using IMA.
> >
> > Like the existing kernel modules, kexec_load() is not file descriptor
> > based.  There isn't an LSM or IMA-appraisal hook here.
> >
> >> > > Right. Trusting userspace would require a new system call that passes in
> >> > > a signature of the userspace binary, and the kernel would then have to
> >> > > verify the ELF object in memory in order to ensure that it
> >> > > matches the signature. Verifying that the copy on the filesystem is
> >> > > unmodified isn't adequate - an attacker could simply have paused the
> >> > > process and injected code.
> >
> > I haven't looked at kexec_load() in detail, but like kernel modules, I
> > think the better solution would be to pass a file descriptor, especially
> > if you're discussing a new system call.  (cc'ing Kees.)
> 
> Yeah, it looks like kexec_load could use a nearly identical new
> syscall that uses an fd, just like init_module is getting.
> 
> Another area, kind of related, is firmware loading. The interface for
> that is a bit weird, if the documentation is up to date:
> 
>         echo 1 > /sys/$DEVPATH/loading
>         cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data
>         echo 0 > /sys/$DEVPATH/loading
> 
> It looks like there's a filp on the reader:
> 
> static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj,
>                                   struct bin_attribute *bin_attr,
>                                   char *buffer, loff_t offset, size_t count)
> 
> But it's not clear to me yet if we'll actually get the firmware file,
> or if we'll get a random pipe we can't evaluate. Has anyone looked at
> handling "signed" firmware loading yet?
> 
> -Kees

Only looked at it enough to mention at LSS, that it's needed.

Mimi

Re: [RFC] Kdump with signed images

[Vivek Goyal]

On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote:
> On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> > > Matthew Garrett <mjg@redhat.com> writes:
> > > 
> > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> > > >
> > > >> But what about creation of a new program which can call kexec_load()
> > > >> and execute an unsigned kernel. Doesn't look like that will be
> > > >> prevented using IMA.
> 
> Like the existing kernel modules, kexec_load() is not file descriptor
> based.  There isn't an LSM or IMA-appraisal hook here.
> 
> > > > Right. Trusting userspace would require a new system call that passes in 
> > > > a signature of the userspace binary, and the kernel would then have to 
> > > > verify the ELF object in memory in order to ensure that it 
> > > > matches the signature. Verifying that the copy on the filesystem is 
> > > > unmodified isn't adequate - an attacker could simply have paused the 
> > > > process and injected code. 
> 
> I haven't looked at kexec_load() in detail, but like kernel modules, I
> think the better solution would be to pass a file descriptor, especially
> if you're discussing a new system call.  (cc'ing Kees.)

If we decide to go for a new system call, then yes it looks like passing
fd will make sense.

> 
> > > Verifying the copy on the filesystem at exec time is perfectly adequate
> > > for gating extra permissions.  Certainly that is the model everywhere
> > > else in the signed key chain.
> > > 
> > > Where IMA falls short is there is no offline signing capability in IMA
> > > itself.  I think EVM may fix that.
> 
> I'm not sure what you mean by offline signing capability.  IMA-appraisal
> verifies a file's 'security.ima' xattr, which may contain a hash or a
> digital signature.  EVM protects a file's metadata, including
> 'security.ima'.  'security.evm' can be either an hmac or a digital
> signature.

By offline we mean that signature generation/signing does not happen on
system in question. It happens say on build time. IIUC, in case of IMA,
security.ima is generated and signed on the system and that means private
key needs to be present on the system? 

We wanted something like module signing where modules are signed at
build time and verification happens at load time but no private key
needs to be present on the system.

> 
> > [ CCing lkml. I think it is a good idea to open discussion to wider
> > audience. Also CCing IMA/EVM folks ]
> 
> thanks!
> 
> > Based on reading following wiki page, looks like EVM also does not allow
> > offline signing capability. And EVM is protecting IMA data to protect
> > against offline attack. If we can assume that unisgned kernels can't be
> > booted on the platform, then EVM might not be a strict requirement in
> > this case.
> 
> > So as you said, one of the main problem with IMA use to verify /sbin/kexec
> > is that IMA does not provide offline signing capability.
> 
> ?

See above.

>  
> > > 
> > > > Realistically, the only solution here is for 
> > > > the kernel to verify that the kernel it's about to boot is signed and 
> > > > for it not to take any untrusted executable code from userspace.
> 
> >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is
> problematic.  IMA maintains a measurement list and extends a PCR with
> the file hash.  The measurement list and PCR value are used to attest to
> the integrity of the running system.  As the original measurement list
> is lost after kexec, but the PCR value hasn't been reset, the
> measuremnet list and PCR value won't agree.
> 
> > > Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> > > perfectly reasonable, and realistic.  In fact finding a way to trust
> > > small bits of userspace even if root is compromised seems a far superior
> > > model to simply solving the signing problem for /sbin/kexec.
> 
> Huh?  I don't understand what you're suggesting.  Once root has been
> compromised, that's it.
> 
> > > Although I do admit some part of the kexec process will need to verify
> > > keys on the images we decide to boot.
> 
> Which keys?  Isn't the kernel module key builtin to the kernel and
> included in the kernel image signature?

I think Eric is referring to verifying bzImage signature. One can sign
PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec
verify the integrity/authenticity of bzImage and figure a way out to
verify integrity/authenticity of /sbin/kexec.

That way one does not have to change current logic and most of the logic
of kexec/kdump can still be in user space. Otherwise we shall probably
have to implement a new system call which takes kernel and initrd as
input parameters and kernel does signature verification and prepares
bzImage for loading. This is like re-writing kexec/kdump again with
restricted functionality.

Thanks
Vivek

Re: [RFC] Kdump with signed images

[Mimi Zohar]

On Thu, 2012-10-25 at 09:54 -0400, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote:
> > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote:
> > > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote:
> > > > Matthew Garrett <mjg@redhat.com> writes:
> > > > 
> > > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> > > > >
> > > > >> But what about creation of a new program which can call kexec_load()
> > > > >> and execute an unsigned kernel. Doesn't look like that will be
> > > > >> prevented using IMA.
> > 
> > Like the existing kernel modules, kexec_load() is not file descriptor
> > based.  There isn't an LSM or IMA-appraisal hook here.
> > 
> > > > > Right. Trusting userspace would require a new system call that passes in 
> > > > > a signature of the userspace binary, and the kernel would then have to 
> > > > > verify the ELF object in memory in order to ensure that it 
> > > > > matches the signature. Verifying that the copy on the filesystem is 
> > > > > unmodified isn't adequate - an attacker could simply have paused the 
> > > > > process and injected code. 
> > 
> > I haven't looked at kexec_load() in detail, but like kernel modules, I
> > think the better solution would be to pass a file descriptor, especially
> > if you're discussing a new system call.  (cc'ing Kees.)
> 
> If we decide to go for a new system call, then yes it looks like passing
> fd will make sense.
> 
> > 
> > > > Verifying the copy on the filesystem at exec time is perfectly adequate
> > > > for gating extra permissions.  Certainly that is the model everywhere
> > > > else in the signed key chain.
> > > > 
> > > > Where IMA falls short is there is no offline signing capability in IMA
> > > > itself.  I think EVM may fix that.
> > 
> > I'm not sure what you mean by offline signing capability.  IMA-appraisal
> > verifies a file's 'security.ima' xattr, which may contain a hash or a
> > digital signature.  EVM protects a file's metadata, including
> > 'security.ima'.  'security.evm' can be either an hmac or a digital
> > signature.
> 
> By offline we mean that signature generation/signing does not happen on
> system in question. It happens say on build time. IIUC, in case of IMA,
> security.ima is generated and signed on the system and that means private
> key needs to be present on the system? 

The signature for 'security.ima' can definitely be created offline.
'security.evm' can also be created offline, as long as the target's
inode and other metadata doesn't change.

> We wanted something like module signing where modules are signed at
> build time and verification happens at load time but no private key
> needs to be present on the system.

Modules are identifiable.  As long as you have some mechanism to
identify mutable vs immutable files during build, there shouldn't be a
problem.  I'd use the same private key for signing modules and all
others.

> > 
> > > [ CCing lkml. I think it is a good idea to open discussion to wider
> > > audience. Also CCing IMA/EVM folks ]
> > 
> > thanks!
> > 
> > > Based on reading following wiki page, looks like EVM also does not allow
> > > offline signing capability. And EVM is protecting IMA data to protect
> > > against offline attack. If we can assume that unisgned kernels can't be
> > > booted on the platform, then EVM might not be a strict requirement in
> > > this case.
> > 
> > > So as you said, one of the main problem with IMA use to verify /sbin/kexec
> > > is that IMA does not provide offline signing capability.
> > 
> > ?
> 
> See above.
> 
> >  
> > > > 
> > > > > Realistically, the only solution here is for 
> > > > > the kernel to verify that the kernel it's about to boot is signed and 
> > > > > for it not to take any untrusted executable code from userspace.
> > 
> > >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is
> > problematic.  IMA maintains a measurement list and extends a PCR with
> > the file hash.  The measurement list and PCR value are used to attest to
> > the integrity of the running system.  As the original measurement list
> > is lost after kexec, but the PCR value hasn't been reset, the
> > measuremnet list and PCR value won't agree.
> > 
> > > > Hogwash.  The kernel verifing a signature of /sbin/kexec at exec time is
> > > > perfectly reasonable, and realistic.  In fact finding a way to trust
> > > > small bits of userspace even if root is compromised seems a far superior
> > > > model to simply solving the signing problem for /sbin/kexec.
> > 
> > Huh?  I don't understand what you're suggesting.  Once root has been
> > compromised, that's it.
> > 
> > > > Although I do admit some part of the kexec process will need to verify
> > > > keys on the images we decide to boot.
> > 
> > Which keys?  Isn't the kernel module key builtin to the kernel and
> > included in the kernel image signature?
> 
> I think Eric is referring to verifying bzImage signature. One can sign
> PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec
> verify the integrity/authenticity of bzImage and figure a way out to
> verify integrity/authenticity of /sbin/kexec.

Yes that would work.  IMA-appraisal/EVM would verify and enforce the
integrity of /sbin/kexec, like any other file.  Verifying the signature
of the kernel image itself could be left up to kexec.

> That way one does not have to change current logic and most of the logic
> of kexec/kdump can still be in user space. Otherwise we shall probably
> have to implement a new system call which takes kernel and initrd as
> input parameters and kernel does signature verification and prepares
> bzImage for loading. This is like re-writing kexec/kdump again with
> restricted functionality.
> 
> Thanks
> Vivek
> 

>From an attestation perspective, it would be better to add a new hook to
measure the kernel image and append the measurement to the IMA
measurement list.  With the new hook, the integrity of the kernel image
could be enforced.   I assume you realize that calculating a hash
requires reading the entire file.

thanks,

Mimi

Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting)

[Vivek Goyal]

On Tue, Oct 23, 2012 at 04:41:24PM +0100, Matthew Garrett wrote:
> On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> 
> > But what about creation of a new program which can call kexec_load()
> > and execute an unsigned kernel. Doesn't look like that will be
> > prevented using IMA.
> 
> Right. Trusting userspace would require a new system call that passes in 
> a signature of the userspace binary, and the kernel would then have to 
> verify the ELF object in memory in order to ensure that it 
> matches the signature.

[ CC lkml and IMA/EVM developers ]

Not sure how much of this is feasible. There is initialized data which
can change. That means we shall have to exclude initialized data from
digest. And then initialized data can be changed by attacker.

I think in the context of kexec, purgatory (which is actually a
relocatable executable), is embedded in kexec binary as "const char
purgatory[]". I am assuming that it will show up as initialized data
in /sbin/kexec. And if we do not include initialized data in digest
calculation, then one can overwrite purgatory with its own executable
code and kexec will load it into the kernel and let it run at priviliged
level.

So looks like even above will not be foolproof. (Assuming we can do
this. I thought we lost all the elf headers after loading elf 
binary and now we don't know which mmpaed areas need to be included
in digest and which should not be).
 
> Verifying that the copy on the filesystem is 
> unmodified isn't adequate - an attacker could simply have paused the 
> process and injected code.

This is an interesting point. So even if we verify the signature of
/sbin/kexec, parent can change the code (using ptrace() interface?).
And we are again prone to attack. So this will work if we are doing
integrity/authenticity checks on all root processes and not just
one /sbin/kexec.

> Realistically, the only solution here is for 
> the kernel to verify that the kernel it's about to boot is signed and 
> for it not to take any untrusted executable code from userspace.

Hmm.., given above, looks like implementing a new system call to pass
in full kernel and initramfs (along with some command line or other
parameters), becomes interesting.

Thanks
Vivek