kdump: pass acpi_rsdp= to 2nd kernel for efi booting

In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve the acpi root table physical address.

Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab If there's no such file or read fail the function will just do nothing.

Tested efi boot Fedora 17 on thinkpad T420.

Some background info for this issue:
http://lists.infradead.org/pipermail/kexec/2010-March/003889.html

[v1 -> v2]:
Address comments from Khalid and Simon
use fgets instead of read(2) to iterate the file
do not add 'noefi' because kexec does not construct EFI signature in bootloader signature in boot_params, so kexec'd kernel will disable EFI automatically even without noefi.

Signed-off-by Dave Young <[email protected]>

---
 kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

Quoted 18 lines · Dave Young

In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve the acpi root table physical address.

Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab If there's no such file or read fail the function will just do nothing.

Tested efi boot Fedora 17 on thinkpad T420.

Some background info for this issue:
http://lists.infradead.org/pipermail/kexec/2010-March/003889.html

[v1 -> v2]:
Address comments from Khalid and Simon
use fgets instead of read(2) to iterate the file
do not add 'noefi' because kexec does not construct EFI signature in bootloader signature in boot_params, so kexec'd kernel will disable EFI automatically even without noefi.

Quoted 4 lines

Signed-off-by Dave Young <[email protected]>

---
 kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

Looks good.

Reviewed-by Khalid Aziz <[email protected]>

Quoted 25 lines · Khalid Aziz

Quoted 18 lines · Dave Young

In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve the acpi root table physical address.

Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab If there's no such file or read fail the function will just do nothing.

Tested efi boot Fedora 17 on thinkpad T420.

Some background info for this issue:
http://lists.infradead.org/pipermail/kexec/2010-March/003889.html

[v1 -> v2]:
Address comments from Khalid and Simon
use fgets instead of read(2) to iterate the file
do not add 'noefi' because kexec does not construct EFI signature in bootloader signature in boot_params, so kexec'd kernel will disable EFI automatically even without noefi.

Quoted 4 lines

Signed-off-by Dave Young <[email protected]>

---
 kexec/arch/i386/crashdump-x86.c |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

Quoted 3 lines

Looks good.

Reviewed-by Khalid Aziz <[email protected]>

Khalid/Dave,

Last time khalid mentioned that we are currently taking normal boot path in second kernel and that's why things are working even without "noefi"?

If that's the case, then we don't need "acpi_rsdp" also? In normal boot path we used to just pass acpi memmap ranges in e820 map and second kernel could find those.

So now I am full confused that howcome we require acpi_rsdp but not "noefi".

This UEFI thing is a mess. We need to sort it out. I am primarily interested in making sure kdump works well with UEFI systems as more and more systems are going to adopt UEFI. Also this UEFI secure boot will make things very interesting. Now we can't trust the purgatory code prepared in user space.

Thanks
Vivek

Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes life even more difficult. Matthew Garret had earlier sent out patches to support SecureBoot on Linux and one of the things those patches did was to disable kexec completely. That is a drastic measure and ok as a short term solution but we need to come up with something better. If SecureBoot does not go away, we will have to do something in kexec-tools or even kernel to validate kernel code being loaded for kexec/kdump and the purgatory code as well. This will require interfacing with UEFI key checking mechanism. That is going to be ugly.

I was thinking that how about supporting in kernel bootloader. That is, kernel acts as a boot loader. User passes the kernel, initrd and commandline from user space using kexec system call and kernel parses it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs, backup region, elf header region etc). At the time of kexec -e, we just follow th regular path and jump to second kernel.

At the time of loading, kernel can verify the signature of incoming bzImage and reject it if signatures don't match. Matthew mentioned that kernel signing certificate will be available inside the running kernel, so verifying PE/COFF bzImage should be easy.

There is one side issue of acpi_rsdp. Because second kernel executes the code specified by acpi_rsdp, it is unsafe to let user specify that location. Matthew metioned that figure a way out to pass acpi_rsdp using boot params and drop it from command line.

On Thu, Oct 18, 2012 at 01:22:01PM -0600, Khalid Aziz wrote:

[..]

Quoted 9 lines

Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes life even more difficult. Matthew Garret had earlier sent out patches to support SecureBoot on Linux and one of the things those patches did was to disable kexec completely. That is a drastic measure and ok as a short term solution but we need to come up with something better. If SecureBoot does not go away, we will have to do something in kexec-tools or even kernel to validate kernel code being loaded for kexec/kdump and the purgatory code as well. This will require interfacing with UEFI key checking mechanism. That is going to be ugly.

