Re: Kdump with signed images
On Wed, 2012-11-14 at 21:09 -0800, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: > >> Vivek Goyal writes: > >> > >> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: > >> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: > >> >> > >> >> [..] > >> >> > >> >> Thnking more about executable signature verification, I have another > >> >> question. > >> >> > >> >> While verifyign the signature, we will have to read the whole executable > >> >> in memory. That sounds bad as we are in kernel mode and will not be > >> >> killed > >> >> and if sombody is trying to execute a malformed exceptionally large > >> >> executable, system will start killing other processess. We can > >> >> potentially > >> >> lock all the memory in kernel just by trying to execute a signed huge > >> >> executable. Not good. > >> >> > >> > > >> > Also, even if we try to read in whole executable, can't an hacker modify > >> > pages in swap disk and then they will be faulted back in and bingo hacker > >> > is running its unsigned code. (assuming root has been compromised > >> > otherwise > >> > why do we have to do all this exercise). > >> > >> You make a decent case for an implicit mlockall(MCL_FUTURE) being > >> required of signed executables, that are going to be granted privileges > >> based on signature verification. > > > > implicity lockall for signed executables sounds reasonable to avoid the > > swap hack. > > > >> > >> As for size if the executable won't fit in memory, there is no point in > >> checking the signature. > > > > Well I am worried about malformed executables. One can sign a huge > > executable (which is never meant to run successfully) and cause all > > kind of memory issues. > > Good point what to do with executables with invalid sigantures. From > another reply it sounded like one of the bits of IMA/EVM had already > addressed part of that. With IMA-appraisal enabled (enforcing mode), it would not be executed. > > Can we first look at the signature, decrypt it using certificates in > > kernel ring, and if we find out that executable was signed by any > > of the certificates, only then we go on to read in whole executable > > and try to calculate the digest. May be at the time of signing we can put > > a string, say "LINUX", along with digest and then sing/encrypt it. Upon > > decryption we can check if LINUX is there and if yes, we know it was > > signed by the certifcate loaded in kernel and then go on to load the > > full executable and calculate digest. > > > Not sure if above is doable or not but if it is, it might reduce the > > risk significantly as we will not try to integrity verify executables > > not signed by genuine certificates. > > Known plaintext in the signed blob should allow that. I would be very > careful with that because it sounds like the kind of thing that opens > you up to plain-text attacks, but that is mostly my parania and lack of > experience speaking. Although IMA (measurement and attestation), IMA-appraisal (local integrity enforcement), and IMA auditing (logging hashes) can be enabled individually, if any of these functions are enabled, then assuming the file is in the IMA policy, the file will be hashed. Remember if all else fails, measurement and attestation is your last line of defense, for detecting if your system has been compromised. Mimi > >> It should be fairly straight forward to make the signature checking > >> process preemptable and killable. > > > > hmm..., not sure how to do this. Will have to read more code to understand > > process killing and see what can I do this while I am in kernel mode > > and I possibly might have done kernel memory allocations using > > vmalloc()/kmalloc() etc. > > Well basically it is matter of using the killable version of waits > returning an error code as you unwind, and eventually either > force_sig(SIGKILL) or do_exit(). > > There are a lot of times where you can support SIGKILL and just cause > the process to exit where you can't handle signals. > > > Eric > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Wed, 2012-11-14 at 21:09 -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: [..] Thnking more about executable signature verification, I have another question. While verifyign the signature, we will have to read the whole executable in memory. That sounds bad as we are in kernel mode and will not be killed and if sombody is trying to execute a malformed exceptionally large executable, system will start killing other processess. We can potentially lock all the memory in kernel just by trying to execute a signed huge executable. Not good. Also, even if we try to read in whole executable, can't an hacker modify pages in swap disk and then they will be faulted back in and bingo hacker is running its unsigned code. (assuming root has been compromised otherwise why do we have to do all this exercise). You make a decent case for an implicit mlockall(MCL_FUTURE) being required of signed executables, that are going to be granted privileges based on signature verification. implicity lockall for signed executables sounds reasonable to avoid the swap hack. As for size if the executable won't fit in memory, there is no point in checking the signature. Well I am worried about malformed executables. One can sign a huge executable (which is never meant to run successfully) and cause all kind of memory issues. Good point what to do with executables with invalid sigantures. From another reply it sounded like one of the bits of IMA/EVM had already addressed part of that. With IMA-appraisal enabled (enforcing mode), it would not be executed. Can we first look at the signature, decrypt it using certificates in kernel ring, and if we find out that executable was signed by any of the certificates, only then we go on to read in whole executable and try to calculate the digest. May be at the time of signing we can put a string, say LINUX, along with digest and then sing/encrypt it. Upon decryption we can check if LINUX is there and if yes, we know it was signed by the certifcate loaded in kernel and then go on to load the full executable and calculate digest. Not sure if above is doable or not but if it is, it might reduce the risk significantly as we will not try to integrity verify executables not signed by genuine certificates. Known plaintext in the signed blob should allow that. I would be very careful with that because it sounds like the kind of thing that opens you up to plain-text attacks, but that is mostly my parania and lack of experience speaking. Although IMA (measurement and attestation), IMA-appraisal (local integrity enforcement), and IMA auditing (logging hashes) can be enabled individually, if any of these functions are enabled, then assuming the file is in the IMA policy, the file will be hashed. Remember if all else fails, measurement and attestation is your last line of defense, for detecting if your system has been compromised. Mimi It should be fairly straight forward to make the signature checking process preemptable and killable. hmm..., not sure how to do this. Will have to read more code to understand process killing and see what can I do this while I am in kernel mode and I possibly might have done kernel memory allocations using vmalloc()/kmalloc() etc. Well basically it is matter of using the killable version of waits returning an error code as you unwind, and eventually either force_sig(SIGKILL) or do_exit(). There are a lot of times where you can support SIGKILL and just cause the process to exit where you can't handle signals. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal writes: > On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: >> Vivek Goyal writes: >> >> > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: >> >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: >> >> >> >> [..] >> >> >> >> Thnking more about executable signature verification, I have another >> >> question. >> >> >> >> While verifyign the signature, we will have to read the whole executable >> >> in memory. That sounds bad as we are in kernel mode and will not be killed >> >> and if sombody is trying to execute a malformed exceptionally large >> >> executable, system will start killing other processess. We can potentially >> >> lock all the memory in kernel just by trying to execute a signed huge >> >> executable. Not good. >> >> >> > >> > Also, even if we try to read in whole executable, can't an hacker modify >> > pages in swap disk and then they will be faulted back in and bingo hacker >> > is running its unsigned code. (assuming root has been compromised otherwise >> > why do we have to do all this exercise). >> >> You make a decent case for an implicit mlockall(MCL_FUTURE) being >> required of signed executables, that are going to be granted privileges >> based on signature verification. > > implicity lockall for signed executables sounds reasonable to avoid the > swap hack. > >> >> As for size if the executable won't fit in memory, there is no point in >> checking the signature. > > Well I am worried about malformed executables. One can sign a huge > executable (which is never meant to run successfully) and cause all > kind of memory issues. Good point what to do with executables with invalid sigantures. From another reply it sounded like one of the bits of IMA/EVM had already addressed part of that. > Can we first look at the signature, decrypt it using certificates in > kernel ring, and if we find out that executable was signed by any > of the certificates, only then we go on to read in whole executable > and try to calculate the digest. May be at the time of signing we can put > a string, say "LINUX", along with digest and then sing/encrypt it. Upon > decryption we can check if LINUX is there and if yes, we know it was > signed by the certifcate loaded in kernel and then go on to load the > full executable and calculate digest. > Not sure if above is doable or not but if it is, it might reduce the > risk significantly as we will not try to integrity verify executables > not signed by genuine certificates. Known plaintext in the signed blob should allow that. I would be very careful with that because it sounds like the kind of thing that opens you up to plain-text attacks, but that is mostly my parania and lack of experience speaking. >> It should be fairly straight forward to make the signature checking >> process preemptable and killable. > > hmm..., not sure how to do this. Will have to read more code to understand > process killing and see what can I do this while I am in kernel mode > and I possibly might have done kernel memory allocations using > vmalloc()/kmalloc() etc. Well basically it is matter of using the killable version of waits returning an error code as you unwind, and eventually either force_sig(SIGKILL) or do_exit(). There are a lot of times where you can support SIGKILL and just cause the process to exit where you can't handle signals. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: [..] Thnking more about executable signature verification, I have another question. While verifyign the signature, we will have to read the whole executable in memory. That sounds bad as we are in kernel mode and will not be killed and if sombody is trying to execute a malformed exceptionally large executable, system will start killing other processess. We can potentially lock all the memory in kernel just by trying to execute a signed huge executable. Not good. Also, even if we try to read in whole executable, can't an hacker modify pages in swap disk and then they will be faulted back in and bingo hacker is running its unsigned code. (assuming root has been compromised otherwise why do we have to do all this exercise). You make a decent case for an implicit mlockall(MCL_FUTURE) being required of signed executables, that are going to be granted privileges based on signature verification. implicity lockall for signed executables sounds reasonable to avoid the swap hack. As for size if the executable won't fit in memory, there is no point in checking the signature. Well I am worried about malformed executables. One can sign a huge executable (which is never meant to run successfully) and cause all kind of memory issues. Good point what to do with executables with invalid sigantures. From another reply it sounded like one of the bits of IMA/EVM had already addressed part of that. Can we first look at the signature, decrypt it using certificates in kernel ring, and if we find out that executable was signed by any of the certificates, only then we go on to read in whole executable and try to calculate the digest. May be at the time of signing we can put a string, say LINUX, along with digest and then sing/encrypt it. Upon decryption we can check if LINUX is there and if yes, we know it was signed by the certifcate loaded in kernel and then go on to load the full executable and calculate digest. Not sure if above is doable or not but if it is, it might reduce the risk significantly as we will not try to integrity verify executables not signed by genuine certificates. Known plaintext in the signed blob should allow that. I would be very careful with that because it sounds like the kind of thing that opens you up to plain-text attacks, but that is mostly my parania and lack of experience speaking. It should be fairly straight forward to make the signature checking process preemptable and killable. hmm..., not sure how to do this. Will have to read more code to understand process killing and see what can I do this while I am in kernel mode and I possibly might have done kernel memory allocations using vmalloc()/kmalloc() etc. Well basically it is matter of using the killable version of waits returning an error code as you unwind, and eventually either force_sig(SIGKILL) or do_exit(). There are a lot of times where you can support SIGKILL and just cause the process to exit where you can't handle signals. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: > >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: > >> > >> [..] > >> > >> Thnking more about executable signature verification, I have another > >> question. > >> > >> While verifyign the signature, we will have to read the whole executable > >> in memory. That sounds bad as we are in kernel mode and will not be killed > >> and if sombody is trying to execute a malformed exceptionally large > >> executable, system will start killing other processess. We can potentially > >> lock all the memory in kernel just by trying to execute a signed huge > >> executable. Not good. > >> > > > > Also, even if we try to read in whole executable, can't an hacker modify > > pages in swap disk and then they will be faulted back in and bingo hacker > > is running its unsigned code. (assuming root has been compromised otherwise > > why do we have to do all this exercise). > > You make a decent case for an implicit mlockall(MCL_FUTURE) being > required of signed executables, that are going to be granted privileges > based on signature verification. implicity lockall for signed executables sounds reasonable to avoid the swap hack. > > As for size if the executable won't fit in memory, there is no point in > checking the signature. Well I am worried about malformed executables. One can sign a huge executable (which is never meant to run successfully) and cause all kind of memory issues. Can we first look at the signature, decrypt it using certificates in kernel ring, and if we find out that executable was signed by any of the certificates, only then we go on to read in whole executable and try to calculate the digest. May be at the time of signing we can put a string, say "LINUX", along with digest and then sing/encrypt it. Upon decryption we can check if LINUX is there and if yes, we know it was signed by the certifcate loaded in kernel and then go on to load the full executable and calculate digest. Not sure if above is doable or not but if it is, it might reduce the risk significantly as we will not try to integrity verify executables not signed by genuine certificates. > > It should be fairly straight forward to make the signature checking > process preemptable and killable. hmm..., not sure how to do this. Will have to read more code to understand process killing and see what can I do this while I am in kernel mode and I possibly might have done kernel memory allocations using vmalloc()/kmalloc() etc. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 08, 2012 at 01:03:17PM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: [..] Thnking more about executable signature verification, I have another question. While verifyign the signature, we will have to read the whole executable in memory. That sounds bad as we are in kernel mode and will not be killed and if sombody is trying to execute a malformed exceptionally large executable, system will start killing other processess. We can potentially lock all the memory in kernel just by trying to execute a signed huge executable. Not good. Also, even if we try to read in whole executable, can't an hacker modify pages in swap disk and then they will be faulted back in and bingo hacker is running its unsigned code. (assuming root has been compromised otherwise why do we have to do all this exercise). You make a decent case for an implicit mlockall(MCL_FUTURE) being required of signed executables, that are going to be granted privileges based on signature verification. implicity lockall for signed executables sounds reasonable to avoid the swap hack. As for size if the executable won't fit in memory, there is no point in checking the signature. Well I am worried about malformed executables. One can sign a huge executable (which is never meant to run successfully) and cause all kind of memory issues. Can we first look at the signature, decrypt it using certificates in kernel ring, and if we find out that executable was signed by any of the certificates, only then we go on to read in whole executable and try to calculate the digest. May be at the time of signing we can put a string, say LINUX, along with digest and then sing/encrypt it. Upon decryption we can check if LINUX is there and if yes, we know it was signed by the certifcate loaded in kernel and then go on to load the full executable and calculate digest. Not sure if above is doable or not but if it is, it might reduce the risk significantly as we will not try to integrity verify executables not signed by genuine certificates. It should be fairly straight forward to make the signature checking process preemptable and killable. hmm..., not sure how to do this. Will have to read more code to understand process killing and see what can I do this while I am in kernel mode and I possibly might have done kernel memory allocations using vmalloc()/kmalloc() etc. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal writes: > On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: >> On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: >> >> [..] >> >> Thnking more about executable signature verification, I have another >> question. >> >> While verifyign the signature, we will have to read the whole executable >> in memory. That sounds bad as we are in kernel mode and will not be killed >> and if sombody is trying to execute a malformed exceptionally large >> executable, system will start killing other processess. We can potentially >> lock all the memory in kernel just by trying to execute a signed huge >> executable. Not good. >> > > Also, even if we try to read in whole executable, can't an hacker modify > pages in swap disk and then they will be faulted back in and bingo hacker > is running its unsigned code. (assuming root has been compromised otherwise > why do we have to do all this exercise). You make a decent case for an implicit mlockall(MCL_FUTURE) being required of signed executables, that are going to be granted privileges based on signature verification. As for size if the executable won't fit in memory, there is no point in checking the signature. It should be fairly straight forward to make the signature checking process preemptable and killable. Of course this is all hand waving at this point. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-08 at 14:40 -0500, Vivek Goyal wrote: > On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: > > [..] > > Thnking more about executable signature verification, I have another question. > > While verifyign the signature, we will have to read the whole executable > in memory. That sounds bad as we are in kernel mode and will not be killed > and if sombody is trying to execute a malformed exceptionally large > executable, system will start killing other processess. We can potentially > lock all the memory in kernel just by trying to execute a signed huge > executable. Not good. > > I was looking at IMA and they seem to be using kernel_read() for reading > page in and update digest. IIUC, that means page is read from disk, > brought in cache and if needed will be read back from disk. But that > means hacker can try to do some timing tricks and try to replace disk image > after signature verification and run unsigned program. For the reason you mentioned, the signature verification is deferred to bprm, after the executable has been locked from modification. Any subsequent changes to the file would cause the file to be re-appraised. The goal of EVM/IMA-appraisal is to detect file tampering and enforce file data/metadata integrity. If EVM/IMA-appraisal fail, then as a last resort, we fall back and rely on IMA measurement/attestation at least to detect it. Mimi > So how do we go about it. Neither of the approaches sound appealing > to me. > > Thanks > Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: > On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: > > [..] > > Thnking more about executable signature verification, I have another question. > > While verifyign the signature, we will have to read the whole executable > in memory. That sounds bad as we are in kernel mode and will not be killed > and if sombody is trying to execute a malformed exceptionally large > executable, system will start killing other processess. We can potentially > lock all the memory in kernel just by trying to execute a signed huge > executable. Not good. > Also, even if we try to read in whole executable, can't an hacker modify pages in swap disk and then they will be faulted back in and bingo hacker is running its unsigned code. (assuming root has been compromised otherwise why do we have to do all this exercise). Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: [..] Thnking more about executable signature verification, I have another question. While verifyign the signature, we will have to read the whole executable in memory. That sounds bad as we are in kernel mode and will not be killed and if sombody is trying to execute a malformed exceptionally large executable, system will start killing other processess. We can potentially lock all the memory in kernel just by trying to execute a signed huge executable. Not good. Also, even if we try to read in whole executable, can't an hacker modify pages in swap disk and then they will be faulted back in and bingo hacker is running its unsigned code. (assuming root has been compromised otherwise why do we have to do all this exercise). Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-08 at 14:40 -0500, Vivek Goyal wrote: On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: [..] Thnking more about executable signature verification, I have another question. While verifyign the signature, we will have to read the whole executable in memory. That sounds bad as we are in kernel mode and will not be killed and if sombody is trying to execute a malformed exceptionally large executable, system will start killing other processess. We can potentially lock all the memory in kernel just by trying to execute a signed huge executable. Not good. I was looking at IMA and they seem to be using kernel_read() for reading page in and update digest. IIUC, that means page is read from disk, brought in cache and if needed will be read back from disk. But that means hacker can try to do some timing tricks and try to replace disk image after signature verification and run unsigned program. For the reason you mentioned, the signature verification is deferred to bprm, after the executable has been locked from modification. Any subsequent changes to the file would cause the file to be re-appraised. The goal of EVM/IMA-appraisal is to detect file tampering and enforce file data/metadata integrity. If EVM/IMA-appraisal fail, then as a last resort, we fall back and rely on IMA measurement/attestation at least to detect it. Mimi So how do we go about it. Neither of the approaches sound appealing to me. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 08, 2012 at 02:40:50PM -0500, Vivek Goyal wrote: On Tue, Nov 06, 2012 at 03:51:59PM -0800, Eric W. Biederman wrote: [..] Thnking more about executable signature verification, I have another question. While verifyign the signature, we will have to read the whole executable in memory. That sounds bad as we are in kernel mode and will not be killed and if sombody is trying to execute a malformed exceptionally large executable, system will start killing other processess. We can potentially lock all the memory in kernel just by trying to execute a signed huge executable. Not good. Also, even if we try to read in whole executable, can't an hacker modify pages in swap disk and then they will be faulted back in and bingo hacker is running its unsigned code. (assuming root has been compromised otherwise why do we have to do all this exercise). You make a decent case for an implicit mlockall(MCL_FUTURE) being required of signed executables, that are going to be granted privileges based on signature verification. As for size if the executable won't fit in memory, there is no point in checking the signature. It should be fairly straight forward to make the signature checking process preemptable and killable. Of course this is all hand waving at this point. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal writes: > On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: >> Vivek Goyal writes: >> >> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: >> >> >> >> It needs to be checked but /sbin/kexec should not use any functions that >> >> trigger nss switch. No user or password or host name lookup should be >> >> happening. >> > >> > I also think that we don't call routines which trigger nss switch but >> > be probably can't rely on that as somebody might introduce it in >> > future. So we need more robust mechanism to prevent it than just code >> > inspection. >> >> The fact that we shouldn't use those routines is enough to let us >> walk down a path where they are not used. Either with a static glibc >> linked told to use no nss modules (--enable-static-nss ?), or with >> another more restricted libc. > > I installed glibc-static and built kexec-tools using gcc "-static" option. > It built just fine and infact kdump is working with it. > > Size of new kexec binary is around 1.4MB. > > Did not get any warning w.r.t nss, so I am assuming we are not calling > any relevant functions. > > I did try building my own libc using --enable-static-nss but it does not > seem to have built static versions of libnss*. Will look more into it > and try linking kexec with this new glibc and see if that works. > > Also tried playing with klibc and uclibc a bit but can't get anything > going quickly. Sounds good. It has been about a year since I looked but kexec built uclibc just fine last time I tried it. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: > >> > >> It needs to be checked but /sbin/kexec should not use any functions that > >> trigger nss switch. No user or password or host name lookup should be > >> happening. > > > > I also think that we don't call routines which trigger nss switch but > > be probably can't rely on that as somebody might introduce it in > > future. So we need more robust mechanism to prevent it than just code > > inspection. > > The fact that we shouldn't use those routines is enough to let us > walk down a path where they are not used. Either with a static glibc > linked told to use no nss modules (--enable-static-nss ?), or with > another more restricted libc. I installed glibc-static and built kexec-tools using gcc "-static" option. It built just fine and infact kdump is working with it. Size of new kexec binary is around 1.4MB. Did not get any warning w.r.t nss, so I am assuming we are not calling any relevant functions. I did try building my own libc using --enable-static-nss but it does not seem to have built static versions of libnss*. Will look more into it and try linking kexec with this new glibc and see if that works. Also tried playing with klibc and uclibc a bit but can't get anything going quickly. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. The fact that we shouldn't use those routines is enough to let us walk down a path where they are not used. Either with a static glibc linked told to use no nss modules (--enable-static-nss ?), or with another more restricted libc. I installed glibc-static and built kexec-tools using gcc -static option. It built just fine and infact kdump is working with it. Size of new kexec binary is around 1.4MB. Did not get any warning w.r.t nss, so I am assuming we are not calling any relevant functions. I did try building my own libc using --enable-static-nss but it does not seem to have built static versions of libnss*. Will look more into it and try linking kexec with this new glibc and see if that works. Also tried playing with klibc and uclibc a bit but can't get anything going quickly. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal vgo...@redhat.com writes: On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. The fact that we shouldn't use those routines is enough to let us walk down a path where they are not used. Either with a static glibc linked told to use no nss modules (--enable-static-nss ?), or with another more restricted libc. I installed glibc-static and built kexec-tools using gcc -static option. It built just fine and infact kdump is working with it. Size of new kexec binary is around 1.4MB. Did not get any warning w.r.t nss, so I am assuming we are not calling any relevant functions. I did try building my own libc using --enable-static-nss but it does not seem to have built static versions of libnss*. Will look more into it and try linking kexec with this new glibc and see if that works. Also tried playing with klibc and uclibc a bit but can't get anything going quickly. Sounds good. It has been about a year since I looked but kexec built uclibc just fine last time I tried it. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Yes, it is unlikely you can pare thibgs down more than klibc. Vivek Goyal wrote: >On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: >> Vivek Goyal writes: >> >> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: >> >> >> >> It needs to be checked but /sbin/kexec should not use any >functions that >> >> trigger nss switch. No user or password or host name lookup >should be >> >> happening. >> > >> > I also think that we don't call routines which trigger nss switch >but >> > be probably can't rely on that as somebody might introduce it in >> > future. So we need more robust mechanism to prevent it than just >code >> > inspection. >> >> The fact that we shouldn't use those routines is enough to let us >> walk down a path where they are not used. Either with a static glibc >> linked told to use no nss modules (--enable-static-nss ?), or with >> another more restricted libc. > >Is there anything wrong with using uClibc? Trying to link again >customized glibc (with --enable-static-nss) sounds just extra work for >build environments. Are there know restricted libc or we need to create >one with passing more compile time options to libc. > >Instead of doing more work in an attempt to create restricted libc, >it might be easier to just link against any already available >restricted library. > >Thanks >Vivek -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: > >> > >> It needs to be checked but /sbin/kexec should not use any functions that > >> trigger nss switch. No user or password or host name lookup should be > >> happening. > > > > I also think that we don't call routines which trigger nss switch but > > be probably can't rely on that as somebody might introduce it in > > future. So we need more robust mechanism to prevent it than just code > > inspection. > > The fact that we shouldn't use those routines is enough to let us > walk down a path where they are not used. Either with a static glibc > linked told to use no nss modules (--enable-static-nss ?), or with > another more restricted libc. Is there anything wrong with using uClibc? Trying to link again customized glibc (with --enable-static-nss) sounds just extra work for build environments. Are there know restricted libc or we need to create one with passing more compile time options to libc. Instead of doing more work in an attempt to create restricted libc, it might be easier to just link against any already available restricted library. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal writes: > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: >> >> It needs to be checked but /sbin/kexec should not use any functions that >> trigger nss switch. No user or password or host name lookup should be >> happening. > > I also think that we don't call routines which trigger nss switch but > be probably can't rely on that as somebody might introduce it in > future. So we need more robust mechanism to prevent it than just code > inspection. The fact that we shouldn't use those routines is enough to let us walk down a path where they are not used. Either with a static glibc linked told to use no nss modules (--enable-static-nss ?), or with another more restricted libc. >> This is one part in hardening /sbin/kexec to deal with hostile root >> users. We need to check crazy things like do the files we open on /proc >> actually point to /proc after we have opened them. > > Can you please explain it more. How can one fiddle with /proc. Also > what's the solution then. The solution is to just fstat the files and verify the filesystem from which they came after the files have been opened. The issue is that an evil root user may have mounted something else on /proc. >> I believe glibc has some code which triggers for suid root applications >> that we should ensure gets triggered that avoid trusting things like >> LD_LIBRARY_PATH and company. > > I guess linking statically with uClibc or klibc (as hpa said), might turn > out to be better option to avoid all the issues w.r.t shared objects > and all the tricky environment variables. Linking with a more restricted libc will solve most if not all shared object issues. We still need to audit our environment variable issue. How we interpret them and how our restricted libc automatically interprets them. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: > >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: > >> > >> > So I think this does satisfy the requirement matthew specified. Isn't it? > >> > Matthew, what do you think? > >> > >> Sure, if you can ensure that. You'll need to figure out how to get the > >> build system to sign the userspace binaries and you'll need to ensure > >> that they're statically linked and don't dlopen anything (including the > >> nsswitch modules), but otherwise that should work. > >> > > > > [ CC peter jones ] > > > > Ok, so even if we build kexec-tools statically with glibc, we have the > > issue of name service switch modules. glibc will still do dlopen on > > these modules. So what are options now. > > > > - Sign glibc and associated shared libraries. Do not allow unsigned > > shared library to dynamically link with signed executable. > > > > - Peter mentioned that work with uClibc for kexec-tools. > > > > I personally think that however hard it is but first option sounds like > > a long term solution. We might have more user space processes which > > we might have to trust a generic solution will help with that. For example, > > we might have to sign and trust qemu at some point of time. > > > > Are there other ways of handing glibc issue? > > It needs to be checked but /sbin/kexec should not use any functions that > trigger nss switch. No user or password or host name lookup should be > happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. > > This is one part in hardening /sbin/kexec to deal with hostile root > users. We need to check crazy things like do the files we open on /proc > actually point to /proc after we have opened them. Can you please explain it more. How can one fiddle with /proc. Also what's the solution then. > > I believe glibc has some code which triggers for suid root applications > that we should ensure gets triggered that avoid trusting things like > LD_LIBRARY_PATH and company. I guess linking statically with uClibc or klibc (as hpa said), might turn out to be better option to avoid all the issues w.r.t shared objects and all the tricky environment variables. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. This is one part in hardening /sbin/kexec to deal with hostile root users. We need to check crazy things like do the files we open on /proc actually point to /proc after we have opened them. Can you please explain it more. How can one fiddle with /proc. Also what's the solution then. I believe glibc has some code which triggers for suid root applications that we should ensure gets triggered that avoid trusting things like LD_LIBRARY_PATH and company. I guess linking statically with uClibc or klibc (as hpa said), might turn out to be better option to avoid all the issues w.r.t shared objects and all the tricky environment variables. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal vgo...@redhat.com writes: On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. The fact that we shouldn't use those routines is enough to let us walk down a path where they are not used. Either with a static glibc linked told to use no nss modules (--enable-static-nss ?), or with another more restricted libc. This is one part in hardening /sbin/kexec to deal with hostile root users. We need to check crazy things like do the files we open on /proc actually point to /proc after we have opened them. Can you please explain it more. How can one fiddle with /proc. Also what's the solution then. The solution is to just fstat the files and verify the filesystem from which they came after the files have been opened. The issue is that an evil root user may have mounted something else on /proc. I believe glibc has some code which triggers for suid root applications that we should ensure gets triggered that avoid trusting things like LD_LIBRARY_PATH and company. I guess linking statically with uClibc or klibc (as hpa said), might turn out to be better option to avoid all the issues w.r.t shared objects and all the tricky environment variables. Linking with a more restricted libc will solve most if not all shared object issues. We still need to audit our environment variable issue. How we interpret them and how our restricted libc automatically interprets them. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. The fact that we shouldn't use those routines is enough to let us walk down a path where they are not used. Either with a static glibc linked told to use no nss modules (--enable-static-nss ?), or with another more restricted libc. Is there anything wrong with using uClibc? Trying to link again customized glibc (with --enable-static-nss) sounds just extra work for build environments. Are there know restricted libc or we need to create one with passing more compile time options to libc. Instead of doing more work in an attempt to create restricted libc, it might be easier to just link against any already available restricted library. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Yes, it is unlikely you can pare thibgs down more than klibc. Vivek Goyal vgo...@redhat.com wrote: On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. I also think that we don't call routines which trigger nss switch but be probably can't rely on that as somebody might introduce it in future. So we need more robust mechanism to prevent it than just code inspection. The fact that we shouldn't use those routines is enough to let us walk down a path where they are not used. Either with a static glibc linked told to use no nss modules (--enable-static-nss ?), or with another more restricted libc. Is there anything wrong with using uClibc? Trying to link again customized glibc (with --enable-static-nss) sounds just extra work for build environments. Are there know restricted libc or we need to create one with passing more compile time options to libc. Instead of doing more work in an attempt to create restricted libc, it might be easier to just link against any already available restricted library. Thanks Vivek -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 2, 2012 at 8:06 PM, Vivek Goyal wrote: > On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote: >> On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal wrote: >> > On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: >> >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: >> >> >> >> > So I think this does satisfy the requirement matthew specified. Isn't >> >> > it? >> >> > Matthew, what do you think? >> >> >> >> Sure, if you can ensure that. You'll need to figure out how to get the >> >> build system to sign the userspace binaries and you'll need to ensure >> >> that they're statically linked and don't dlopen anything (including the >> >> nsswitch modules), but otherwise that should work. >> >> >> > >> > [ CC peter jones ] >> > >> > Ok, so even if we build kexec-tools statically with glibc, we have the >> > issue of name service switch modules. glibc will still do dlopen on >> > these modules. So what are options now. >> > >> > - Sign glibc and associated shared libraries. Do not allow unsigned >> > shared library to dynamically link with signed executable. >> > >> > - Peter mentioned that work with uClibc for kexec-tools. >> > >> > I personally think that however hard it is but first option sounds like >> > a long term solution. We might have more user space processes which >> > we might have to trust a generic solution will help with that. For example, >> > we might have to sign and trust qemu at some point of time. >> > >> > Are there other ways of handing glibc issue? >> > >> >> Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically >> linked programs need some shared libraries which is not acceptable for >> me. What can I do?" Probably, worth trying. > > Yes I have seen this. IIUC, it says that build libc with -enable-static-nss > and then individual programs need to statically build against the nss > modules program will use. > > I think building libc with -enable-static-nss part will be unacceptable > for general server as other programs would like to make use of the > existing nss functionality. No, use that library for static linking only for programs that need to be signed (kexec-tools), until the base OS gets signature support. Why does the same library need to be used for general sever programs? The built library would be used only on the build system. I also like HPA's suggestion on using klibc, but I am not sure what it would take to port the tools to use klibc Balbir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On 11/02/2012 07:29 AM, Balbir Singh wrote: > > Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically > linked programs need some shared libraries which is not acceptable for > me. What can I do?" Probably, worth trying. > You can build something with klibc... a static klibc binary can easily be smaller than a dynamic glibc binary. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal writes: > On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: >> >> > So I think this does satisfy the requirement matthew specified. Isn't it? >> > Matthew, what do you think? >> >> Sure, if you can ensure that. You'll need to figure out how to get the >> build system to sign the userspace binaries and you'll need to ensure >> that they're statically linked and don't dlopen anything (including the >> nsswitch modules), but otherwise that should work. >> > > [ CC peter jones ] > > Ok, so even if we build kexec-tools statically with glibc, we have the > issue of name service switch modules. glibc will still do dlopen on > these modules. So what are options now. > > - Sign glibc and associated shared libraries. Do not allow unsigned > shared library to dynamically link with signed executable. > > - Peter mentioned that work with uClibc for kexec-tools. > > I personally think that however hard it is but first option sounds like > a long term solution. We might have more user space processes which > we might have to trust a generic solution will help with that. For example, > we might have to sign and trust qemu at some point of time. > > Are there other ways of handing glibc issue? It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. This is one part in hardening /sbin/kexec to deal with hostile root users. We need to check crazy things like do the files we open on /proc actually point to /proc after we have opened them. I believe glibc has some code which triggers for suid root applications that we should ensure gets triggered that avoid trusting things like LD_LIBRARY_PATH and company. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-01 at 16:23 +, Matthew Garrett wrote: > On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote: > > How would a customer go about getting that userspace binary signed and > > re-signed every time they update their app? There is the option of > > turning the whole SecureBoot thing off for a system like that but let > > us assume customer wants to leave that on or does not have the option > > to turn it off? > > There's ongoing work for providing mechanisms for trusting user keys. If > you want Secure Boot turned on, you don't want any untrusted code > running in your kernel. If you're happy with untrusted code in your > kernel, why are you using Secure Boot? > I would argue code written by a customer to run on their own systems is inherently trusted code and does not invalidate need/desire for Secure Boot. So the customer will still need some way to get their binary signed very painlessly just so they could use their own binary on their own system, simply because of a heavily locked down system design by Linux community. -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote: > On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal wrote: > > On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: > >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: > >> > >> > So I think this does satisfy the requirement matthew specified. Isn't it? > >> > Matthew, what do you think? > >> > >> Sure, if you can ensure that. You'll need to figure out how to get the > >> build system to sign the userspace binaries and you'll need to ensure > >> that they're statically linked and don't dlopen anything (including the > >> nsswitch modules), but otherwise that should work. > >> > > > > [ CC peter jones ] > > > > Ok, so even if we build kexec-tools statically with glibc, we have the > > issue of name service switch modules. glibc will still do dlopen on > > these modules. So what are options now. > > > > - Sign glibc and associated shared libraries. Do not allow unsigned > > shared library to dynamically link with signed executable. > > > > - Peter mentioned that work with uClibc for kexec-tools. > > > > I personally think that however hard it is but first option sounds like > > a long term solution. We might have more user space processes which > > we might have to trust a generic solution will help with that. For example, > > we might have to sign and trust qemu at some point of time. > > > > Are there other ways of handing glibc issue? > > > > Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically > linked programs need some shared libraries which is not acceptable for > me. What can I do?" Probably, worth trying. Yes I have seen this. IIUC, it says that build libc with -enable-static-nss and then individual programs need to statically build against the nss modules program will use. I think building libc with -enable-static-nss part will be unacceptable for general server as other programs would like to make use of the existing nss functionality. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal wrote: > On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: >> On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: >> >> > So I think this does satisfy the requirement matthew specified. Isn't it? >> > Matthew, what do you think? >> >> Sure, if you can ensure that. You'll need to figure out how to get the >> build system to sign the userspace binaries and you'll need to ensure >> that they're statically linked and don't dlopen anything (including the >> nsswitch modules), but otherwise that should work. >> > > [ CC peter jones ] > > Ok, so even if we build kexec-tools statically with glibc, we have the > issue of name service switch modules. glibc will still do dlopen on > these modules. So what are options now. > > - Sign glibc and associated shared libraries. Do not allow unsigned > shared library to dynamically link with signed executable. > > - Peter mentioned that work with uClibc for kexec-tools. > > I personally think that however hard it is but first option sounds like > a long term solution. We might have more user space processes which > we might have to trust a generic solution will help with that. For example, > we might have to sign and trust qemu at some point of time. > > Are there other ways of handing glibc issue? > Have you seen http://sourceware.org/glibc/wiki/FAQ - "Even statically linked programs need some shared libraries which is not acceptable for me. What can I do?" Probably, worth trying. Balbir Singh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: > On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: > > > So I think this does satisfy the requirement matthew specified. Isn't it? > > Matthew, what do you think? > > Sure, if you can ensure that. You'll need to figure out how to get the > build system to sign the userspace binaries and you'll need to ensure > that they're statically linked and don't dlopen anything (including the > nsswitch modules), but otherwise that should work. > [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. Balbir Singh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote: On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. Yes I have seen this. IIUC, it says that build libc with -enable-static-nss and then individual programs need to statically build against the nss modules program will use. I think building libc with -enable-static-nss part will be unacceptable for general server as other programs would like to make use of the existing nss functionality. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-01 at 16:23 +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote: How would a customer go about getting that userspace binary signed and re-signed every time they update their app? There is the option of turning the whole SecureBoot thing off for a system like that but let us assume customer wants to leave that on or does not have the option to turn it off? There's ongoing work for providing mechanisms for trusting user keys. If you want Secure Boot turned on, you don't want any untrusted code running in your kernel. If you're happy with untrusted code in your kernel, why are you using Secure Boot? I would argue code written by a customer to run on their own systems is inherently trusted code and does not invalidate need/desire for Secure Boot. So the customer will still need some way to get their binary signed very painlessly just so they could use their own binary on their own system, simply because of a heavily locked down system design by Linux community. -- Khalid -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Vivek Goyal vgo...@redhat.com writes: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? It needs to be checked but /sbin/kexec should not use any functions that trigger nss switch. No user or password or host name lookup should be happening. This is one part in hardening /sbin/kexec to deal with hostile root users. We need to check crazy things like do the files we open on /proc actually point to /proc after we have opened them. I believe glibc has some code which triggers for suid root applications that we should ensure gets triggered that avoid trusting things like LD_LIBRARY_PATH and company. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On 11/02/2012 07:29 AM, Balbir Singh wrote: Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. You can build something with klibc... a static klibc binary can easily be smaller than a dynamic glibc binary. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Nov 2, 2012 at 8:06 PM, Vivek Goyal vgo...@redhat.com wrote: On Fri, Nov 02, 2012 at 07:59:15PM +0530, Balbir Singh wrote: On Fri, Nov 2, 2012 at 6:53 PM, Vivek Goyal vgo...@redhat.com wrote: On Thu, Nov 01, 2012 at 02:52:25PM +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. [ CC peter jones ] Ok, so even if we build kexec-tools statically with glibc, we have the issue of name service switch modules. glibc will still do dlopen on these modules. So what are options now. - Sign glibc and associated shared libraries. Do not allow unsigned shared library to dynamically link with signed executable. - Peter mentioned that work with uClibc for kexec-tools. I personally think that however hard it is but first option sounds like a long term solution. We might have more user space processes which we might have to trust a generic solution will help with that. For example, we might have to sign and trust qemu at some point of time. Are there other ways of handing glibc issue? Have you seen http://sourceware.org/glibc/wiki/FAQ - Even statically linked programs need some shared libraries which is not acceptable for me. What can I do? Probably, worth trying. Yes I have seen this. IIUC, it says that build libc with -enable-static-nss and then individual programs need to statically build against the nss modules program will use. I think building libc with -enable-static-nss part will be unacceptable for general server as other programs would like to make use of the existing nss functionality. No, use that library for static linking only for programs that need to be signed (kexec-tools), until the base OS gets signature support. Why does the same library need to be used for general sever programs? The built library would be used only on the build system. I also like HPA's suggestion on using klibc, but I am not sure what it would take to port the tools to use klibc Balbir -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote: > On Thu, 2012-11-01 at 14:57 +, Matthew Garrett wrote: > > On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: > > > > > And if one wants only /sbin/kexec to call it, then just sign that > > > one so no other executable will be able to call kexec_load(). Though > > > I don't think that's the requirement here. Requirement is that only > > > trusted executables should be able to call kexec_load(). > > > > Where "trusted executables" means "signed by a key that's present in the > > system firmware or in the kernel that's signed with a key that's present > > in the system firmware", sure. > > > > This is starting to sound too restrictive (even though I understand the > rationale behind the restrictions). Does this allow for a custom > userspace application that among other things also can kexec_load() a > new kernel and boot it, for example a customer unique health monitoring > app that reboots the system if things are not looking right on the > running system? Only if it's signed with a key that the kernel trusts. > How would a customer go about getting that userspace binary signed and > re-signed every time they update their app? There is the option of > turning the whole SecureBoot thing off for a system like that but let > us assume customer wants to leave that on or does not have the option > to turn it off? There's ongoing work for providing mechanisms for trusting user keys. If you want Secure Boot turned on, you don't want any untrusted code running in your kernel. If you're happy with untrusted code in your kernel, why are you using Secure Boot? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-01 at 14:57 +, Matthew Garrett wrote: > On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: > > > And if one wants only /sbin/kexec to call it, then just sign that > > one so no other executable will be able to call kexec_load(). Though > > I don't think that's the requirement here. Requirement is that only > > trusted executables should be able to call kexec_load(). > > Where "trusted executables" means "signed by a key that's present in the > system firmware or in the kernel that's signed with a key that's present > in the system firmware", sure. > This is starting to sound too restrictive (even though I understand the rationale behind the restrictions). Does this allow for a custom userspace application that among other things also can kexec_load() a new kernel and boot it, for example a customer unique health monitoring app that reboots the system if things are not looking right on the running system? How would a customer go about getting that userspace binary signed and re-signed every time they update their app? There is the option of turning the whole SecureBoot thing off for a system like that but let us assume customer wants to leave that on or does not have the option to turn it off? -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: > And if one wants only /sbin/kexec to call it, then just sign that > one so no other executable will be able to call kexec_load(). Though > I don't think that's the requirement here. Requirement is that only > trusted executables should be able to call kexec_load(). Where "trusted executables" means "signed by a key that's present in the system firmware or in the kernel that's signed with a key that's present in the system firmware", sure. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: > So I think this does satisfy the requirement matthew specified. Isn't it? > Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote: > On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote: > > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: > > > > [..] > > > > > > > > > - So say we can sign /sbin/kexec at build time and distros can do > > > > > that. > > > > > - Verify the signature at exec time using kernel keyring and if > > > > > verification happens successfully, say process gains extra > > > > > capability. > > > > > - Use this new capability to determine whether kexec_load() will be > > > > > successful or not. > > > > > > > > > > Even if we can do all this, it still has the issue of being able to > > > > > stop the process in user space and replace the code at run time > > > > > and be able to launch unsigned kernel. > > > > > > Thinking more about it. Can we just keep track whether a process was > > > ptraced or not and disallow kexec_load() syscall if it was ptraced. > > > (I am assuming that ptrace is the only way to change process code/data). > > > > > > So binaries can be signed offline. Signature verification can take place > > > using kernel keyring at exec() time. And we can keep track of ptraced > > > processes and disallow calling kexec_load() for such processes. If this > > > is implementable, this should take care of following requirement raised > > > by matthew. > > > > > > > > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't > > > been signed by a trusted key that's been built into the kernel, and it > > > must be impossible for anything other than /sbin/kexec to make the kexec > > > system call. > > > * > > > > > > Thoughts? > > > > Eric responded but my mistake he responded to only me. So I will quickly > > put his idea here. > > > > [start quote] > > > > You can't ptrace a process that has a capability you don't. > > > > That should be enforced in security/commoncap/ > > > > [end quote] > > > > This looks like a good idea. Upon verification signed binaries will be > > assigned special capability and then no unsigned binary should be able > > to ptrace signed/verified processes > > That's a good generic solution, which I'm all in favor of, but it > doesn't resolve the latter half of Matthrew's requirement "and it must > be impossible for anything other than /sbin/kexec to make the kexec > system call." I think what matthew might have meant that anything other than signed trusted executable should not be able to call kexec_load(). Matthew? And if one wants only /sbin/kexec to call it, then just sign that one so no other executable will be able to call kexec_load(). Though I don't think that's the requirement here. Requirement is that only trusted executables should be able to call kexec_load(). Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote: > On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote: > > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: > > > > [..] > > > > > > > > > - So say we can sign /sbin/kexec at build time and distros can do > > > > > that. > > > > > - Verify the signature at exec time using kernel keyring and if > > > > > verification happens successfully, say process gains extra > > > > > capability. > > > > > - Use this new capability to determine whether kexec_load() will be > > > > > successful or not. > > > > > > > > > > Even if we can do all this, it still has the issue of being able to > > > > > stop the process in user space and replace the code at run time > > > > > and be able to launch unsigned kernel. > > > > > > Thinking more about it. Can we just keep track whether a process was > > > ptraced or not and disallow kexec_load() syscall if it was ptraced. > > > (I am assuming that ptrace is the only way to change process code/data). > > > > > > So binaries can be signed offline. Signature verification can take place > > > using kernel keyring at exec() time. And we can keep track of ptraced > > > processes and disallow calling kexec_load() for such processes. If this > > > is implementable, this should take care of following requirement raised > > > by matthew. > > > > > > > > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't > > > been signed by a trusted key that's been built into the kernel, and it > > > must be impossible for anything other than /sbin/kexec to make the kexec > > > system call. > > > * > > > > > > Thoughts? > > > > Eric responded but my mistake he responded to only me. So I will quickly > > put his idea here. > > > > [start quote] > > > > You can't ptrace a process that has a capability you don't. > > > > That should be enforced in security/commoncap/ > > > > [end quote] > > > > This looks like a good idea. Upon verification signed binaries will be > > assigned special capability and then no unsigned binary should be able > > to ptrace signed/verified processes > > That's a good generic solution, which I'm all in favor of, but it > doesn't resolve the latter half of Matthrew's requirement "and it must > be impossible for anything other than /sbin/kexec to make the kexec > system call." Only those executables which have extended capability (say CAP_SIGNATURES_VERIFIED) will be able to call kexec_load() syscall. Only signed executables will get this capability upon signature verification (using keys in kernel keyring only). so any xyz executable will not be able to call kexec_load() until and unless it is signed with keys kernel trusts. This is similar to signed module verification. So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote: > On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: > > [..] > > > > > > > - So say we can sign /sbin/kexec at build time and distros can do that. > > > > - Verify the signature at exec time using kernel keyring and if > > > > verification happens successfully, say process gains extra capability. > > > > - Use this new capability to determine whether kexec_load() will be > > > > successful or not. > > > > > > > > Even if we can do all this, it still has the issue of being able to > > > > stop the process in user space and replace the code at run time > > > > and be able to launch unsigned kernel. > > > > Thinking more about it. Can we just keep track whether a process was > > ptraced or not and disallow kexec_load() syscall if it was ptraced. > > (I am assuming that ptrace is the only way to change process code/data). > > > > So binaries can be signed offline. Signature verification can take place > > using kernel keyring at exec() time. And we can keep track of ptraced > > processes and disallow calling kexec_load() for such processes. If this > > is implementable, this should take care of following requirement raised > > by matthew. > > > > > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't > > been signed by a trusted key that's been built into the kernel, and it > > must be impossible for anything other than /sbin/kexec to make the kexec > > system call. > > * > > > > Thoughts? > > Eric responded but my mistake he responded to only me. So I will quickly > put his idea here. > > [start quote] > > You can't ptrace a process that has a capability you don't. > > That should be enforced in security/commoncap/ > > [end quote] > > This looks like a good idea. Upon verification signed binaries will be > assigned special capability and then no unsigned binary should be able > to ptrace signed/verified processes That's a good generic solution, which I'm all in favor of, but it doesn't resolve the latter half of Matthrew's requirement "and it must be impossible for anything other than /sbin/kexec to make the kexec system call." thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: [..] > > > > > - So say we can sign /sbin/kexec at build time and distros can do that. > > > - Verify the signature at exec time using kernel keyring and if > > > verification happens successfully, say process gains extra capability. > > > - Use this new capability to determine whether kexec_load() will be > > > successful or not. > > > > > > Even if we can do all this, it still has the issue of being able to > > > stop the process in user space and replace the code at run time > > > and be able to launch unsigned kernel. > > Thinking more about it. Can we just keep track whether a process was > ptraced or not and disallow kexec_load() syscall if it was ptraced. > (I am assuming that ptrace is the only way to change process code/data). > > So binaries can be signed offline. Signature verification can take place > using kernel keyring at exec() time. And we can keep track of ptraced > processes and disallow calling kexec_load() for such processes. If this > is implementable, this should take care of following requirement raised > by matthew. > > > It must be impossible for the kernel to launch any /sbin/kexec that hasn't > been signed by a trusted key that's been built into the kernel, and it > must be impossible for anything other than /sbin/kexec to make the kexec > system call. > * > > Thoughts? Eric responded but my mistake he responded to only me. So I will quickly put his idea here. [start quote] You can't ptrace a process that has a capability you don't. That should be enforced in security/commoncap/ [end quote] This looks like a good idea. Upon verification signed binaries will be assigned special capability and then no unsigned binary should be able to ptrace signed/verified processes Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Oct 26, 2012 at 02:37:29PM -0400, Mimi Zohar wrote: > On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote: > > On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: > > > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > > > > > > > On a running system, the package installer, after verifying the package > > > > integrity, would install each file with the associated 'security.ima' > > > > extended attribute. The 'security.evm' digital signature would be > > > > installed with an HMAC, calculated using a system unique key. > > > > > > The idea isn't to prevent /sbin/kexec from being modified after > > > installation - it's to prevent it from being possible to install a > > > system that has a modified /sbin/kexec. Leaving any part of this up to > > > the package installer means that it doesn't solve the problem we're > > > trying to solve here. It must be impossible for the kernel to launch any > > > /sbin/kexec that hasn't been signed by a trusted key that's been built > > > into the kernel, and it must be impossible for anything other than > > > /sbin/kexec to make the kexec system call. > > > > I am kind of lost now so just trying to summarize whatever I have > > learned so far from this thread. > > Thanks for summarizing. > > > - So say we can sign /sbin/kexec at build time and distros can do that. > > - Verify the signature at exec time using kernel keyring and if > > verification happens successfully, say process gains extra capability. > > - Use this new capability to determine whether kexec_load() will be > > successful or not. > > > > Even if we can do all this, it still has the issue of being able to > > stop the process in user space and replace the code at run time > > and be able to launch unsigned kernel. Thinking more about it. Can we just keep track whether a process was ptraced or not and disallow kexec_load() syscall if it was ptraced. (I am assuming that ptrace is the only way to change process code/data). So binaries can be signed offline. Signature verification can take place using kernel keyring at exec() time. And we can keep track of ptraced processes and disallow calling kexec_load() for such processes. If this is implementable, this should take care of following requirement raised by matthew. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. * Thoughts? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Oct 26, 2012 at 02:37:29PM -0400, Mimi Zohar wrote: On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote: On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. I am kind of lost now so just trying to summarize whatever I have learned so far from this thread. Thanks for summarizing. - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. Thinking more about it. Can we just keep track whether a process was ptraced or not and disallow kexec_load() syscall if it was ptraced. (I am assuming that ptrace is the only way to change process code/data). So binaries can be signed offline. Signature verification can take place using kernel keyring at exec() time. And we can keep track of ptraced processes and disallow calling kexec_load() for such processes. If this is implementable, this should take care of following requirement raised by matthew. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. * Thoughts? Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: [..] - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. Thinking more about it. Can we just keep track whether a process was ptraced or not and disallow kexec_load() syscall if it was ptraced. (I am assuming that ptrace is the only way to change process code/data). So binaries can be signed offline. Signature verification can take place using kernel keyring at exec() time. And we can keep track of ptraced processes and disallow calling kexec_load() for such processes. If this is implementable, this should take care of following requirement raised by matthew. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. * Thoughts? Eric responded but my mistake he responded to only me. So I will quickly put his idea here. [start quote] You can't ptrace a process that has a capability you don't. That should be enforced in security/commoncap/ [end quote] This looks like a good idea. Upon verification signed binaries will be assigned special capability and then no unsigned binary should be able to ptrace signed/verified processes Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote: On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: [..] - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. Thinking more about it. Can we just keep track whether a process was ptraced or not and disallow kexec_load() syscall if it was ptraced. (I am assuming that ptrace is the only way to change process code/data). So binaries can be signed offline. Signature verification can take place using kernel keyring at exec() time. And we can keep track of ptraced processes and disallow calling kexec_load() for such processes. If this is implementable, this should take care of following requirement raised by matthew. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. * Thoughts? Eric responded but my mistake he responded to only me. So I will quickly put his idea here. [start quote] You can't ptrace a process that has a capability you don't. That should be enforced in security/commoncap/ [end quote] This looks like a good idea. Upon verification signed binaries will be assigned special capability and then no unsigned binary should be able to ptrace signed/verified processes That's a good generic solution, which I'm all in favor of, but it doesn't resolve the latter half of Matthrew's requirement and it must be impossible for anything other than /sbin/kexec to make the kexec system call. thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote: On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote: On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: [..] - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. Thinking more about it. Can we just keep track whether a process was ptraced or not and disallow kexec_load() syscall if it was ptraced. (I am assuming that ptrace is the only way to change process code/data). So binaries can be signed offline. Signature verification can take place using kernel keyring at exec() time. And we can keep track of ptraced processes and disallow calling kexec_load() for such processes. If this is implementable, this should take care of following requirement raised by matthew. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. * Thoughts? Eric responded but my mistake he responded to only me. So I will quickly put his idea here. [start quote] You can't ptrace a process that has a capability you don't. That should be enforced in security/commoncap/ [end quote] This looks like a good idea. Upon verification signed binaries will be assigned special capability and then no unsigned binary should be able to ptrace signed/verified processes That's a good generic solution, which I'm all in favor of, but it doesn't resolve the latter half of Matthrew's requirement and it must be impossible for anything other than /sbin/kexec to make the kexec system call. Only those executables which have extended capability (say CAP_SIGNATURES_VERIFIED) will be able to call kexec_load() syscall. Only signed executables will get this capability upon signature verification (using keys in kernel keyring only). so any xyz executable will not be able to call kexec_load() until and unless it is signed with keys kernel trusts. This is similar to signed module verification. So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:29:19AM -0400, Mimi Zohar wrote: On Thu, 2012-11-01 at 09:53 -0400, Vivek Goyal wrote: On Thu, Nov 01, 2012 at 09:10:03AM -0400, Vivek Goyal wrote: [..] - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. Thinking more about it. Can we just keep track whether a process was ptraced or not and disallow kexec_load() syscall if it was ptraced. (I am assuming that ptrace is the only way to change process code/data). So binaries can be signed offline. Signature verification can take place using kernel keyring at exec() time. And we can keep track of ptraced processes and disallow calling kexec_load() for such processes. If this is implementable, this should take care of following requirement raised by matthew. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. * Thoughts? Eric responded but my mistake he responded to only me. So I will quickly put his idea here. [start quote] You can't ptrace a process that has a capability you don't. That should be enforced in security/commoncap/ [end quote] This looks like a good idea. Upon verification signed binaries will be assigned special capability and then no unsigned binary should be able to ptrace signed/verified processes That's a good generic solution, which I'm all in favor of, but it doesn't resolve the latter half of Matthrew's requirement and it must be impossible for anything other than /sbin/kexec to make the kexec system call. I think what matthew might have meant that anything other than signed trusted executable should not be able to call kexec_load(). Matthew? And if one wants only /sbin/kexec to call it, then just sign that one so no other executable will be able to call kexec_load(). Though I don't think that's the requirement here. Requirement is that only trusted executables should be able to call kexec_load(). Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:43:04AM -0400, Vivek Goyal wrote: So I think this does satisfy the requirement matthew specified. Isn't it? Matthew, what do you think? Sure, if you can ensure that. You'll need to figure out how to get the build system to sign the userspace binaries and you'll need to ensure that they're statically linked and don't dlopen anything (including the nsswitch modules), but otherwise that should work. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: And if one wants only /sbin/kexec to call it, then just sign that one so no other executable will be able to call kexec_load(). Though I don't think that's the requirement here. Requirement is that only trusted executables should be able to call kexec_load(). Where trusted executables means signed by a key that's present in the system firmware or in the kernel that's signed with a key that's present in the system firmware, sure. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-11-01 at 14:57 +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: And if one wants only /sbin/kexec to call it, then just sign that one so no other executable will be able to call kexec_load(). Though I don't think that's the requirement here. Requirement is that only trusted executables should be able to call kexec_load(). Where trusted executables means signed by a key that's present in the system firmware or in the kernel that's signed with a key that's present in the system firmware, sure. This is starting to sound too restrictive (even though I understand the rationale behind the restrictions). Does this allow for a custom userspace application that among other things also can kexec_load() a new kernel and boot it, for example a customer unique health monitoring app that reboots the system if things are not looking right on the running system? How would a customer go about getting that userspace binary signed and re-signed every time they update their app? There is the option of turning the whole SecureBoot thing off for a system like that but let us assume customer wants to leave that on or does not have the option to turn it off? -- Khalid -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote: On Thu, 2012-11-01 at 14:57 +, Matthew Garrett wrote: On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote: And if one wants only /sbin/kexec to call it, then just sign that one so no other executable will be able to call kexec_load(). Though I don't think that's the requirement here. Requirement is that only trusted executables should be able to call kexec_load(). Where trusted executables means signed by a key that's present in the system firmware or in the kernel that's signed with a key that's present in the system firmware, sure. This is starting to sound too restrictive (even though I understand the rationale behind the restrictions). Does this allow for a custom userspace application that among other things also can kexec_load() a new kernel and boot it, for example a customer unique health monitoring app that reboots the system if things are not looking right on the running system? Only if it's signed with a key that the kernel trusts. How would a customer go about getting that userspace binary signed and re-signed every time they update their app? There is the option of turning the whole SecureBoot thing off for a system like that but let us assume customer wants to leave that on or does not have the option to turn it off? There's ongoing work for providing mechanisms for trusting user keys. If you want Secure Boot turned on, you don't want any untrusted code running in your kernel. If you're happy with untrusted code in your kernel, why are you using Secure Boot? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote: > On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: > > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > > > > > On a running system, the package installer, after verifying the package > > > integrity, would install each file with the associated 'security.ima' > > > extended attribute. The 'security.evm' digital signature would be > > > installed with an HMAC, calculated using a system unique key. > > > > The idea isn't to prevent /sbin/kexec from being modified after > > installation - it's to prevent it from being possible to install a > > system that has a modified /sbin/kexec. Leaving any part of this up to > > the package installer means that it doesn't solve the problem we're > > trying to solve here. It must be impossible for the kernel to launch any > > /sbin/kexec that hasn't been signed by a trusted key that's been built > > into the kernel, and it must be impossible for anything other than > > /sbin/kexec to make the kexec system call. > > I am kind of lost now so just trying to summarize whatever I have > learned so far from this thread. Thanks for summarizing. > - So say we can sign /sbin/kexec at build time and distros can do that. > - Verify the signature at exec time using kernel keyring and if > verification happens successfully, say process gains extra capability. > - Use this new capability to determine whether kexec_load() will be > successful or not. > > Even if we can do all this, it still has the issue of being able to > stop the process in user space and replace the code at run time > and be able to launch unsigned kernel. > > So until and unless we have a good solution to verify application's > integrity/authneticity at the time of kexec_load() system call we > still have the problem. And I don't think we have come up with a > solution for that yet (until and unless I missed something). > > Thanks > Vivek > Agreed, you need a new LSM/integrity hook. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, 2012-10-26 at 19:19 +0100, Matthew Garrett wrote: > On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote: > > On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote: > > > and it must be impossible for anything other than > > > /sbin/kexec to make the kexec system call. > > > > Permission is a MAC issue. :) > > It's a MAC issue that has to be implemented in the kernel. We can't > depend on userspace loading any kind of policy. Still a MAC issue, that problably could be addressed by capabilities. I suggest you post this issue on the LSM mailing list. Please cc: Serge, as the capabilities maintainer. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote: > On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote: > > and it must be impossible for anything other than > > /sbin/kexec to make the kexec system call. > > Permission is a MAC issue. :) It's a MAC issue that has to be implemented in the kernel. We can't depend on userspace loading any kind of policy. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote: > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > > > On a running system, the package installer, after verifying the package > > integrity, would install each file with the associated 'security.ima' > > extended attribute. The 'security.evm' digital signature would be > > installed with an HMAC, calculated using a system unique key. > > The idea isn't to prevent /sbin/kexec from being modified after > installation - it's to prevent it from being possible to install a > system that has a modified /sbin/kexec. Understood. > Leaving any part of this up to > the package installer means that it doesn't solve the problem we're > trying to solve here. It must be impossible for the kernel to launch any > /sbin/kexec that hasn't been signed by a trusted key that's been built > into the kernel, With Dmitry's patch "5e0d1a4 ima: added policy support for security.ima type", or something similar, we can force 'security.ima' to a specific type, in this case, a digital signature. With that patch, this shouldn't be a problem. > and it must be impossible for anything other than > /sbin/kexec to make the kexec system call. Permission is a MAC issue. :) thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > > > On a running system, the package installer, after verifying the package > > integrity, would install each file with the associated 'security.ima' > > extended attribute. The 'security.evm' digital signature would be > > installed with an HMAC, calculated using a system unique key. > > The idea isn't to prevent /sbin/kexec from being modified after > installation - it's to prevent it from being possible to install a > system that has a modified /sbin/kexec. Leaving any part of this up to > the package installer means that it doesn't solve the problem we're > trying to solve here. It must be impossible for the kernel to launch any > /sbin/kexec that hasn't been signed by a trusted key that's been built > into the kernel, and it must be impossible for anything other than > /sbin/kexec to make the kexec system call. I am kind of lost now so just trying to summarize whatever I have learned so far from this thread. - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. So until and unless we have a good solution to verify application's integrity/authneticity at the time of kexec_load() system call we still have the problem. And I don't think we have come up with a solution for that yet (until and unless I missed something). Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. I am kind of lost now so just trying to summarize whatever I have learned so far from this thread. - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. So until and unless we have a good solution to verify application's integrity/authneticity at the time of kexec_load() system call we still have the problem. And I don't think we have come up with a solution for that yet (until and unless I missed something). Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote: On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Understood. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, With Dmitry's patch 5e0d1a4 ima: added policy support for security.ima type, or something similar, we can force 'security.ima' to a specific type, in this case, a digital signature. With that patch, this shouldn't be a problem. and it must be impossible for anything other than /sbin/kexec to make the kexec system call. Permission is a MAC issue. :) thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote: On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote: and it must be impossible for anything other than /sbin/kexec to make the kexec system call. Permission is a MAC issue. :) It's a MAC issue that has to be implemented in the kernel. We can't depend on userspace loading any kind of policy. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, 2012-10-26 at 19:19 +0100, Matthew Garrett wrote: On Fri, Oct 26, 2012 at 01:59:34PM -0400, Mimi Zohar wrote: On Fri, 2012-10-26 at 03:39 +0100, Matthew Garrett wrote: and it must be impossible for anything other than /sbin/kexec to make the kexec system call. Permission is a MAC issue. :) It's a MAC issue that has to be implemented in the kernel. We can't depend on userspace loading any kind of policy. Still a MAC issue, that problably could be addressed by capabilities. I suggest you post this issue on the LSM mailing list. Please cc: Serge, as the capabilities maintainer. thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Fri, 2012-10-26 at 13:06 -0400, Vivek Goyal wrote: On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote: On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. I am kind of lost now so just trying to summarize whatever I have learned so far from this thread. Thanks for summarizing. - So say we can sign /sbin/kexec at build time and distros can do that. - Verify the signature at exec time using kernel keyring and if verification happens successfully, say process gains extra capability. - Use this new capability to determine whether kexec_load() will be successful or not. Even if we can do all this, it still has the issue of being able to stop the process in user space and replace the code at run time and be able to launch unsigned kernel. So until and unless we have a good solution to verify application's integrity/authneticity at the time of kexec_load() system call we still have the problem. And I don't think we have come up with a solution for that yet (until and unless I missed something). Thanks Vivek Agreed, you need a new LSM/integrity hook. thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Matthew Garrett writes: > On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > >> On a running system, the package installer, after verifying the package >> integrity, would install each file with the associated 'security.ima' >> extended attribute. The 'security.evm' digital signature would be >> installed with an HMAC, calculated using a system unique key. > > The idea isn't to prevent /sbin/kexec from being modified after > installation - it's to prevent it from being possible to install a > system that has a modified /sbin/kexec. Leaving any part of this up to > the package installer means that it doesn't solve the problem we're > trying to solve here. It must be impossible for the kernel to launch any > /sbin/kexec that hasn't been signed by a trusted key that's been built > into the kernel, and it must be impossible for anything other than > /sbin/kexec to make the kexec system call. The 'security.capability' attribute modulo weirdness with the security bounding set gives us the necessary tools to allow /sbin/kexec to make the system call. The primary trick with this is to limit the installer in such as way that we can trust the installer even on a system on which root has been compromised. Trusting the installer is the same class of problem as trusting /sbin/kexec, and to me a much more interesting problem as it keeps critical system files from being tampered with. It sounds like there are some tricky details to work through but this direction of system integrity looks like it is worth pursuing, regardless of how we handle a signed /sbin/kexec. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: > On a running system, the package installer, after verifying the package > integrity, would install each file with the associated 'security.ima' > extended attribute. The 'security.evm' digital signature would be > installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-10-25 at 14:55 -0400, Vivek Goyal wrote: > On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote: > > On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote: > > > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: > > > > > > [..] > > > > IMA-appraisal verifies the integrity of file data, while EVM verifies > > > > the integrity of the file metadata, such as LSM and IMA-appraisal > > > > labels. Both 'security.ima' and 'security.evm' can contain digital > > > > signatures. > > > > > > But the private key for creating these digital signature needs to be > > > on the target system? > > > > > > Thanks > > > Vivek > > > > Absolutely not. The public key needs to be added to the _ima or _evm > > keyrings. Roberto Sassu modified dracut and later made equivalent > > changes to systemd. Both have been upstreamed. > > Putting public key in _ima or _evm keyring is not the problem. This is > just the verification part. > > > Dmitry has a package > > that labels the filesystem called ima-evm-utils, which supports hash > > (IMA), hmac(EVM) and digital signatures(both). > > > > We're hoping that distro's would label all immutable files, not only elf > > executables, with digital signatures and mutable files with a hash. > > So this labeling (digital signing) can happen at build time? There is nothing inherently preventing it from happening at build time. Elana Reshetova gave a talk at LSS 2012 on modifying RPM http://lwn.net/Articles/518265/. > I suspect you need labeling to happen at system install time? If yes, > installer does not have the private key to sign anything. The installed system needs to be labeled, but how that occurs is dependent on your environment (eg. flash, rpm based install). Neither of these mechanisms would require the build private key. On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. > IOW, if distro sign a file, they will most likely put signatures in > ELF header (something along the lines of signing PE/COFF binaries). Rusty was definitely against putting the signature in the ELF header for kernel modules. Why would this be any different? > But > I think you need digital signatures to be put in security.ima which are > stored in xattrs and xattrs are not generated till you put file in > question on target file system. > > Thanks > Vivek The 'security.ima' digital signature would be created as part of the build process and stored as an extended attribute with the file, like other metadata. On install, the file, extended attributes and other metadata would be copied to the target file system. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Thu, 2012-10-25 at 09:54 -0400, Vivek Goyal wrote: > On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote: > > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: > > > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: > > > > Matthew Garrett writes: > > > > > > > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: > > > > > > > > > >> But what about creation of a new program which can call kexec_load() > > > > >> and execute an unsigned kernel. Doesn't look like that will be > > > > >> prevented using IMA. > > > > Like the existing kernel modules, kexec_load() is not file descriptor > > based. There isn't an LSM or IMA-appraisal hook here. > > > > > > > Right. Trusting userspace would require a new system call that passes > > > > > in > > > > > a signature of the userspace binary, and the kernel would then have > > > > > to > > > > > verify the ELF object in memory in order to ensure that it > > > > > matches the signature. Verifying that the copy on the filesystem is > > > > > unmodified isn't adequate - an attacker could simply have paused the > > > > > process and injected code. > > > > I haven't looked at kexec_load() in detail, but like kernel modules, I > > think the better solution would be to pass a file descriptor, especially > > if you're discussing a new system call. (cc'ing Kees.) > > If we decide to go for a new system call, then yes it looks like passing > fd will make sense. > > > > > > > Verifying the copy on the filesystem at exec time is perfectly adequate > > > > for gating extra permissions. Certainly that is the model everywhere > > > > else in the signed key chain. > > > > > > > > Where IMA falls short is there is no offline signing capability in IMA > > > > itself. I think EVM may fix that. > > > > I'm not sure what you mean by offline signing capability. IMA-appraisal > > verifies a file's 'security.ima' xattr, which may contain a hash or a > > digital signature. EVM protects a file's metadata, including > > 'security.ima'. 'security.evm' can be either an hmac or a digital > > signature. > > By offline we mean that signature generation/signing does not happen on > system in question. It happens say on build time. IIUC, in case of IMA, > security.ima is generated and signed on the system and that means private > key needs to be present on the system? The signature for 'security.ima' can definitely be created offline. 'security.evm' can also be created offline, as long as the target's inode and other metadata doesn't change. > We wanted something like module signing where modules are signed at > build time and verification happens at load time but no private key > needs to be present on the system. Modules are identifiable. As long as you have some mechanism to identify mutable vs immutable files during build, there shouldn't be a problem. I'd use the same private key for signing modules and all others. > > > > > [ CCing lkml. I think it is a good idea to open discussion to wider > > > audience. Also CCing IMA/EVM folks ] > > > > thanks! > > > > > Based on reading following wiki page, looks like EVM also does not allow > > > offline signing capability. And EVM is protecting IMA data to protect > > > against offline attack. If we can assume that unisgned kernels can't be > > > booted on the platform, then EVM might not be a strict requirement in > > > this case. > > > > > So as you said, one of the main problem with IMA use to verify /sbin/kexec > > > is that IMA does not provide offline signing capability. > > > > ? > > See above. > > > > > > > > > > > > Realistically, the only solution here is for > > > > > the kernel to verify that the kernel it's about to boot is signed and > > > > > for it not to take any untrusted executable code from userspace. > > > > >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is > > problematic. IMA maintains a measurement list and extends a PCR with > > the file hash. The measurement list and PCR value are used to attest to > > the integrity of the running system. As the original measurement list > > is lost after kexec, but the PCR value hasn't been reset, the > > measuremnet list and PCR value won't agree. > > > > > > Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is > > > > perfectly reasonable, and realistic. In fact finding a way to trust > > > > small bits of userspace even if root is compromised seems a far superior > > > > model to simply solving the signing problem for /sbin/kexec. > > > > Huh? I don't understand what you're suggesting. Once root has been > > compromised, that's it. > > > > > > Although I do admit some part of the kexec process will need to verify > > > > keys on the images we decide to boot. > > > > Which keys? Isn't the kernel module key builtin to the kernel and > > included in the kernel image signature? > > I think Eric is referring to verifying bzImage signature. One can sign >
Re: Kdump with signed images
On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote: > On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote: > > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: > > > > [..] > > > IMA-appraisal verifies the integrity of file data, while EVM verifies > > > the integrity of the file metadata, such as LSM and IMA-appraisal > > > labels. Both 'security.ima' and 'security.evm' can contain digital > > > signatures. > > > > But the private key for creating these digital signature needs to be > > on the target system? > > > > Thanks > > Vivek > > Absolutely not. The public key needs to be added to the _ima or _evm > keyrings. Roberto Sassu modified dracut and later made equivalent > changes to systemd. Both have been upstreamed. Putting public key in _ima or _evm keyring is not the problem. This is just the verification part. > Dmitry has a package > that labels the filesystem called ima-evm-utils, which supports hash > (IMA), hmac(EVM) and digital signatures(both). > > We're hoping that distro's would label all immutable files, not only elf > executables, with digital signatures and mutable files with a hash. So this labeling (digital signing) can happen at build time? I suspect you need labeling to happen at system install time? If yes, installer does not have the private key to sign anything. IOW, if distro sign a file, they will most likely put signatures in ELF header (something along the lines of signing PE/COFF binaries). But I think you need digital signatures to be put in security.ima which are stored in xattrs and xattrs are not generated till you put file in question on target file system. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote: > On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: > > [..] > > IMA-appraisal verifies the integrity of file data, while EVM verifies > > the integrity of the file metadata, such as LSM and IMA-appraisal > > labels. Both 'security.ima' and 'security.evm' can contain digital > > signatures. > > But the private key for creating these digital signature needs to be > on the target system? > > Thanks > Vivek Absolutely not. The public key needs to be added to the _ima or _evm keyrings. Roberto Sassu modified dracut and later made equivalent changes to systemd. Both have been upstreamed. Dmitry has a package that labels the filesystem called ima-evm-utils, which supports hash (IMA), hmac(EVM) and digital signatures(both). We're hoping that distro's would label all immutable files, not only elf executables, with digital signatures and mutable files with a hash. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: [..] > IMA-appraisal verifies the integrity of file data, while EVM verifies > the integrity of the file metadata, such as LSM and IMA-appraisal > labels. Both 'security.ima' and 'security.evm' can contain digital > signatures. But the private key for creating these digital signature needs to be on the target system? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote: > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: > > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: > > > Matthew Garrett writes: > > > > > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: > > > > > > > >> But what about creation of a new program which can call kexec_load() > > > >> and execute an unsigned kernel. Doesn't look like that will be > > > >> prevented using IMA. > > Like the existing kernel modules, kexec_load() is not file descriptor > based. There isn't an LSM or IMA-appraisal hook here. > > > > > Right. Trusting userspace would require a new system call that passes > > > > in > > > > a signature of the userspace binary, and the kernel would then have to > > > > verify the ELF object in memory in order to ensure that it > > > > matches the signature. Verifying that the copy on the filesystem is > > > > unmodified isn't adequate - an attacker could simply have paused the > > > > process and injected code. > > I haven't looked at kexec_load() in detail, but like kernel modules, I > think the better solution would be to pass a file descriptor, especially > if you're discussing a new system call. (cc'ing Kees.) If we decide to go for a new system call, then yes it looks like passing fd will make sense. > > > > Verifying the copy on the filesystem at exec time is perfectly adequate > > > for gating extra permissions. Certainly that is the model everywhere > > > else in the signed key chain. > > > > > > Where IMA falls short is there is no offline signing capability in IMA > > > itself. I think EVM may fix that. > > I'm not sure what you mean by offline signing capability. IMA-appraisal > verifies a file's 'security.ima' xattr, which may contain a hash or a > digital signature. EVM protects a file's metadata, including > 'security.ima'. 'security.evm' can be either an hmac or a digital > signature. By offline we mean that signature generation/signing does not happen on system in question. It happens say on build time. IIUC, in case of IMA, security.ima is generated and signed on the system and that means private key needs to be present on the system? We wanted something like module signing where modules are signed at build time and verification happens at load time but no private key needs to be present on the system. > > > [ CCing lkml. I think it is a good idea to open discussion to wider > > audience. Also CCing IMA/EVM folks ] > > thanks! > > > Based on reading following wiki page, looks like EVM also does not allow > > offline signing capability. And EVM is protecting IMA data to protect > > against offline attack. If we can assume that unisgned kernels can't be > > booted on the platform, then EVM might not be a strict requirement in > > this case. > > > So as you said, one of the main problem with IMA use to verify /sbin/kexec > > is that IMA does not provide offline signing capability. > > ? See above. > > > > > > > > Realistically, the only solution here is for > > > > the kernel to verify that the kernel it's about to boot is signed and > > > > for it not to take any untrusted executable code from userspace. > > >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is > problematic. IMA maintains a measurement list and extends a PCR with > the file hash. The measurement list and PCR value are used to attest to > the integrity of the running system. As the original measurement list > is lost after kexec, but the PCR value hasn't been reset, the > measuremnet list and PCR value won't agree. > > > > Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is > > > perfectly reasonable, and realistic. In fact finding a way to trust > > > small bits of userspace even if root is compromised seems a far superior > > > model to simply solving the signing problem for /sbin/kexec. > > Huh? I don't understand what you're suggesting. Once root has been > compromised, that's it. > > > > Although I do admit some part of the kexec process will need to verify > > > keys on the images we decide to boot. > > Which keys? Isn't the kernel module key builtin to the kernel and > included in the kernel image signature? I think Eric is referring to verifying bzImage signature. One can sign PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec verify the integrity/authenticity of bzImage and figure a way out to verify integrity/authenticity of /sbin/kexec. That way one does not have to change current logic and most of the logic of kexec/kdump can still be in user space. Otherwise we shall probably have to implement a new system call which takes kernel and initrd as input parameters and kernel does signature verification and prepares bzImage for loading. This is like re-writing kexec/kdump again with restricted functionality. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Re: [RFC] Kdump with signed images
On Wed, 2012-10-24 at 23:44 -0700, Kees Cook wrote: > On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar wrote: > > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: > >> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: > >> > Matthew Garrett writes: > >> > > >> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: > >> > > > >> > >> But what about creation of a new program which can call kexec_load() > >> > >> and execute an unsigned kernel. Doesn't look like that will be > >> > >> prevented using IMA. > > > > Like the existing kernel modules, kexec_load() is not file descriptor > > based. There isn't an LSM or IMA-appraisal hook here. > > > >> > > Right. Trusting userspace would require a new system call that passes > >> > > in > >> > > a signature of the userspace binary, and the kernel would then have to > >> > > verify the ELF object in memory in order to ensure that it > >> > > matches the signature. Verifying that the copy on the filesystem is > >> > > unmodified isn't adequate - an attacker could simply have paused the > >> > > process and injected code. > > > > I haven't looked at kexec_load() in detail, but like kernel modules, I > > think the better solution would be to pass a file descriptor, especially > > if you're discussing a new system call. (cc'ing Kees.) > > Yeah, it looks like kexec_load could use a nearly identical new > syscall that uses an fd, just like init_module is getting. > > Another area, kind of related, is firmware loading. The interface for > that is a bit weird, if the documentation is up to date: > > echo 1 > /sys/$DEVPATH/loading > cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data > echo 0 > /sys/$DEVPATH/loading > > It looks like there's a filp on the reader: > > static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj, > struct bin_attribute *bin_attr, > char *buffer, loff_t offset, size_t count) > > But it's not clear to me yet if we'll actually get the firmware file, > or if we'll get a random pipe we can't evaluate. Has anyone looked at > handling "signed" firmware loading yet? > > -Kees Only looked at it enough to mention at LSS, that it's needed. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar wrote: > On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: >> On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: >> > Matthew Garrett writes: >> > >> > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: >> > > >> > >> But what about creation of a new program which can call kexec_load() >> > >> and execute an unsigned kernel. Doesn't look like that will be >> > >> prevented using IMA. > > Like the existing kernel modules, kexec_load() is not file descriptor > based. There isn't an LSM or IMA-appraisal hook here. > >> > > Right. Trusting userspace would require a new system call that passes in >> > > a signature of the userspace binary, and the kernel would then have to >> > > verify the ELF object in memory in order to ensure that it >> > > matches the signature. Verifying that the copy on the filesystem is >> > > unmodified isn't adequate - an attacker could simply have paused the >> > > process and injected code. > > I haven't looked at kexec_load() in detail, but like kernel modules, I > think the better solution would be to pass a file descriptor, especially > if you're discussing a new system call. (cc'ing Kees.) Yeah, it looks like kexec_load could use a nearly identical new syscall that uses an fd, just like init_module is getting. Another area, kind of related, is firmware loading. The interface for that is a bit weird, if the documentation is up to date: echo 1 > /sys/$DEVPATH/loading cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data echo 0 > /sys/$DEVPATH/loading It looks like there's a filp on the reader: static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buffer, loff_t offset, size_t count) But it's not clear to me yet if we'll actually get the firmware file, or if we'll get a random pipe we can't evaluate. Has anyone looked at handling "signed" firmware loading yet? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote: > On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote: > > Vivek Goyal writes: > > > > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote: > > > > > > [..] > > >> > >> There are 3 options for trusting /sbin/kexec. There are IMA and > > >> > >> EMA, > > >> > >> and it is conceivable to have ELF note sections with signatures for > > >> > >> executables. > > >> > > > > >> > > Can you please tell more about what is EMA and IMA. I did quick > > >> > > google > > >> > > and could not find much. > > >> > > > >> > That should have been EVM and IMA. Look under security/integrity/. I > > >> > don't know much about them but they appear to be security modules with > > >> > a > > >> > focus on verifying checksum or perhaps encrypted hashes of executables > > >> > are consistent. > > >> > > >> I will do some quick search there and I see if I can understand > > >> something. > > >> > > > > > > Ok, I quickly went through following paper. > > > > > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf > > > > > > So it looks like that IMA can store the hashes of files and at execute > > > time ensure those hashes are unchanged to protect against the possibility > > > of modification of files. IMA-appraisal originally was hashed based, but Dmitry Kasatkin added digital signature support. Both have been upstreamed. > > > But what about creation of a new program which can call kexec_load() > > > and execute an unsigned kernel. Doesn't look like that will be > > > prevented using IMA. Assuming the IMA policy syntax is updated to require 'security.ima' to contain a digital signature, then it is only a question of protecting the _ima and _evm keyrings. (Dmitry has such a patch waiting to be reviewed.) So the new program would have to be vetted by someone trusted. > > > Whole idea behind UEFI secure boot seems to be that all signing happens > > > outside the running system and now only signed code can run with higher > > > priviliges. > > > > No. UEFI secure boot has absolutely nothing todo with this. > > > > UEFI secure boot is about not being able to hijack the code EFI runs > > directly. Full stop. > > > > Some people would like to implment a security policy that says > > you can't boot an untrusted version of windows from linux if you have > > booted with UEFI secure boot, so they don't get their bootloader > > signatures revoked by microsoft. > > > > A security model relying on Microsoft's key is totally uniteresting to > > me. Either signing at the UEFI level is of no use or Microsofts key > > will fall again to the combined assult of every cracker and every > > governmental dirty cyber ops division attacking it. Not to mention that > > Microsoft has little incentive to keep linux booting. > > > > I think it is reasonable to be able to support a policy where we can't > > boot unsigned versions of Microsoft windows. However beyond being able > > to exclude booting windows being one criteria for our policy mechanism > > please don't even start to justify things with that ridiculous security > > policy even indirectly. > > > > > IMA seems to be only protecting against only making sure > > > existing binaries are not modifed but it does not seem to prevent against > > > installation of new binaries and these binaries take advantage of kexec > > > system call to load an unsigned kernel. The IMA/IMA-appraisal policy dictates what needs to be appraised. The default ima-appraisal policy appraises all files owned by root. > > I believe you can combine IMA with EVM signed security attributes where > > the EVM signing key is offline, and the verification key is in the > > kernel. > > > > The combination of IMA and EVM gets very close to being able to sign > > executables offline and be able to update them. > > [ Again CCing lkml and IMA/EVM folks ] > > After little reading, my understanding is EVM also does not support > offline signing. > > http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page > > Given the fact EVM protects IMA data (security.ima), which is generated > inline, I am not sure how EVM can sign images offline. > > I might have misunderstood things, please correct me if that's not the > case. > > Thanks > Vivek > IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote: [..] There are 3 options for trusting /sbin/kexec. There are IMA and EMA, and it is conceivable to have ELF note sections with signatures for executables. Can you please tell more about what is EMA and IMA. I did quick google and could not find much. That should have been EVM and IMA. Look under security/integrity/. I don't know much about them but they appear to be security modules with a focus on verifying checksum or perhaps encrypted hashes of executables are consistent. I will do some quick search there and I see if I can understand something. Ok, I quickly went through following paper. http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf So it looks like that IMA can store the hashes of files and at execute time ensure those hashes are unchanged to protect against the possibility of modification of files. IMA-appraisal originally was hashed based, but Dmitry Kasatkin added digital signature support. Both have been upstreamed. But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Assuming the IMA policy syntax is updated to require 'security.ima' to contain a digital signature, then it is only a question of protecting the _ima and _evm keyrings. (Dmitry has such a patch waiting to be reviewed.) So the new program would have to be vetted by someone trusted. Whole idea behind UEFI secure boot seems to be that all signing happens outside the running system and now only signed code can run with higher priviliges. No. UEFI secure boot has absolutely nothing todo with this. UEFI secure boot is about not being able to hijack the code EFI runs directly. Full stop. Some people would like to implment a security policy that says you can't boot an untrusted version of windows from linux if you have booted with UEFI secure boot, so they don't get their bootloader signatures revoked by microsoft. A security model relying on Microsoft's key is totally uniteresting to me. Either signing at the UEFI level is of no use or Microsofts key will fall again to the combined assult of every cracker and every governmental dirty cyber ops division attacking it. Not to mention that Microsoft has little incentive to keep linux booting. I think it is reasonable to be able to support a policy where we can't boot unsigned versions of Microsoft windows. However beyond being able to exclude booting windows being one criteria for our policy mechanism please don't even start to justify things with that ridiculous security policy even indirectly. IMA seems to be only protecting against only making sure existing binaries are not modifed but it does not seem to prevent against installation of new binaries and these binaries take advantage of kexec system call to load an unsigned kernel. The IMA/IMA-appraisal policy dictates what needs to be appraised. The default ima-appraisal policy appraises all files owned by root. I believe you can combine IMA with EVM signed security attributes where the EVM signing key is offline, and the verification key is in the kernel. The combination of IMA and EVM gets very close to being able to sign executables offline and be able to update them. [ Again CCing lkml and IMA/EVM folks ] After little reading, my understanding is EVM also does not support offline signing. http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page Given the fact EVM protects IMA data (security.ima), which is generated inline, I am not sure how EVM can sign images offline. I might have misunderstood things, please correct me if that's not the case. Thanks Vivek IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) Yeah, it looks like kexec_load could use a nearly identical new syscall that uses an fd, just like init_module is getting. Another area, kind of related, is firmware loading. The interface for that is a bit weird, if the documentation is up to date: echo 1 /sys/$DEVPATH/loading cat $HOTPLUG_FW_DIR/$FIRMWARE /sysfs/$DEVPATH/data echo 0 /sys/$DEVPATH/loading It looks like there's a filp on the reader: static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buffer, loff_t offset, size_t count) But it's not clear to me yet if we'll actually get the firmware file, or if we'll get a random pipe we can't evaluate. Has anyone looked at handling signed firmware loading yet? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Wed, 2012-10-24 at 23:44 -0700, Kees Cook wrote: On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) Yeah, it looks like kexec_load could use a nearly identical new syscall that uses an fd, just like init_module is getting. Another area, kind of related, is firmware loading. The interface for that is a bit weird, if the documentation is up to date: echo 1 /sys/$DEVPATH/loading cat $HOTPLUG_FW_DIR/$FIRMWARE /sysfs/$DEVPATH/data echo 0 /sys/$DEVPATH/loading It looks like there's a filp on the reader: static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buffer, loff_t offset, size_t count) But it's not clear to me yet if we'll actually get the firmware file, or if we'll get a random pipe we can't evaluate. Has anyone looked at handling signed firmware loading yet? -Kees Only looked at it enough to mention at LSS, that it's needed. Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) If we decide to go for a new system call, then yes it looks like passing fd will make sense. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. By offline we mean that signature generation/signing does not happen on system in question. It happens say on build time. IIUC, in case of IMA, security.ima is generated and signed on the system and that means private key needs to be present on the system? We wanted something like module signing where modules are signed at build time and verification happens at load time but no private key needs to be present on the system. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] thanks! Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. ? See above. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? I think Eric is referring to verifying bzImage signature. One can sign PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec verify the integrity/authenticity of bzImage and figure a way out to verify integrity/authenticity of /sbin/kexec. That way one does not have to change current logic and most of the logic of kexec/kdump can still be in user space. Otherwise we shall probably have to implement a new system call which takes kernel and initrd as input parameters and kernel does signature verification and prepares bzImage for loading. This is like re-writing kexec/kdump again with restricted functionality. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: Kdump with signed images
On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: [..] IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. But the private key for creating these digital signature needs to be on the target system? Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote: On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: [..] IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. But the private key for creating these digital signature needs to be on the target system? Thanks Vivek Absolutely not. The public key needs to be added to the _ima or _evm keyrings. Roberto Sassu modified dracut and later made equivalent changes to systemd. Both have been upstreamed. Dmitry has a package that labels the filesystem called ima-evm-utils, which supports hash (IMA), hmac(EVM) and digital signatures(both). We're hoping that distro's would label all immutable files, not only elf executables, with digital signatures and mutable files with a hash. thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote: On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote: On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: [..] IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. But the private key for creating these digital signature needs to be on the target system? Thanks Vivek Absolutely not. The public key needs to be added to the _ima or _evm keyrings. Roberto Sassu modified dracut and later made equivalent changes to systemd. Both have been upstreamed. Putting public key in _ima or _evm keyring is not the problem. This is just the verification part. Dmitry has a package that labels the filesystem called ima-evm-utils, which supports hash (IMA), hmac(EVM) and digital signatures(both). We're hoping that distro's would label all immutable files, not only elf executables, with digital signatures and mutable files with a hash. So this labeling (digital signing) can happen at build time? I suspect you need labeling to happen at system install time? If yes, installer does not have the private key to sign anything. IOW, if distro sign a file, they will most likely put signatures in ELF header (something along the lines of signing PE/COFF binaries). But I think you need digital signatures to be put in security.ima which are stored in xattrs and xattrs are not generated till you put file in question on target file system. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Thu, 2012-10-25 at 09:54 -0400, Vivek Goyal wrote: On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) If we decide to go for a new system call, then yes it looks like passing fd will make sense. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. By offline we mean that signature generation/signing does not happen on system in question. It happens say on build time. IIUC, in case of IMA, security.ima is generated and signed on the system and that means private key needs to be present on the system? The signature for 'security.ima' can definitely be created offline. 'security.evm' can also be created offline, as long as the target's inode and other metadata doesn't change. We wanted something like module signing where modules are signed at build time and verification happens at load time but no private key needs to be present on the system. Modules are identifiable. As long as you have some mechanism to identify mutable vs immutable files during build, there shouldn't be a problem. I'd use the same private key for signing modules and all others. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] thanks! Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. ? See above. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? I think Eric is referring to verifying bzImage signature. One can sign PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec verify the integrity/authenticity of bzImage and figure a way out to verify integrity/authenticity of /sbin/kexec. Yes that would work. IMA-appraisal/EVM would verify and enforce the
Re: Kdump with signed images
On Thu, 2012-10-25 at 14:55 -0400, Vivek Goyal wrote: On Thu, Oct 25, 2012 at 02:40:21PM -0400, Mimi Zohar wrote: On Thu, 2012-10-25 at 10:10 -0400, Vivek Goyal wrote: On Thu, Oct 25, 2012 at 02:10:01AM -0400, Mimi Zohar wrote: [..] IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. But the private key for creating these digital signature needs to be on the target system? Thanks Vivek Absolutely not. The public key needs to be added to the _ima or _evm keyrings. Roberto Sassu modified dracut and later made equivalent changes to systemd. Both have been upstreamed. Putting public key in _ima or _evm keyring is not the problem. This is just the verification part. Dmitry has a package that labels the filesystem called ima-evm-utils, which supports hash (IMA), hmac(EVM) and digital signatures(both). We're hoping that distro's would label all immutable files, not only elf executables, with digital signatures and mutable files with a hash. So this labeling (digital signing) can happen at build time? There is nothing inherently preventing it from happening at build time. Elana Reshetova gave a talk at LSS 2012 on modifying RPM http://lwn.net/Articles/518265/. I suspect you need labeling to happen at system install time? If yes, installer does not have the private key to sign anything. The installed system needs to be labeled, but how that occurs is dependent on your environment (eg. flash, rpm based install). Neither of these mechanisms would require the build private key. On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. IOW, if distro sign a file, they will most likely put signatures in ELF header (something along the lines of signing PE/COFF binaries). Rusty was definitely against putting the signature in the ELF header for kernel modules. Why would this be any different? But I think you need digital signatures to be put in security.ima which are stored in xattrs and xattrs are not generated till you put file in question on target file system. Thanks Vivek The 'security.ima' digital signature would be created as part of the build process and stored as an extended attribute with the file, like other metadata. On install, the file, extended attributes and other metadata would be copied to the target file system. Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
Matthew Garrett m...@redhat.com writes: On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote: On a running system, the package installer, after verifying the package integrity, would install each file with the associated 'security.ima' extended attribute. The 'security.evm' digital signature would be installed with an HMAC, calculated using a system unique key. The idea isn't to prevent /sbin/kexec from being modified after installation - it's to prevent it from being possible to install a system that has a modified /sbin/kexec. Leaving any part of this up to the package installer means that it doesn't solve the problem we're trying to solve here. It must be impossible for the kernel to launch any /sbin/kexec that hasn't been signed by a trusted key that's been built into the kernel, and it must be impossible for anything other than /sbin/kexec to make the kexec system call. The 'security.capability' attribute modulo weirdness with the security bounding set gives us the necessary tools to allow /sbin/kexec to make the system call. The primary trick with this is to limit the installer in such as way that we can trust the installer even on a system on which root has been compromised. Trusting the installer is the same class of problem as trusting /sbin/kexec, and to me a much more interesting problem as it keeps critical system files from being tampered with. It sounds like there are some tricky details to work through but this direction of system integrity looks like it is worth pursuing, regardless of how we handle a signed /sbin/kexec. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: > On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: > > Matthew Garrett writes: > > > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: > > > > > >> But what about creation of a new program which can call kexec_load() > > >> and execute an unsigned kernel. Doesn't look like that will be > > >> prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. > > > Right. Trusting userspace would require a new system call that passes in > > > a signature of the userspace binary, and the kernel would then have to > > > verify the ELF object in memory in order to ensure that it > > > matches the signature. Verifying that the copy on the filesystem is > > > unmodified isn't adequate - an attacker could simply have paused the > > > process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) > > Verifying the copy on the filesystem at exec time is perfectly adequate > > for gating extra permissions. Certainly that is the model everywhere > > else in the signed key chain. > > > > Where IMA falls short is there is no offline signing capability in IMA > > itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. > [ CCing lkml. I think it is a good idea to open discussion to wider > audience. Also CCing IMA/EVM folks ] thanks! > Based on reading following wiki page, looks like EVM also does not allow > offline signing capability. And EVM is protecting IMA data to protect > against offline attack. If we can assume that unisgned kernels can't be > booted on the platform, then EVM might not be a strict requirement in > this case. > So as you said, one of the main problem with IMA use to verify /sbin/kexec > is that IMA does not provide offline signing capability. ? > > > > > Realistically, the only solution here is for > > > the kernel to verify that the kernel it's about to boot is signed and > > > for it not to take any untrusted executable code from userspace. >From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. > > Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is > > perfectly reasonable, and realistic. In fact finding a way to trust > > small bits of userspace even if root is compromised seems a far superior > > model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. > > Although I do admit some part of the kexec process will need to verify > > keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? > It should be an option, isn't it? Either /sbin/kexec can try to verify the > integrity of kernel or we extend try to extend kexec() system call to also > pass the signature of kernel and let kernel verify it (as you mentioned > previously). > > Thanks > Vivek > As suggested above, please consider passing a file descriptor, at least in addition, if not in lieu of a signature. thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote: > > > > [..] > >> > >> There are 3 options for trusting /sbin/kexec. There are IMA and EMA, > >> > >> and it is conceivable to have ELF note sections with signatures for > >> > >> executables. > >> > > > >> > > Can you please tell more about what is EMA and IMA. I did quick google > >> > > and could not find much. > >> > > >> > That should have been EVM and IMA. Look under security/integrity/. I > >> > don't know much about them but they appear to be security modules with a > >> > focus on verifying checksum or perhaps encrypted hashes of executables > >> > are consistent. > >> > >> I will do some quick search there and I see if I can understand something. > >> > > > > Ok, I quickly went through following paper. > > > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf > > > > So it looks like that IMA can store the hashes of files and at execute > > time ensure those hashes are unchanged to protect against the possibility > > of modification of files. > > > > But what about creation of a new program which can call kexec_load() > > and execute an unsigned kernel. Doesn't look like that will be > > prevented using IMA. > > > > Whole idea behind UEFI secure boot seems to be that all signing happens > > outside the running system and now only signed code can run with higher > > priviliges. > > No. UEFI secure boot has absolutely nothing todo with this. > > UEFI secure boot is about not being able to hijack the code EFI runs > directly. Full stop. > > Some people would like to implment a security policy that says > you can't boot an untrusted version of windows from linux if you have > booted with UEFI secure boot, so they don't get their bootloader > signatures revoked by microsoft. > > A security model relying on Microsoft's key is totally uniteresting to > me. Either signing at the UEFI level is of no use or Microsofts key > will fall again to the combined assult of every cracker and every > governmental dirty cyber ops division attacking it. Not to mention that > Microsoft has little incentive to keep linux booting. > > I think it is reasonable to be able to support a policy where we can't > boot unsigned versions of Microsoft windows. However beyond being able > to exclude booting windows being one criteria for our policy mechanism > please don't even start to justify things with that ridiculous security > policy even indirectly. > > > IMA seems to be only protecting against only making sure > > existing binaries are not modifed but it does not seem to prevent against > > installation of new binaries and these binaries take advantage of kexec > > system call to load an unsigned kernel. > > I believe you can combine IMA with EVM signed security attributes where > the EVM signing key is offline, and the verification key is in the > kernel. > > The combination of IMA and EVM gets very close to being able to sign > executables offline and be able to update them. [ Again CCing lkml and IMA/EVM folks ] After little reading, my understanding is EVM also does not support offline signing. http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page Given the fact EVM protects IMA data (security.ima), which is generated inline, I am not sure how EVM can sign images offline. I might have misunderstood things, please correct me if that's not the case. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: > Matthew Garrett writes: > > > On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: > > > >> But what about creation of a new program which can call kexec_load() > >> and execute an unsigned kernel. Doesn't look like that will be > >> prevented using IMA. > > > > Right. Trusting userspace would require a new system call that passes in > > a signature of the userspace binary, and the kernel would then have to > > verify the ELF object in memory in order to ensure that it > > matches the signature. Verifying that the copy on the filesystem is > > unmodified isn't adequate - an attacker could simply have paused the > > process and injected code. > > Verifying the copy on the filesystem at exec time is perfectly adequate > for gating extra permissions. Certainly that is the model everywhere > else in the signed key chain. > > Where IMA falls short is there is no offline signing capability in IMA > itself. I think EVM may fix that. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. > > > Realistically, the only solution here is for > > the kernel to verify that the kernel it's about to boot is signed and > > for it not to take any untrusted executable code from userspace. > > Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is > perfectly reasonable, and realistic. In fact finding a way to trust > small bits of userspace even if root is compromised seems a far superior > model to simply solving the signing problem for /sbin/kexec. > > Although I do admit some part of the kexec process will need to verify > keys on the images we decide to boot. It should be an option, isn't it? Either /sbin/kexec can try to verify the integrity of kernel or we extend try to extend kexec() system call to also pass the signature of kernel and let kernel verify it (as you mentioned previously). Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. It should be an option, isn't it? Either /sbin/kexec can try to verify the integrity of kernel or we extend try to extend kexec() system call to also pass the signature of kernel and let kernel verify it (as you mentioned previously). Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kdump with signed images
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote: Vivek Goyal vgo...@redhat.com writes: On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote: [..] There are 3 options for trusting /sbin/kexec. There are IMA and EMA, and it is conceivable to have ELF note sections with signatures for executables. Can you please tell more about what is EMA and IMA. I did quick google and could not find much. That should have been EVM and IMA. Look under security/integrity/. I don't know much about them but they appear to be security modules with a focus on verifying checksum or perhaps encrypted hashes of executables are consistent. I will do some quick search there and I see if I can understand something. Ok, I quickly went through following paper. http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf So it looks like that IMA can store the hashes of files and at execute time ensure those hashes are unchanged to protect against the possibility of modification of files. But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Whole idea behind UEFI secure boot seems to be that all signing happens outside the running system and now only signed code can run with higher priviliges. No. UEFI secure boot has absolutely nothing todo with this. UEFI secure boot is about not being able to hijack the code EFI runs directly. Full stop. Some people would like to implment a security policy that says you can't boot an untrusted version of windows from linux if you have booted with UEFI secure boot, so they don't get their bootloader signatures revoked by microsoft. A security model relying on Microsoft's key is totally uniteresting to me. Either signing at the UEFI level is of no use or Microsofts key will fall again to the combined assult of every cracker and every governmental dirty cyber ops division attacking it. Not to mention that Microsoft has little incentive to keep linux booting. I think it is reasonable to be able to support a policy where we can't boot unsigned versions of Microsoft windows. However beyond being able to exclude booting windows being one criteria for our policy mechanism please don't even start to justify things with that ridiculous security policy even indirectly. IMA seems to be only protecting against only making sure existing binaries are not modifed but it does not seem to prevent against installation of new binaries and these binaries take advantage of kexec system call to load an unsigned kernel. I believe you can combine IMA with EVM signed security attributes where the EVM signing key is offline, and the verification key is in the kernel. The combination of IMA and EVM gets very close to being able to sign executables offline and be able to update them. [ Again CCing lkml and IMA/EVM folks ] After little reading, my understanding is EVM also does not support offline signing. http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page Given the fact EVM protects IMA data (security.ima), which is generated inline, I am not sure how EVM can sign images offline. I might have misunderstood things, please correct me if that's not the case. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kdump with signed images
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] thanks! Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. ? Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? It should be an option, isn't it? Either /sbin/kexec can try to verify the integrity of kernel or we extend try to extend kexec() system call to also pass the signature of kernel and let kernel verify it (as you mentioned previously). Thanks Vivek As suggested above, please consider passing a file descriptor, at least in addition, if not in lieu of a signature. thanks, Mimi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