CCing Eric and Matthew Garret and hpa.

Ok, I will split this thread in two parts. Lets us quickly discuss the UEFI secure boot also as it is happening soon.

I was thinking that how about supporting in kernel bootloader. That is, kernel acts as a boot loader. User passes the kernel, initrd and commandline from user space using kexec system call and kernel parses it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs, backup region, elf header region etc). At the time of kexec -e, we just follow th regular path and jump to second kernel.

At the time of loading, kernel can verify the signature of incoming bzImage and reject it if signatures don't match. Matthew mentioned that kernel signing certificate will be available inside the running kernel, so verifying PE/COFF bzImage should be easy.

We don't have to worry about initramfs verification as it runs in user space.

There is one side issue of acpi_rsdp. Because second kernel executes the code specified by acpi_rsdp, it is unsafe to let user specify that location. Matthew metioned that figure a way out to pass acpi_rsdp using boot params and drop it from command line.

Looking for thoughts and ideas on how to support kdump with UEFI secureboot. (This is assuming that kdump already works with UEFI with parameters "noefi" and "acpi_rsdp" in non secure boot mode).

Quoted 13 lines · Vivek Goyal

On Thu, Oct 18, 2012 at 01:22:01PM -0600, Khalid Aziz wrote:

[..]

Quoted 9 lines

Yes, UEFI is a mess :) It does need to be sorted out. SecureBoot makes life even more difficult. Matthew Garret had earlier sent out patches to support SecureBoot on Linux and one of the things those patches did was to disable kexec completely. That is a drastic measure and ok as a short term solution but we need to come up with something better. If SecureBoot does not go away, we will have to do something in kexec-tools or even kernel to validate kernel code being loaded for kexec/kdump and the purgatory code as well. This will require interfacing with UEFI key checking mechanism. That is going to be ugly.

Quoted 4 lines

CCing Eric and Matthew Garret and hpa.

Ok, I will split this thread in two parts. Lets us quickly discuss the UEFI secure boot also as it is happening soon.

Any fimware secure boot solution fundamentally is about having the firmware not boot something that is not trusted. This reduces the area of attack in your firmware to your executable loader, your signature verification code and the key itself. Making your firmware and the early parts of the boot process less susceptible to attack. UEFI secure boot seems to match that criteria.

I am happy to see a similar system implemented in the kernel for the kexec boot path.

I do not support limiting that solution to UEFI systems or making the jusficiation UEFI systems. The code needs to make sense without any UEFI justifications.

Quoted 8 lines

I was thinking that how about supporting in kernel bootloader. That is, kernel acts as a boot loader. User passes the kernel, initrd and commandline from user space using kexec system call and kernel parses it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs, backup region, elf header region etc). At the time of kexec -e, we just follow th regular path and jump to second kernel.

Quoted 4 lines

At the time of loading, kernel can verify the signature of incoming bzImage and reject it if signatures don't match. Matthew mentioned that kernel signing certificate will be available inside the running kernel, so verifying PE/COFF bzImage should be easy.

Except that we don't pass the executable file to the kernel. That approach was nixed in the early review of kexec.

So we either need to
find a way to trust the /sbin/kexec binary

and do the signature
verification there on a per file type basis,

or we need to pass an
additional signature along with the code (the signature would be encoded with an extra kexec flag and a special purpose segment I expect).

If we pass the signature to the kernel for verification there are rough bits like how do file formats with relocation entries, the purgatory code, ramdisks, and kernel parameters.

Quoted 2 lines

We don't have to worry about initramfs verification as it runs in user space.

Except that we need a way to distinguish the initramfs and other data the part that is signed.

Quoted 5 lines

There is one side issue of acpi_rsdp. Because second kernel executes the code specified by acpi_rsdp, it is unsafe to let user specify that location. Matthew metioned that figure a way out to pass acpi_rsdp using boot params and drop it from command line.

The acpi_rsdp option is really orthogonal to this issue. Since everything comes from userspace the trust picture is essentially the same (unless we can find a way to trust /sbin/kexec).

But specifically for acpi_rdsp if we can figure out how to successfully use the EFI code path that should not be a problem. For other code paths shrug, that is a detail we should look at when we get there.

Quoted 3 lines

Looking for thoughts and ideas on how to support kdump with UEFI secureboot. (This is assuming that kdump already works with UEFI with parameters "noefi" and "acpi_rsdp" in non secure boot mode).

We don't support kdump with UEFI secure boot. We support kexec loading signed images. An important difference because it means that everyone can benefit or not as they choose.

This leaves us with a couple of important questions to answer.
- How do we trust /sbin/kexec or how do we avoid the need to trust /sbin/kexec.
- Where is the root of trust located?

- How do we verify /sbin/kexec or do we verify /sbin/kexec.
- How do we verify the images we load?
- How do we separate code/data that needs trust from code/data that doesn't need trust?

- How does the design we pick reduce the amount of code we need to trust?

None of this is particularly hard but it all needs going through carefully by someone who cares.

Quoted 13 lines

Quoted 12 lines

I was thinking that how about supporting in kernel bootloader. That is, kernel acts as a boot loader. User passes the kernel, initrd and commandline from user space using kexec system call and kernel parses it and prepares appropriate memory areas ( ex. boot_params, kernel, initramfs, backup region, elf header region etc). At the time of kexec -e, we just follow th regular path and jump to second kernel.

At the time of loading, kernel can verify the signature of incoming bzImage and reject it if signatures don't match. Matthew mentioned that kernel signing certificate will be available inside the running kernel, so verifying PE/COFF bzImage should be easy.

Quoted 2 lines

Except that we don't pass the executable file to the kernel. That approach was nixed in the early review of kexec.

Ok, this is the crux of this discussion. Why was passing executable image to kernel was rejected. What's wrong with it? We can pass the executable segments but not the executable image? Is it about keeping the file type handling code in user space?

Quoted 2 lines

So we either need to
find a way to trust the /sbin/kexec binary

This would be the key. How do we trust /sbin/kexec. We don't have any infrastrucutre to sign user space executables. Code for signing modules got just in after a long battle.

Quoted 2 lines

and do the signature
verification there on a per file type basis,

This will be possible only if we figure a way out to trust /sbin/kexec otherwise trust chain is broken.

Quoted 3 lines

or we need to pass an
additional signature along with the code (the signature would be encoded with an extra kexec flag and a special purpose segment I expect).

We can possibly pass the signature in separate segment but part of the verification process also involves calculating the digest of executable. And how digest is calculated depends on file type. For PE/Coff there is specific method regarding how to go about digest calculation and what area to include and what fields to exclude.

That means for kernel to do signature verification, we shall have to pass the full executable to kenrel as it is with PE/COFF headers and we are back to original idea of passing executables to kernel.

Quoted 7 lines

If we pass the signature to the kernel for verification there are rough bits like how do file formats with relocation entries, the purgatory code, ramdisks, and kernel parameters.

Quoted 2 lines

We don't have to worry about initramfs verification as it runs in user space.

Quoted 2 lines

Except that we need a way to distinguish the initramfs and other data the part that is signed.

If we are ok with the idea of passing executables and initramfs to kernel, then kernel can do the placement. That means fields "mem and memsz fields of kexec_segment will be free. We can possibly overload memsz field and pass flags to represent segment type. This will happen only if user chooses kernel as bootloader functionality.

Quoted 4 lines

This leaves us with a couple of important questions to answer.
- How do we trust /sbin/kexec or how do we avoid the need to trust /sbin/kexec.
- Where is the root of trust located?

I think it is either in UEFI or in kernel.

Quoted 4 lines

- How do we verify /sbin/kexec or do we verify /sbin/kexec.
- How do we verify the images we load?
- How do we separate code/data that needs trust from code/data that doesn't need trust?

If we agree on passing executable to kernel, then we just need to verify only kernel. And we could overload kexec_segment->mem for this.

Quoted 2 lines

- How does the design we pick reduce the amount of code we need to trust?

I think if we loading in kernel, then we don't have to trust /sbin/kexec and problem gets simplified a lot.

Quoted 2 lines

None of this is particularly hard but it all needs going through carefully by someone who cares.

I think here crux of the matter is what's wrong with passing kernel executable to kernel for loading and verification.

Handling the file formats etc in kernel space in inflexible.

Given that what we load current at no time is exactly what is in the executable but is the executable plus it's ``arguments'' I have to agree with that assesment.

In practice we have all kinds of argument passing conventions and those conventions prevent the kernel from executing another linux kernel directly, even if we had the other pieces in place.

Not to mention things like the SHA512 checksum that we do to verify the kdump kernel has not been corrupted.

Quoted 7 lines

Quoted 3 lines

So we either need to
find a way to trust the /sbin/kexec binary

This would be the key. How do we trust /sbin/kexec. We don't have any infrastrucutre to sign user space executables. Code for signing modules got just in after a long battle.

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.

Quoted 5 lines

Quoted 4 lines

and do the signature
verification there on a per file type basis,

Quoted 2 lines

This will be possible only if we figure a way out to trust /sbin/kexec otherwise trust chain is broken.

Not so. When loading an executable in general we don't process relocation entries. Which means the bits in the file and the bits actually loaded in memory match. Since we are passing the bits through /sbin/kexec if we also pass through the signature bits all should be well.

Modulo argument passing.

If we can pass in two signed executable blobs we can also perform trusted argument conversions.

Quoted 5 lines

If we are ok with the idea of passing executables and initramfs to kernel, then kernel can do the placement. That means fields "mem and memsz fields of kexec_segment will be free. We can possibly overload memsz field and pass flags to represent segment type. This will happen only if user chooses kernel as bootloader functionality.

Which sounds nice initially but I don't think the notion of the kernel being a general purpose bootloader holds up to well. It doesn't provide an easy place to put all of the weird cases.

If we are going to pass in a file it probably makes sense to do a variation of kexec_load that passes in a file descriptor, a filename could work but I don't think we want those races.

But then we get how do we pass in a different kernel command line and an initrd. Things that were simple start quickly becoming complex.

So at this point my recommendation would be:

- Target images where the bits are passed straight through.

- Add support for passing the initial kernels parameters through to the kexec'd image.

- Add support for passing the executable image signed signature through to the kernel, and the conversion code signed signature through to the kernel.

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:

[..]

Quoted 2 lines

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

Thinking more about it, another not so clean proposal.

- So only non-signed executable code user space loads is purgatory. What if we get rid of purgatory and let kernel do the pugatory's job.

- purgatory seems to be doing few things. (atleast on x86_64).
1. Verifies the checksums of loaded segments.
2. Copies the backup region.
3. Prepares the environment for jumping into target executable. (32bit entry or real mode entry etc).

First should be easily doable in kernel. At load time kernel can calculate the checksum of loaded segments and can verify the chesum again before during execute time.

Second one should be doable too in kernel as kernel can copy the contents to backup region. Just that we shall have to introduce per segment flags so that user space can tell kernel that a particular segment is backup segment. (say KEXEC_BACKUP_SEGMENT).

Third one is most tricky as it requires passing extra information to kernel about what kind of setup to do before jumping to entry point. If we can define some generic per arch kexec flags to represent those states, then kernel can do the job.

Doing lots of things based on flags does not sound very clean to me. Over a period of time we will end up defining more flags as people come up with new situations. But at the same time it can simplify the problem a bit and one does not have to introduce an new system call.

Just a thought..., Still scratching my head on how to go about this signed image thing without too much of work.

On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:

[..]

Quoted 2 lines

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

Thinking more about it, another not so clean proposal.

Quoted 7 lines · Vivek Goyal

On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:

[..]

Quoted 2 lines

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

Thinking more about it, another not so clean proposal.

I have always assumed that purgatory can't be removed as doing so would break backwards compatibility.

Quoted 11 lines · Simon Horman

Quoted 7 lines · Vivek Goyal

On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote:

[..]

Quoted 2 lines

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

Thinking more about it, another not so clean proposal.

I have always assumed that purgatory can't be removed as doing so would break backwards compatibility.

Hi Simon,

I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system.

Quoted 4 lines

I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system.

Rubbish. Kexec works just fine today on a secure boot enabled system. Ignoring the nonsense that there is no such thing as a secure boot enabled linux system.

[..]

Quoted 8 lines

Quoted 4 lines

I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system.

Rubbish. Kexec works just fine today on a secure boot enabled system. Ignoring the nonsense that there is no such thing as a secure boot enabled linux system.

I think it is a security hole for the systems where we don't want to run unsigned priviliged code. So yes, it works as of today, but at some point of time we shall have to close this hole.

Thanks
Vivek

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

2012/10/23 Vivek Goyal <[email protected]>:

Quoted 12 lines · Eric W. Biederman

[..]

Quoted 8 lines

Quoted 4 lines

I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system.

Rubbish. Kexec works just fine today on a secure boot enabled system. Ignoring the nonsense that there is no such thing as a secure boot enabled linux system.

Quoted 7 lines

I think it is a security hole for the systems where we don't want to run unsigned priviliged code. So yes, it works as of today, but at some point of time we shall have to close this hole.

Thanks
Vivek

Signatures kernel & modules in general good for support reason. We can say for example that we support only signed kernel and signed modules for that kernel, so we are sure that this binaries match our source. But what is the reason of checking signatures in kexec? If you have root privileges then more likely you have access to boot loader or to physical machine (console, bios). Might be useful only for embedded things to prevent enthusiasts play with already manufactured devices.

On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:

[..]

Quoted 6 lines

Handling the file formats etc in kernel space in inflexible.

Given that what we load current at no time is exactly what is in the executable but is the executable plus it's ``arguments'' I have to agree with that assesment.

Quoted 3 lines

In practice we have all kinds of argument passing conventions and those conventions prevent the kernel from executing another linux kernel directly, even if we had the other pieces in place.

Can we pass all argument in one kexec segment and let associated image format handlers parse the arguments.

Quoted 2 lines

Not to mention things like the SHA512 checksum that we do to verify the kdump kernel has not been corrupted.

As we will be preparing all the segments intenally and also preparing the purgatory(or equivalent) in kernel, we can alaways calculate the checksum in kernel tool IOW, there is no reason that why can't we do existing verifications in kernel.

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

So we either need to
find a way to trust the /sbin/kexec binary

This would be the key. How do we trust /sbin/kexec. We don't have any infrastrucutre to sign user space executables. Code for signing modules got just in after a long battle.

Quoted 3 lines

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.

Adding signatures to ELF should be possible. I guess this is similar to signed PE/COFF images. Just that convention changes that how images are signed and where exactly signatures are stored.

I do see some references to elfsign and elfverify during search. Have not dived in to figure out what exactly they are.

I think bigger issue here is that creating that generic system of signing user space executables and kernel verifying it. Then we end up creating even more complicated and more locked down system.

Quoted 11 lines

Quoted 5 lines

Quoted 2 lines

and do the signature
verification there on a per file type basis,

This will be possible only if we figure a way out to trust /sbin/kexec otherwise trust chain is broken.

Not so. When loading an executable in general we don't process relocation entries. Which means the bits in the file and the bits actually loaded in memory match. Since we are passing the bits through /sbin/kexec if we also pass through the signature bits all should be well.

So are you saying that let /sbin/kexec still load all the segments. It will also load the attached signatures/certificates in a separate segment and kernel can calculate hash and do verification? If yes, few issues. here.

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

Quoted 4 lines

Modulo argument passing.

If we can pass in two signed executable blobs we can also perform trusted argument conversions.

Again lost here. Which two executable blobs you are referring to. One is signed kernel executable, which is other one.

[..]

Quoted 14 lines

Quoted 5 lines

If we are ok with the idea of passing executables and initramfs to kernel, then kernel can do the placement. That means fields "mem and memsz fields of kexec_segment will be free. We can possibly overload memsz field and pass flags to represent segment type. This will happen only if user chooses kernel as bootloader functionality.

Which sounds nice initially but I don't think the notion of the kernel being a general purpose bootloader holds up to well. It doesn't provide an easy place to put all of the weird cases.

If we are going to pass in a file it probably makes sense to do a variation of kexec_load that passes in a file descriptor, a filename could work but I don't think we want those races.

Quoted 2 lines

But then we get how do we pass in a different kernel command line and an initrd. Things that were simple start quickly becoming complex.

Expecting three segments as input. Kernel executable, initrd and one segment which contains all arguemnts (separated by new line) including command line. Will that be generic enough to cover all kind of cases?

[..]

Quoted 4 lines

So at this point my recommendation would be:

- Target images where the bits are passed straight through.

Quoted 6 lines

- Add support for passing the initial kernels parameters through to the kexec'd image.

- Add support for passing the executable image signed signature through to the kernel, and the conversion code signed signature through to the kernel.

What is conversion code here?

Are you referring to /sbin/kexec here which
breaks down kernel executables into segments? If yes, are you saying that sign /sbin/kexec and pass its signature along with kernel signature?

Quoted 2 lines

Can we pass all argument in one kexec segment and let associated image format handlers parse the arguments.

The issue is can we pass trusted arguments? Any kind of firmware callback ACPI, EFI, openfirmware etc needs to be in the trusted parameter set so it must come from a trusted location.

Unless we can trust the /sbin/kexec binary we can't trust pointers to executable code passed to us that we can not verify are safe.

Quoted 6 lines

Quoted 3 lines

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.

It just occurred to me there is a 4th approach we can take that seems interesting.

Have a system call where you pass in a signature of yourself, that will allow you to increase your set of capabilities. I am a good binary here is proof. I initially that it might be a complement to sys_kexec_load just for the kexec case but there is no reason to limit it.

Quoted 2 lines

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

The purgatory code would need to be signed. Which is why it is important to enable composition of signed pieces of code.

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 4 lines

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.

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.

Quoted 3 lines · Vivek Goyal

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.

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.

Quoted 6 lines · Matthew Garrett

Quoted 3 lines · Vivek Goyal

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.

Quoted 6 lines

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.

Quoted 4 lines

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.

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Matthew Garrett

Quoted 3 lines · Vivek Goyal

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 4 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 8 lines · Vivek Goyal

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Matthew Garrett

Quoted 3 lines · Vivek Goyal

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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.)

Quoted 20 lines · Mimi Zohar

Quoted 8 lines · Vivek Goyal

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Matthew Garrett

Quoted 3 lines · Vivek Goyal

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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.

Quoted 3 lines

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

Quoted 8 lines · Vivek Goyal

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Matthew Garrett

Quoted 3 lines · Vivek Goyal

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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.)

Quoted 5 lines

Quoted 5 lines

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.

Quoted 2 lines

Quoted 2 lines

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.

Quoted 3 lines

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

thanks!

Quoted 5 lines

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.

Quoted 2 lines

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.

?

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 4 lines

Quoted 4 lines

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.

Quoted 2 lines

Quoted 2 lines

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?

Quoted 20 lines · Mimi Zohar

Quoted 8 lines · Vivek Goyal

Quoted 7 lines · Eric W. Biederman

Quoted 5 lines · Matthew Garrett

Quoted 3 lines · Vivek Goyal

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 12 lines

Quoted 3 lines

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

thanks!

Quoted 5 lines

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.

Quoted 4 lines

Quoted 2 lines

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.

Quoted 24 lines

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

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.

Quoted 4 lines

Quoted 4 lines

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.

Quoted 2 lines

Quoted 2 lines

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

Quoted 2 lines

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

Quoted 3 lines · Vivek Goyal

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.

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.

On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:

[..]

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

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.

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.

Quoted 4 lines · Eric W. Biederman

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.

No. It's about ensuring that no untrusted code can be run before any OS kernel, which means that no untrusted code can run *in* any OS kernel.

Quoted 3 lines · Matthew Garrett

Quoted 2 lines · Eric W. Biederman

No. UEFI secure boot has absolutely nothing todo with this.

Quoted 5 lines

Quoted 2 lines

UEFI secure boot is about not being able to hijack the code EFI runs directly. Full stop.

No. It's about ensuring that no untrusted code can be run before any OS kernel, which means that no untrusted code can run *in* any OS kernel.

Hogwash.

Quoted 26 lines · Vivek Goyal

On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:

[..]

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 20 lines · Eric W. Biederman

Quoted 18 lines · Vivek Goyal

On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:

[..]

Quoted 14 lines

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 7 lines

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.

Quoted 3 lines

Quoted 3 lines

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.

Quoted 26 lines

Quoted 3 lines

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.

Quoted 4 lines

Quoted 4 lines

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.

Quoted 6 lines

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.

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

[..]

Quoted 4 lines

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

Quoted 11 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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?

Quoted 2 lines

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.

Quoted 12 lines · Mimi Zohar

Quoted 11 lines · Vivek Goyal

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

[..]

Quoted 4 lines

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?

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

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

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.

Quoted 4 lines · Mimi Zohar

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.

Quoted 4 lines · Mimi Zohar

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.

Quoted 7 lines · Matthew Garrett

Quoted 4 lines · Mimi Zohar

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.

Quoted 8 lines

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

Quoted 17 lines · Vivek Goyal

Quoted 15 lines · Matthew Garrett

Quoted 4 lines · Mimi Zohar

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.

Quoted 2 lines

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

Thanks for summarizing.

Quoted 9 lines

- 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.

Quoted 10 lines

Quoted 10 lines

- 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?

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

[..]

Quoted 21 lines

Quoted 10 lines

Quoted 10 lines

- 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.

Quoted 8 lines

************************************************************************
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

Quoted 44 lines · Vivek Goyal

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

[..]

Quoted 21 lines

Quoted 10 lines

Quoted 10 lines

- 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.

Quoted 8 lines

************************************************************************
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]

Quoted 3 lines

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."

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

Quoted 2 lines · Vivek Goyal

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.

Quoted 10 lines · Matthew Garrett

Quoted 2 lines · Vivek Goyal

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?

Quoted 28 lines · Vivek Goyal

Quoted 10 lines · Matthew Garrett

Quoted 2 lines · Vivek Goyal

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.

Quoted 2 lines

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.

Quoted 29 lines · Balbir Singh

Quoted 28 lines · Vivek Goyal

Quoted 10 lines · Matthew Garrett

Quoted 2 lines · Vivek Goyal

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.

Quoted 6 lines

Quoted 2 lines

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.

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.

Quoted 10 lines · Matthew Garrett

Quoted 2 lines · Vivek Goyal

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?

Quoted 28 lines · Vivek Goyal

Quoted 10 lines · Matthew Garrett

Quoted 2 lines · Vivek Goyal

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.

Quoted 1 line

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.

Quoted 4 lines · Eric W. Biederman

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 10 lines · Vivek Goyal

Quoted 4 lines · Eric W. Biederman

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.

Quoted 5 lines · Eric W. Biederman

Quoted 3 lines · Vivek Goyal

Quoted 2 lines · Eric W. Biederman

It needs to be checked but /sbin/kexec should not use any

functions that

Quoted 1 line

Quoted 1 line

Quoted 1 line

trigger nss switch. No user or password or host name lookup

should be

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

happening.

I also think that we don't call routines which trigger nss switch

but

Quoted 2 lines

Quoted 2 lines

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

Quoted 6 lines

Quoted 1 line

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

Quoted 10 lines · Vivek Goyal

Quoted 4 lines · Eric W. Biederman

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.

Quoted 13 lines · Eric W. Biederman

Quoted 10 lines · Vivek Goyal

Quoted 4 lines · Eric W. Biederman

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.

Quoted 4 lines

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.

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.

Quoted 4 lines · Vivek Goyal

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

[..]

Quoted 9 lines

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).

Quoted 15 lines · Vivek Goyal

Quoted 13 lines · 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.

Quoted 4 lines

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.

Quoted 17 lines · Eric W. Biederman

Quoted 15 lines · Vivek Goyal

Quoted 13 lines · 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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 1 line

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 34 lines · Vivek Goyal

Quoted 17 lines · Eric W. Biederman

Quoted 15 lines · Vivek Goyal

Quoted 13 lines · 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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 3 lines

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.

Quoted 8 lines

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.

Quoted 3 lines

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.

Quoted 7 lines

Quoted 2 lines

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

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

Quoted 44 lines · Vivek Goyal

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

[..]

Quoted 21 lines

Quoted 10 lines

Quoted 10 lines

- 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.

Quoted 8 lines

************************************************************************
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]

Quoted 3 lines

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."

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().

Quoted 4 lines · Vivek Goyal

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.

Quoted 11 lines · Matthew Garrett

Quoted 4 lines · Vivek Goyal

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?

Quoted 5 lines · Khalid Aziz

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?

Quoted 4 lines · Mimi Zohar

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.

Quoted 2 lines · Matthew Garrett

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

Permission is a MAC issue. :)

Quoted 5 lines · Mimi Zohar

Quoted 2 lines · Matthew Garrett

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.

On Mon, Oct 22, 2012 at 02:07:56PM -0700, Eric W. Biederman wrote:

[..]

Quoted 7 lines

Quoted 2 lines

Can we pass all argument in one kexec segment and let associated image format handlers parse the arguments.

The issue is can we pass trusted arguments? Any kind of firmware callback ACPI, EFI, openfirmware etc needs to be in the trusted parameter set so it must come from a trusted location.

I think parameters will include something like read only one and second kernel should be able to verify it. It should not be an executable code of any form. (like acpi_rsdp). I think this is similar to that we don't sign/verify kernel command line passed in a bootloader.

Quoted 2 lines

Unless we can trust the /sbin/kexec binary we can't trust pointers to executable code passed to us that we can not verify are safe.

Given the fact we allow user to specify command line, even if we sign /sbin/kexec, we have no way to trust it. IMO here we just need to make sure that input parameters/arguments can't lead one to execute arbitrary code.

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

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.

[..]

Quoted 7 lines

It just occurred to me there is a 4th approach we can take that seems interesting.

Have a system call where you pass in a signature of yourself, that will allow you to increase your set of capabilities. I am a good binary here is proof. I initially that it might be a complement to sys_kexec_load just for the kexec case but there is no reason to limit it.

If one presents its own signature, then anybody can copy and present that signature. There needs to be a mechanism to verify that you actually have the signature you are presenting (i mean digest of executable).

So above does not address that how that new system call will verify the signature/hash of process invoking system call.

Quoted 5 lines

Quoted 2 lines

- What happens to purgatory code. It is unsigned piece of code which runs in kernel?

The purgatory code would need to be signed. Which is why it is important to enable composition of signed pieces of code.

purgatory code is modified dynamically upon every invocation of kexec. That means there needs to be a mechanism to sign it after we are done with purgatory modification. But there are no signing keys available on the system. All the signing happens externally during build time. So we don't have the option of signing purgatory at run time.

Quoted 5 lines

purgatory code is modified dynamically upon every invocation of kexec. That means there needs to be a mechanism to sign it after we are done with purgatory modification. But there are no signing keys available on the system. All the signing happens externally during build time. So we don't have the option of signing purgatory at run time.

Hogwash.

The only significant modification we make to purgatory is relocation processing. That relocation processing is a convinience, not a necessity. Potentially we could move the relocation processing into purgatory itself.

Quoted 5 lines

If we are ok with the idea of passing executables and initramfs to kernel, then kernel can do the placement. That means fields "mem and memsz fields of kexec_segment will be free. We can possibly overload memsz field and pass flags to represent segment type. This will happen only if user chooses kernel as bootloader functionality.

Which sounds nice initially but I don't think the notion of the kernel being a general purpose bootloader holds up to well. It doesn't provide an easy place to put all of the weird cases.

If we are going to pass in a file it probably makes sense to do a variation of kexec_load that passes in a file descriptor, a filename could work but I don't think we want those races.

But then we get how do we pass in a different kernel command line and an initrd. Things that were simple start quickly becoming complex.

On Thu, Oct 18, 2012 at 08:36:19PM -0700, Eric W. Biederman wrote:

[..]

Quoted 10 lines

Quoted 5 lines

If we are ok with the idea of passing executables and initramfs to kernel, then kernel can do the placement. That means fields "mem and memsz fields of kexec_segment will be free. We can possibly overload memsz field and pass flags to represent segment type. This will happen only if user chooses kernel as bootloader functionality.

Which sounds nice initially but I don't think the notion of the kernel being a general purpose bootloader holds up to well. It doesn't provide an easy place to put all of the weird cases.

Quoted 3 lines

If we are going to pass in a file it probably makes sense to do a variation of kexec_load that passes in a file descriptor, a filename could work but I don't think we want those races.

Can we use execve() style filenames. I am not sure what races are you referring to.

Quoted 2 lines

But then we get how do we pass in a different kernel command line and an initrd. Things that were simple start quickly becoming complex.

Can we take more than one filename arguments. Maybe an array of filename arguements. And another array of arguments.

SYSCALL_DEFINE2(kexec2,
const char __user *const __user *, filenamev const char __user *const __user *, argv)

This will allow passing filenames of both kernel and initrd and also allow passing arguments. Arguments will also include command line.

Not asking user space to read in the file will help avoid loading one extra copy of kernel in memory.

One difference here is though that we will have to allocate kernel memory for full kernel image and full initd and if images are big, it can lock down lot of kernel memory and in fact can trigger OOM on many processes. I guess that's an issue with existing kexec() interface too, so nothing new here.

This is like re-designing the kexec/kdump and I really wish there is an easier way to handle the case signed kernels.

Quoted 3 lines

This is like re-designing the kexec/kdump and I really wish there is an easier way to handle the case signed kernels.

Yes. Which is why either a signed puragtory or a signed /sbin/kexec look very attractive.

Quoted 4 lines · Eric W. Biederman

Quoted 3 lines

This is like re-designing the kexec/kdump and I really wish there is an easier way to handle the case signed kernels.

Quoted 3 lines

Yes. Which is why either a signed puragtory or a signed /sbin/kexec look very attractive.

Signed purgatory sounds like The Right Thing. Doing relocation in purgatory should be quite trivial; I'd be happy to work with people if they need pointers how to do it.

Quoted 5 lines · H. Peter Anvin

Quoted 4 lines · Eric W. Biederman

Quoted 3 lines

This is like re-designing the kexec/kdump and I really wish there is an easier way to handle the case signed kernels.

Quoted 7 lines

Quoted 3 lines

Yes. Which is why either a signed puragtory or a signed /sbin/kexec look very attractive.

Signed purgatory sounds like The Right Thing. Doing relocation in purgatory should be quite trivial; I'd be happy to work with people if they need pointers how to do it.

So we sign purgatory and do the relocations in kernel later after signature verification?

I have few questions though.

- We modify purgatory (update symbol values) in user space. That allows us to build single purgatory and chagne its behavior based on user options to kexec-tools (like 16bit vs 32bit entry, updating location of backup region etc). In fact purgatory to kernel jump location is decided at run time and purgatory is updated accordingly. That means we can't sign the purgatory.

So apart from relocation, user space modification of purgatory code is also an issue.

- Even if we come up with a way to avoid that, so will we not sign /sbin/kexec in that case? What happens to other unsigned segments loaded by /sbin/kexec. (boot_params, command line, elf headers etc). Can these be trusted without any signature.

So I am not sure that just signing the purgatory will solve the issue.