* [PATCH v6 0/3] ima-evm-utils: Add --keyid option @ 2021-05-11 11:56 Vitaly Chikunov 2021-05-11 11:56 ` [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing Vitaly Chikunov ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Vitaly Chikunov @ 2021-05-11 11:56 UTC (permalink / raw) To: Mimi Zohar, Dmitry Kasatkin, linux-integrity Allow user to set signature's keyid using `--keyid' option. Keyid should correspond to SKID in certificate. When keyid is calculated using SHA-1 in libimaevm it may mismatch keyid extracted by the kernel from SKID of certificate (the way public key is presented to the kernel), thus making signatures not verifiable. This may happen when certificate is using non SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2). As a last resort user may specify arbitrary keyid using the new option. Certificate @filename could be used instead of the hex number. And, third option is to read keyid from the cert appended to the key file. These commits create backward incompatible ABI change for libimaevm, thus soname should be incremented on release. Changes from v5: - ima_read_keyid renamed to imaevm_read_keyid and its return value inverted to match other API functions. Suggested by Stefan Berger - Rebased over next-testing. Noticed by Mimi Zohar. Changes from v4: - ima_read_keyid() API changed. As suggested by Stefan Berger. Changes from v3: - ima_read_keyid() is improved to better support both use cases. Changes from v2: - Add ima_read_keyid() function to libemaevm and use it in both evmctl (for --keyid) and sign_hash_v2() (for concatenated PEMs). Suggested by Stefan Berger. - Autodetect PEM by openssl reading it instead of magic string. Suggested by Stefan Berger. - Trivial change: s/unsigned long int/unsigned long/ for keyid type. Changes from v1: - Extract keyid from cert associated to key file. - Use sizeof instead of constant. Changes since rfc version: - `imaevm_params.keyid' now stored as native integer (instead of network order). Suggested by Stefan Berger. - Added support for `--keyid=@filename'. Vitaly Chikunov (3): ima-evm-utils: Allow manual setting keyid for signing ima-evm-utils: Allow manual setting keyid from a cert file ima-evm-utils: Read keyid from the cert appended to the key file README | 5 +++ src/evmctl.c | 27 ++++++++++++++ src/imaevm.h | 2 + src/libimaevm.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++-- tests/sign_verify.test | 2 + 5 files changed, 132 insertions(+), 3 deletions(-) -- 2.11.0 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-05-11 11:56 [PATCH v6 0/3] ima-evm-utils: Add --keyid option Vitaly Chikunov @ 2021-05-11 11:56 ` Vitaly Chikunov 2021-06-25 12:21 ` Mimi Zohar 2021-05-11 11:56 ` [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file Vitaly Chikunov 2021-05-11 11:56 ` [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file Vitaly Chikunov 2 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-05-11 11:56 UTC (permalink / raw) To: Mimi Zohar, Dmitry Kasatkin, linux-integrity Allow user to set signature's keyid using `--keyid' option. Keyid should correspond to SKID in certificate, when keyid is calculated using SHA-1 in libimaevm it may mismatch keyid extracted by the kernel from SKID of certificate (the way public key is presented to the kernel), thus making signatures not verifiable. This may happen when certificate is using non SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2). As a last resort user may specify arbitrary keyid using the new option. This commit creates ABI change for libimaevm, because of adding additional parameter to imaevm_params - newer libimaevm cannot work with older clients. Signed-off-by: Vitaly Chikunov <vt@altlinux.org> Reported-by: Elvira Khabirova <lineprinter0@gmail.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> --- README | 1 + src/evmctl.c | 15 +++++++++++++++ src/imaevm.h | 1 + src/libimaevm.c | 8 +++++--- tests/sign_verify.test | 1 + 5 files changed, 23 insertions(+), 3 deletions(-) diff --git a/README b/README index 321045d..8cd66e0 100644 --- a/README +++ b/README @@ -48,6 +48,7 @@ OPTIONS --xattr-user store xattrs in user namespace (for testing purposes) --rsa use RSA key type and signing scheme v1 -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem) + --keyid val overwrite signature keyid with a value (for signing) -o, --portable generate portable EVM signatures -p, --pass password for encrypted signing key -r, --recursive recurse into directories (sign) diff --git a/src/evmctl.c b/src/evmctl.c index 7a6f202..d853d34 100644 --- a/src/evmctl.c +++ b/src/evmctl.c @@ -2514,6 +2514,7 @@ static void usage(void) " --xattr-user store xattrs in user namespace (for testing purposes)\n" " --rsa use RSA key type and signing scheme v1\n" " -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n" + " --keyid val overwrite signature keyid with a value (for signing)\n" " -o, --portable generate portable EVM signatures\n" " -p, --pass password for encrypted signing key\n" " -r, --recursive recurse into directories (sign)\n" @@ -2594,6 +2595,7 @@ static struct option opts[] = { {"ignore-violations", 0, 0, 141}, {"pcrs", 1, 0, 142}, {"verify-bank", 2, 0, 143}, + {"keyid", 1, 0, 144}, {} }; @@ -2638,6 +2640,8 @@ int main(int argc, char *argv[]) { int err = 0, c, lind; ENGINE *eng = NULL; + unsigned long keyid; + char *eptr; #if !(OPENSSL_VERSION_NUMBER < 0x10100000) OPENSSL_init_crypto( @@ -2785,6 +2789,17 @@ int main(int argc, char *argv[]) case 143: verify_bank = optarg; break; + case 144: + errno = 0; + keyid = strtoul(optarg, &eptr, 16); + if (errno || eptr - optarg != strlen(optarg) || + keyid == ULONG_MAX || keyid > UINT_MAX || + keyid == 0) { + log_err("Invalid keyid value.\n"); + exit(1); + } + imaevm_params.keyid = keyid; + break; case '?': exit(1); break; diff --git a/src/imaevm.h b/src/imaevm.h index 4503919..9f38059 100644 --- a/src/imaevm.h +++ b/src/imaevm.h @@ -196,6 +196,7 @@ struct libimaevm_params { const char *hash_algo; const char *keyfile; const char *keypass; + uint32_t keyid; /* keyid overriding value, unless 0. */ }; struct RSA_ASN1_template { diff --git a/src/libimaevm.c b/src/libimaevm.c index fa6c278..481d29d 100644 --- a/src/libimaevm.c +++ b/src/libimaevm.c @@ -45,6 +45,7 @@ #include <sys/param.h> #include <sys/stat.h> #include <asm/byteorder.h> +#include <arpa/inet.h> #include <unistd.h> #include <dirent.h> #include <string.h> @@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, const EVP_MD *md; size_t sigsize; const char *st; - uint32_t keyid; if (!hash) { log_err("sign_hash_v2: hash is null\n"); @@ -932,8 +932,10 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, return -1; } - calc_keyid_v2(&keyid, name, pkey); - hdr->keyid = keyid; + if (imaevm_params.keyid) + hdr->keyid = htonl(imaevm_params.keyid); + else + calc_keyid_v2(&hdr->keyid, name, pkey); st = "EVP_PKEY_CTX_new"; if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) diff --git a/tests/sign_verify.test b/tests/sign_verify.test index 3d7aa51..eccf5fa 100755 --- a/tests/sign_verify.test +++ b/tests/sign_verify.test @@ -365,6 +365,7 @@ sign_verify rsa1024 sha256 0x0301 --rsa sign_verify rsa1024 md5 0x030201:K:0080 sign_verify rsa1024 sha1 0x030202:K:0080 sign_verify rsa1024 sha224 0x030207:K:0080 +expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd sign_verify rsa1024 sha256 0x030204:K:0080 try_different_keys try_different_sigs -- 2.11.0 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-05-11 11:56 ` [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing Vitaly Chikunov @ 2021-06-25 12:21 ` Mimi Zohar 2021-06-26 0:42 ` Vitaly Chikunov 0 siblings, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-25 12:21 UTC (permalink / raw) To: Vitaly Chikunov, Mimi Zohar, Dmitry Kasatkin, linux-integrity On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > Allow user to set signature's keyid using `--keyid' option. Keyid should > correspond to SKID in certificate, when keyid is calculated using SHA-1 > in libimaevm it may mismatch keyid extracted by the kernel from SKID of > certificate (the way public key is presented to the kernel), thus making > signatures not verifiable. This may happen when certificate is using non > SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2). > As a last resort user may specify arbitrary keyid using the new option. > > This commit creates ABI change for libimaevm, because of adding > additional parameter to imaevm_params - newer libimaevm cannot work > with older clients. Thank you for highlighting the ABI change. > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org> > Reported-by: Elvira Khabirova <lineprinter0@gmail.com> > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > --- > README | 1 + > src/evmctl.c | 15 +++++++++++++++ > src/imaevm.h | 1 + > src/libimaevm.c | 8 +++++--- > tests/sign_verify.test | 1 + > 5 files changed, 23 insertions(+), 3 deletions(-) > > diff --git a/README b/README > index 321045d..8cd66e0 100644 > --- a/README > +++ b/README > @@ -48,6 +48,7 @@ OPTIONS > --xattr-user store xattrs in user namespace (for testing purposes) > --rsa use RSA key type and signing scheme v1 > -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem) > + --keyid val overwrite signature keyid with a value (for signing) > -o, --portable generate portable EVM signatures > -p, --pass password for encrypted signing key > -r, --recursive recurse into directories (sign) > diff --git a/src/evmctl.c b/src/evmctl.c > index 7a6f202..d853d34 100644 > --- a/src/evmctl.c > +++ b/src/evmctl.c > @@ -2514,6 +2514,7 @@ static void usage(void) > " --xattr-user store xattrs in user namespace (for testing purposes)\n" > " --rsa use RSA key type and signing scheme v1\n" > " -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n" > + " --keyid val overwrite signature keyid with a value (for signing)\n" > " -o, --portable generate portable EVM signatures\n" > " -p, --pass password for encrypted signing key\n" > " -r, --recursive recurse into directories (sign)\n" > @@ -2594,6 +2595,7 @@ static struct option opts[] = { > {"ignore-violations", 0, 0, 141}, > {"pcrs", 1, 0, 142}, > {"verify-bank", 2, 0, 143}, > + {"keyid", 1, 0, 144}, > {} > > }; > @@ -2638,6 +2640,8 @@ int main(int argc, char *argv[]) > { > int err = 0, c, lind; > ENGINE *eng = NULL; > + unsigned long keyid; > + char *eptr; > > #if !(OPENSSL_VERSION_NUMBER < 0x10100000) > OPENSSL_init_crypto( > @@ -2785,6 +2789,17 @@ int main(int argc, char *argv[]) > case 143: > verify_bank = optarg; > break; > + case 144: > + errno = 0; > + keyid = strtoul(optarg, &eptr, 16); > + if (errno || eptr - optarg != strlen(optarg) || Before using eptr, shouldn't there be a null test? It's unclear what verifying the resulting string length against the user provided length provides. Requiring the optarg value to be prefixed with "0x" would simplify the strlen test. The length would be 2 * sizeof uint + 2. (The subsequent patch wouldn't need a contrived prefix.) > + keyid == ULONG_MAX || keyid > UINT_MAX || Why are both of these tests required? When ULONG_MAX and UINT_MAX aren't the same, wouldn't ULONG_MAX always be bigger than UINT_MAX? > + keyid == 0) { > + log_err("Invalid keyid value.\n"); > + exit(1); > + } > + imaevm_params.keyid = keyid; > + break; > case '?': > exit(1); > break; > diff --git a/src/imaevm.h b/src/imaevm.h > index 4503919..9f38059 100644 > --- a/src/imaevm.h > +++ b/src/imaevm.h > @@ -196,6 +196,7 @@ struct libimaevm_params { > const char *hash_algo; > const char *keyfile; > const char *keypass; > + uint32_t keyid; /* keyid overriding value, unless 0. */ If keyid is suppose to be big endiran format, please annotate it in the comment. > }; > > struct RSA_ASN1_template { > diff --git a/src/libimaevm.c b/src/libimaevm.c > index fa6c278..481d29d 100644 > --- a/src/libimaevm.c > +++ b/src/libimaevm.c > @@ -45,6 +45,7 @@ > #include <sys/param.h> > #include <sys/stat.h> > #include <asm/byteorder.h> > +#include <arpa/inet.h> > #include <unistd.h> > #include <dirent.h> > #include <string.h> > @@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > const EVP_MD *md; > size_t sigsize; > const char *st; > - uint32_t keyid; > > if (!hash) { > log_err("sign_hash_v2: hash is null\n"); > @@ -932,8 +932,10 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > return -1; > } > > - calc_keyid_v2(&keyid, name, pkey); > - hdr->keyid = keyid; > + if (imaevm_params.keyid) > + hdr->keyid = htonl(imaevm_params.keyid); > + else > + calc_keyid_v2(&hdr->keyid, name, pkey); > At what point should imaevm_params.keyid be converted to big endian - on usage or setting it? Mimi > st = "EVP_PKEY_CTX_new"; > if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) > diff --git a/tests/sign_verify.test b/tests/sign_verify.test > index 3d7aa51..eccf5fa 100755 > --- a/tests/sign_verify.test > +++ b/tests/sign_verify.test > @@ -365,6 +365,7 @@ sign_verify rsa1024 sha256 0x0301 --rsa > sign_verify rsa1024 md5 0x030201:K:0080 > sign_verify rsa1024 sha1 0x030202:K:0080 > sign_verify rsa1024 sha224 0x030207:K:0080 > +expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd > sign_verify rsa1024 sha256 0x030204:K:0080 > try_different_keys > try_different_sigs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-25 12:21 ` Mimi Zohar @ 2021-06-26 0:42 ` Vitaly Chikunov 2021-06-28 20:50 ` Mimi Zohar 0 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-26 0:42 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Mimi, On Fri, Jun 25, 2021 at 08:21:46AM -0400, Mimi Zohar wrote: > On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > Allow user to set signature's keyid using `--keyid' option. Keyid should > > correspond to SKID in certificate, when keyid is calculated using SHA-1 > > in libimaevm it may mismatch keyid extracted by the kernel from SKID of > > certificate (the way public key is presented to the kernel), thus making > > signatures not verifiable. This may happen when certificate is using non > > SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2). > > As a last resort user may specify arbitrary keyid using the new option. > > > > This commit creates ABI change for libimaevm, because of adding > > additional parameter to imaevm_params - newer libimaevm cannot work > > with older clients. > > Thank you for highlighting the ABI change. > > > > > Signed-off-by: Vitaly Chikunov <vt@altlinux.org> > > Reported-by: Elvira Khabirova <lineprinter0@gmail.com> > > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > > --- > > README | 1 + > > src/evmctl.c | 15 +++++++++++++++ > > src/imaevm.h | 1 + > > src/libimaevm.c | 8 +++++--- > > tests/sign_verify.test | 1 + > > 5 files changed, 23 insertions(+), 3 deletions(-) > > > > diff --git a/README b/README > > index 321045d..8cd66e0 100644 > > --- a/README > > +++ b/README > > @@ -48,6 +48,7 @@ OPTIONS > > --xattr-user store xattrs in user namespace (for testing purposes) > > --rsa use RSA key type and signing scheme v1 > > -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem) > > + --keyid val overwrite signature keyid with a value (for signing) > > -o, --portable generate portable EVM signatures > > -p, --pass password for encrypted signing key > > -r, --recursive recurse into directories (sign) > > diff --git a/src/evmctl.c b/src/evmctl.c > > index 7a6f202..d853d34 100644 > > --- a/src/evmctl.c > > +++ b/src/evmctl.c > > @@ -2514,6 +2514,7 @@ static void usage(void) > > " --xattr-user store xattrs in user namespace (for testing purposes)\n" > > " --rsa use RSA key type and signing scheme v1\n" > > " -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n" > > + " --keyid val overwrite signature keyid with a value (for signing)\n" > > " -o, --portable generate portable EVM signatures\n" > > " -p, --pass password for encrypted signing key\n" > > " -r, --recursive recurse into directories (sign)\n" > > @@ -2594,6 +2595,7 @@ static struct option opts[] = { > > {"ignore-violations", 0, 0, 141}, > > {"pcrs", 1, 0, 142}, > > {"verify-bank", 2, 0, 143}, > > + {"keyid", 1, 0, 144}, > > {} > > > > }; > > @@ -2638,6 +2640,8 @@ int main(int argc, char *argv[]) > > { > > int err = 0, c, lind; > > ENGINE *eng = NULL; > > + unsigned long keyid; > > + char *eptr; > > > > #if !(OPENSSL_VERSION_NUMBER < 0x10100000) > > OPENSSL_init_crypto( > > @@ -2785,6 +2789,17 @@ int main(int argc, char *argv[]) > > case 143: > > verify_bank = optarg; > > break; > > + case 144: > > + errno = 0; > > + keyid = strtoul(optarg, &eptr, 16); > > + if (errno || eptr - optarg != strlen(optarg) || > > Before using eptr, shouldn't there be a null test? AFAIK, strtoul() should never return NULL there. strtoul(3): If endptr is not NULL, strtoul() stores the address of the first invalid character in *endptr. If there were no digits at all, strtoul() stores the original value of nptr in *endptr (and returns 0). In particular, if *nptr is not '\0' but **endptr is '\0' on return, the entire string is valid. > It's unclear what > verifying the resulting string length against the user provided length > provides. It shows that whole string is parsed by strtoul, otherwise there is some unparsed garbage, which mean this was not valid number. > Requiring the optarg value to be prefixed with "0x" would > simplify the strlen test. The length would be 2 * sizeof uint + 2. > (The subsequent patch wouldn't need a contrived prefix.) (I do not understand this remark at the moment.) Base 16 will let user pass keyid just as a string, copy-pasting from somewhere else. > > > + keyid == ULONG_MAX || keyid > UINT_MAX || > > Why are both of these tests required? When ULONG_MAX and UINT_MAX > aren't the same, wouldn't ULONG_MAX always be bigger than UINT_MAX? ULONG_MAX is special return value of strtoul. UINT_MAX is a maximum capacity of our keyid variable. So, in the case they are different there is two tests. This also shows that both conditions are checked, without need to solve them in the head. > > > + keyid == 0) { > > + log_err("Invalid keyid value.\n"); > > + exit(1); > > + } > > + imaevm_params.keyid = keyid; > > + break; > > case '?': > > exit(1); > > break; > > diff --git a/src/imaevm.h b/src/imaevm.h > > index 4503919..9f38059 100644 > > --- a/src/imaevm.h > > +++ b/src/imaevm.h > > @@ -196,6 +196,7 @@ struct libimaevm_params { > > const char *hash_algo; > > const char *keyfile; > > const char *keypass; > > + uint32_t keyid; /* keyid overriding value, unless 0. */ > > If keyid is suppose to be big endiran format, please annotate it in the > comment. It isn't. > > > }; > > > > struct RSA_ASN1_template { > > diff --git a/src/libimaevm.c b/src/libimaevm.c > > index fa6c278..481d29d 100644 > > --- a/src/libimaevm.c > > +++ b/src/libimaevm.c > > @@ -45,6 +45,7 @@ > > #include <sys/param.h> > > #include <sys/stat.h> > > #include <asm/byteorder.h> > > +#include <arpa/inet.h> > > #include <unistd.h> > > #include <dirent.h> > > #include <string.h> > > @@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > > const EVP_MD *md; > > size_t sigsize; > > const char *st; > > - uint32_t keyid; > > > > if (!hash) { > > log_err("sign_hash_v2: hash is null\n"); > > @@ -932,8 +932,10 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > > return -1; > > } > > > > - calc_keyid_v2(&keyid, name, pkey); > > - hdr->keyid = keyid; > > + if (imaevm_params.keyid) > > + hdr->keyid = htonl(imaevm_params.keyid); > > + else > > + calc_keyid_v2(&hdr->keyid, name, pkey); > > > At what point should imaevm_params.keyid be converted to big endian - > on usage or setting it? On usage (when storing into header). Thanks, > > Mimi > > > st = "EVP_PKEY_CTX_new"; > > if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) > > diff --git a/tests/sign_verify.test b/tests/sign_verify.test > > index 3d7aa51..eccf5fa 100755 > > --- a/tests/sign_verify.test > > +++ b/tests/sign_verify.test > > @@ -365,6 +365,7 @@ sign_verify rsa1024 sha256 0x0301 --rsa > > sign_verify rsa1024 md5 0x030201:K:0080 > > sign_verify rsa1024 sha1 0x030202:K:0080 > > sign_verify rsa1024 sha224 0x030207:K:0080 > > +expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd > > sign_verify rsa1024 sha256 0x030204:K:0080 > > try_different_keys > > try_different_sigs > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-26 0:42 ` Vitaly Chikunov @ 2021-06-28 20:50 ` Mimi Zohar 2021-06-29 1:32 ` Vitaly Chikunov 0 siblings, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-28 20:50 UTC (permalink / raw) To: Vitaly Chikunov Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Hi Vitaly, Thank you for the detailed explanation. On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > Requiring the optarg value to be prefixed with "0x" would > > simplify the strlen test. > > (The subsequent patch wouldn't need a contrived prefix.) > > (I do not understand this remark at the moment.) > > Base 16 will let user pass keyid just as a string, copy-pasting from > somewhere else. strtoul() supports prefixing the ascii-hex string with "0x". To differentiate between a keyid and pathname, why not require the keyid be prefixed with "0x", as opposed to requiring the pathname to be prefixed with '@', like "--keyid @/path/to/cert.pem". The new test would be "OPTS=--keyid=0xaabbccdd" thanks, Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-28 20:50 ` Mimi Zohar @ 2021-06-29 1:32 ` Vitaly Chikunov 2021-06-30 16:39 ` Mimi Zohar 0 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-29 1:32 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Mimi, On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > Thank you for the detailed explanation. > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > Requiring the optarg value to be prefixed with "0x" would > > > simplify the strlen test. > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > (I do not understand this remark at the moment.) > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > somewhere else. > > strtoul() supports prefixing the ascii-hex string with "0x". To > differentiate between a keyid and pathname, why not require the keyid > be prefixed with "0x", as opposed to requiring the pathname to be > prefixed with '@', like "--keyid @/path/to/cert.pem". I wanted to avoid (filename vs keyid) ambiguity of the argument to `--keyid' - if user have file named "0x00112233" they would have hard time passing it to `--keyid'. But, it's impossible to have keyid string starting with "@". So, "@" perfectly distinguish type of `--keyid' argument but "0x" isn't. Also, in some software (zip, rar) "@" is common prefix meaning value should be taken from the specified file. But, yes, "@" is not common in Unix environments. Do you want me to create separate option like `--keyid-from-file'? Thanks, > > The new test would be "OPTS=--keyid=0xaabbccdd" > > thanks, > > Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-29 1:32 ` Vitaly Chikunov @ 2021-06-30 16:39 ` Mimi Zohar 2021-06-30 19:44 ` Vitaly Chikunov 0 siblings, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-30 16:39 UTC (permalink / raw) To: Vitaly Chikunov Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Hi Vitaly, On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > Mimi, > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > > > Thank you for the detailed explanation. > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > > > Requiring the optarg value to be prefixed with "0x" would > > > > simplify the strlen test. > > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > > > (I do not understand this remark at the moment.) > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > > somewhere else. > > > > strtoul() supports prefixing the ascii-hex string with "0x". To > > differentiate between a keyid and pathname, why not require the keyid > > be prefixed with "0x", as opposed to requiring the pathname to be > > prefixed with '@', like "--keyid @/path/to/cert.pem". > > I wanted to avoid (filename vs keyid) ambiguity of the argument to > `--keyid' - if user have file named "0x00112233" they would have hard > time passing it to `--keyid'. But, it's impossible to have keyid string > starting with "@". So, "@" perfectly distinguish type of `--keyid' > argument but "0x" isn't. > > Also, in some software (zip, rar) "@" is common prefix meaning value > should be taken from the specified file. But, yes, "@" is not common > in Unix environments. Do you want me to create separate option like > `--keyid-from-file'? It's highly unlikely that both the filename and pathname would be prefixed with "0x". Defining a new option might be a good idea. Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- from-cert. thanks, Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-30 16:39 ` Mimi Zohar @ 2021-06-30 19:44 ` Vitaly Chikunov 2021-06-30 20:47 ` Mimi Zohar 0 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-30 19:44 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Mimi, On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote: > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > > > > > Thank you for the detailed explanation. > > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > > > > > Requiring the optarg value to be prefixed with "0x" would > > > > > simplify the strlen test. > > > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > > > > > (I do not understand this remark at the moment.) > > > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > > > somewhere else. > > > > > > strtoul() supports prefixing the ascii-hex string with "0x". To > > > differentiate between a keyid and pathname, why not require the keyid > > > be prefixed with "0x", as opposed to requiring the pathname to be > > > prefixed with '@', like "--keyid @/path/to/cert.pem". > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to > > `--keyid' - if user have file named "0x00112233" they would have hard > > time passing it to `--keyid'. But, it's impossible to have keyid string > > starting with "@". So, "@" perfectly distinguish type of `--keyid' > > argument but "0x" isn't. > > > > Also, in some software (zip, rar) "@" is common prefix meaning value > > should be taken from the specified file. But, yes, "@" is not common > > in Unix environments. Do you want me to create separate option like > > `--keyid-from-file'? > > It's highly unlikely that both the filename and pathname would be > prefixed with "0x". Defining a new option might be a good idea. > Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- > from-cert. It's not unlikely, because people may want to keep cert files named or symlinked by keyid. (For example, local cert database keep cert files symlinked like `f30dd6ad.0'.) I will add an option, most understandable, perhaps, is `--keyid-from-cert'. Also, I will remove base 16 from --keyid argument. Thanks, > > thanks, > > Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-30 19:44 ` Vitaly Chikunov @ 2021-06-30 20:47 ` Mimi Zohar 2021-06-30 21:10 ` Vitaly Chikunov 0 siblings, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-30 20:47 UTC (permalink / raw) To: Vitaly Chikunov Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Hi Vitaly, On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote: > On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote: > > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > > > > > > > Thank you for the detailed explanation. > > > > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > > > > > > > Requiring the optarg value to be prefixed with "0x" would > > > > > > simplify the strlen test. > > > > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > > > > > > > (I do not understand this remark at the moment.) > > > > > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > > > > somewhere else. > > > > > > > > strtoul() supports prefixing the ascii-hex string with "0x". To > > > > differentiate between a keyid and pathname, why not require the keyid > > > > be prefixed with "0x", as opposed to requiring the pathname to be > > > > prefixed with '@', like "--keyid @/path/to/cert.pem". > > > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to > > > `--keyid' - if user have file named "0x00112233" they would have hard > > > time passing it to `--keyid'. But, it's impossible to have keyid string > > > starting with "@". So, "@" perfectly distinguish type of `--keyid' > > > argument but "0x" isn't. > > > > > > Also, in some software (zip, rar) "@" is common prefix meaning value > > > should be taken from the specified file. But, yes, "@" is not common > > > in Unix environments. Do you want me to create separate option like > > > `--keyid-from-file'? > > > > It's highly unlikely that both the filename and pathname would be > > prefixed with "0x". Defining a new option might be a good idea. > > Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- > > from-cert. > > It's not unlikely, because people may want to keep cert files named or > symlinked by keyid. (For example, local cert database keep cert files > symlinked like `f30dd6ad.0'.) > > I will add an option, most understandable, perhaps, is `--keyid-from-cert'. > > Also, I will remove base 16 from --keyid argument. I must be missing something. "openssl x509", "keyctl show %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump" all display the skid in hex. Why would anyone provide the skid as something other than in hex? thanks, Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-30 20:47 ` Mimi Zohar @ 2021-06-30 21:10 ` Vitaly Chikunov 2021-06-30 21:32 ` Mimi Zohar 0 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-30 21:10 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin Mimi, On Wed, Jun 30, 2021 at 04:47:53PM -0400, Mimi Zohar wrote: > On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote: > > On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote: > > > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > > > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > > > > > > > > > Thank you for the detailed explanation. > > > > > > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > > > > > > > > > Requiring the optarg value to be prefixed with "0x" would > > > > > > > simplify the strlen test. > > > > > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > > > > > > > > > (I do not understand this remark at the moment.) > > > > > > > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > > > > > somewhere else. > > > > > > > > > > strtoul() supports prefixing the ascii-hex string with "0x". To > > > > > differentiate between a keyid and pathname, why not require the keyid > > > > > be prefixed with "0x", as opposed to requiring the pathname to be > > > > > prefixed with '@', like "--keyid @/path/to/cert.pem". > > > > > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to > > > > `--keyid' - if user have file named "0x00112233" they would have hard > > > > time passing it to `--keyid'. But, it's impossible to have keyid string > > > > starting with "@". So, "@" perfectly distinguish type of `--keyid' > > > > argument but "0x" isn't. > > > > > > > > Also, in some software (zip, rar) "@" is common prefix meaning value > > > > should be taken from the specified file. But, yes, "@" is not common > > > > in Unix environments. Do you want me to create separate option like > > > > `--keyid-from-file'? > > > > > > It's highly unlikely that both the filename and pathname would be > > > prefixed with "0x". Defining a new option might be a good idea. > > > Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- > > > from-cert. > > > > It's not unlikely, because people may want to keep cert files named or > > symlinked by keyid. (For example, local cert database keep cert files > > symlinked like `f30dd6ad.0'.) > > > > I will add an option, most understandable, perhaps, is `--keyid-from-cert'. > > > > Also, I will remove base 16 from --keyid argument. > > I must be missing something. "openssl x509", "keyctl show > %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump" > all display the skid in hex. Why would anyone provide the skid as > something other than in hex? Ah, I thought you want '0x' prefix mandatory. Will not remove base 16 then. Also, /proc/keys shows keyid without '0x' prefix. Thanks, > > thanks, > > Mimi > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing 2021-06-30 21:10 ` Vitaly Chikunov @ 2021-06-30 21:32 ` Mimi Zohar 0 siblings, 0 replies; 21+ messages in thread From: Mimi Zohar @ 2021-06-30 21:32 UTC (permalink / raw) To: Vitaly Chikunov Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity, Dmitry V. Levin On Thu, 2021-07-01 at 00:10 +0300, Vitaly Chikunov wrote: > Mimi, > > On Wed, Jun 30, 2021 at 04:47:53PM -0400, Mimi Zohar wrote: > > On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote: > > > On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote: > > > > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote: > > > > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote: > > > > > > > > > > > > Thank you for the detailed explanation. > > > > > > > > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote: > > > > > > > > > > > > > > Requiring the optarg value to be prefixed with "0x" would > > > > > > > > simplify the strlen test. > > > > > > > > (The subsequent patch wouldn't need a contrived prefix.) > > > > > > > > > > > > > > (I do not understand this remark at the moment.) > > > > > > > > > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from > > > > > > > somewhere else. > > > > > > > > > > > > strtoul() supports prefixing the ascii-hex string with "0x". To > > > > > > differentiate between a keyid and pathname, why not require the keyid > > > > > > be prefixed with "0x", as opposed to requiring the pathname to be > > > > > > prefixed with '@', like "--keyid @/path/to/cert.pem". > > > > > > > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to > > > > > `--keyid' - if user have file named "0x00112233" they would have hard > > > > > time passing it to `--keyid'. But, it's impossible to have keyid string > > > > > starting with "@". So, "@" perfectly distinguish type of `--keyid' > > > > > argument but "0x" isn't. > > > > > > > > > > Also, in some software (zip, rar) "@" is common prefix meaning value > > > > > should be taken from the specified file. But, yes, "@" is not common > > > > > in Unix environments. Do you want me to create separate option like > > > > > `--keyid-from-file'? > > > > > > > > It's highly unlikely that both the filename and pathname would be > > > > prefixed with "0x". Defining a new option might be a good idea. > > > > Possibly naming it --extract-cert-keyid, ---cert-keyid, or --keyid- > > > > from-cert. > > > > > > It's not unlikely, because people may want to keep cert files named or > > > symlinked by keyid. (For example, local cert database keep cert files > > > symlinked like `f30dd6ad.0'.) > > > > > > I will add an option, most understandable, perhaps, is `--keyid-from-cert'. > > > > > > Also, I will remove base 16 from --keyid argument. > > > > I must be missing something. "openssl x509", "keyctl show > > %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump" > > all display the skid in hex. Why would anyone provide the skid as > > something other than in hex? > > Ah, I thought you want '0x' prefix mandatory. Will not remove base 16 > then. Also, /proc/keys shows keyid without '0x' prefix. Why? One doesn't preclude the other. "keyid = strtoul(optarg, &eptr, 16);" recognizes an "0x" prefixed string as being ascii-hex. Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file 2021-05-11 11:56 [PATCH v6 0/3] ima-evm-utils: Add --keyid option Vitaly Chikunov 2021-05-11 11:56 ` [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing Vitaly Chikunov @ 2021-05-11 11:56 ` Vitaly Chikunov 2021-06-25 12:22 ` Mimi Zohar 2021-05-11 11:56 ` [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file Vitaly Chikunov 2 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-05-11 11:56 UTC (permalink / raw) To: Mimi Zohar, Dmitry Kasatkin, linux-integrity Allow user to specify `--keyid @/path/to/cert.pem' to extract keyid from SKID of the certificate file. PEM or DER format is auto-detected. `--keyid' option is reused instead of adding a new option (like possible `--cert') to signify to the user it's only keyid extraction and nothing more. This commit creates ABI change for libimaevm, due to adding new function ima_read_keyid(). Newer clients cannot work with older libimaevm. Together with previous commit it creates backward-incompatible ABI change, thus soname should be incremented on release. Signed-off-by: Vitaly Chikunov <vt@altlinux.org> --- README | 1 + src/evmctl.c | 22 ++++++++++--- src/imaevm.h | 1 + src/libimaevm.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++ tests/sign_verify.test | 1 + 5 files changed, 109 insertions(+), 5 deletions(-) diff --git a/README b/README index 8cd66e0..0e1f6ba 100644 --- a/README +++ b/README @@ -49,6 +49,7 @@ OPTIONS --rsa use RSA key type and signing scheme v1 -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem) --keyid val overwrite signature keyid with a value (for signing) + val is a x509 cert file if prefixed with '@' -o, --portable generate portable EVM signatures -p, --pass password for encrypted signing key -r, --recursive recurse into directories (sign) diff --git a/src/evmctl.c b/src/evmctl.c index d853d34..9d2bdc3 100644 --- a/src/evmctl.c +++ b/src/evmctl.c @@ -42,6 +42,7 @@ #include <sys/param.h> #include <sys/stat.h> #include <sys/ioctl.h> +#include <arpa/inet.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> @@ -57,12 +58,14 @@ #include <termios.h> #include <assert.h> +#include <openssl/asn1.h> #include <openssl/sha.h> #include <openssl/pem.h> #include <openssl/hmac.h> #include <openssl/err.h> #include <openssl/rsa.h> #include <openssl/engine.h> +#include <openssl/x509v3.h> #include "hash_info.h" #include "pcr.h" #include "utils.h" @@ -2515,6 +2518,7 @@ static void usage(void) " --rsa use RSA key type and signing scheme v1\n" " -k, --key path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n" " --keyid val overwrite signature keyid with a value (for signing)\n" + " val is a x509 cert file if prefixed with '@'\n" " -o, --portable generate portable EVM signatures\n" " -p, --pass password for encrypted signing key\n" " -r, --recursive recurse into directories (sign)\n" @@ -2641,7 +2645,6 @@ int main(int argc, char *argv[]) int err = 0, c, lind; ENGINE *eng = NULL; unsigned long keyid; - char *eptr; #if !(OPENSSL_VERSION_NUMBER < 0x10100000) OPENSSL_init_crypto( @@ -2790,10 +2793,19 @@ int main(int argc, char *argv[]) verify_bank = optarg; break; case 144: - errno = 0; - keyid = strtoul(optarg, &eptr, 16); - if (errno || eptr - optarg != strlen(optarg) || - keyid == ULONG_MAX || keyid > UINT_MAX || + if (optarg[0] == '@') { + keyid = imaevm_read_keyid(optarg + 1); + } else { + char *eptr; + + errno = 0; + keyid = strtoul(optarg, &eptr, 16); + if (eptr - optarg != strlen(optarg) || errno) { + log_err("Invalid keyid value.\n"); + exit(1); + } + } + if (keyid == ULONG_MAX || keyid > UINT_MAX || keyid == 0) { log_err("Invalid keyid value.\n"); exit(1); diff --git a/src/imaevm.h b/src/imaevm.h index 9f38059..f427e8e 100644 --- a/src/imaevm.h +++ b/src/imaevm.h @@ -219,6 +219,7 @@ EVP_PKEY *read_pub_pkey(const char *keyfile, int x509); void calc_keyid_v1(uint8_t *keyid, char *str, const unsigned char *pkey, int len); void calc_keyid_v2(uint32_t *keyid, char *str, EVP_PKEY *pkey); int key2bin(RSA *key, unsigned char *pub); +uint32_t imaevm_read_keyid(const char *certfile); int sign_hash(const char *algo, const unsigned char *hash, int size, const char *keyfile, const char *keypass, unsigned char *sig); int verify_hash(const char *file, const unsigned char *hash, int size, unsigned char *sig, int siglen); diff --git a/src/libimaevm.c b/src/libimaevm.c index 481d29d..1c03768 100644 --- a/src/libimaevm.c +++ b/src/libimaevm.c @@ -57,6 +57,7 @@ #include <openssl/pem.h> #include <openssl/evp.h> #include <openssl/x509.h> +#include <openssl/x509v3.h> #include <openssl/err.h> #include "imaevm.h" @@ -748,6 +749,94 @@ void calc_keyid_v2(uint32_t *keyid, char *str, EVP_PKEY *pkey) X509_PUBKEY_free(pk); } +enum keyid_file_type { + KEYID_FILE_PEM_KEY = 0, + KEYID_FILE_UNK_CERT, +}; + +/* + * @keyid: Pointer to 32-bit value in network order, can be unaligned. + * @file_type: KEYID_FILE_PEM_KEY - PEM encoded private key file with possible + * appended x509 cert; + * KEYID_FILE_UNK_CERT - x509 cert file (maybe PEM, maybe DER + * encoded). + * Return: 0 on success. + */ +static int __read_keyid(uint32_t *keyid, const char *certfile, + enum keyid_file_type file_type) +{ + uint32_t keyid_raw; + const ASN1_OCTET_STRING *skid; + int skid_len; + X509 *x = NULL; + FILE *fp; + + if (!(fp = fopen(certfile, "r"))) { + log_err("read keyid: %s: Cannot open: %s\n", certfile, + strerror(errno)); + return -1; + } + if (!PEM_read_X509(fp, &x, NULL, NULL)) { + if (ERR_GET_REASON(ERR_peek_last_error()) == PEM_R_NO_START_LINE) { + ERR_clear_error(); + if (file_type == KEYID_FILE_PEM_KEY) { + log_debug("%s: x509 certificate not found\n", + certfile); + fclose(fp); + return -1; + } + rewind(fp); + d2i_X509_fp(fp, &x); + } + if (!x) { + ERR_print_errors_fp(stderr); + log_err("read keyid: %s: Error reading x509 certificate\n", + certfile); + fclose(fp); + return -1; + } + } + fclose(fp); + + if (!(skid = X509_get0_subject_key_id(x))) { + log_err("read keyid: %s: SKID not found\n", certfile); + goto err_free; + } + skid_len = ASN1_STRING_length(skid); + if (skid_len < sizeof(keyid_raw)) { + log_err("read keyid: %s: SKID too short (len %d)\n", certfile, + skid_len); + goto err_free; + } + memcpy(&keyid_raw, ASN1_STRING_get0_data(skid) + skid_len + - sizeof(keyid_raw), sizeof(keyid_raw)); + log_info("keyid %04x (from %s)\n", ntohl(keyid_raw), certfile); + memcpy(keyid, &keyid_raw, sizeof(*keyid)); + return 0; + +err_free: + X509_free(x); + return -1; +} + +/** + * imaevm_read_keyid() - Read 32-bit keyid from the cert file. + * @certfile: File possibly containing certificate in DER/PEM format. + * + * Try to read keyid from Subject Key Identifier (SKID) of certificate. + * Autodetect if cert is in PEM or DER encoding. + * + * Return: 0 on error; + * 32-bit keyid as unsigned integer in host order. + */ +uint32_t imaevm_read_keyid(const char *certfile) +{ + uint32_t keyid_raw = 0; + + __read_keyid(&keyid_raw, certfile, KEYID_FILE_UNK_CERT); + return ntohl(keyid_raw); +} + static EVP_PKEY *read_priv_pkey(const char *keyfile, const char *keypass) { FILE *fp; diff --git a/tests/sign_verify.test b/tests/sign_verify.test index eccf5fa..7f6d421 100755 --- a/tests/sign_verify.test +++ b/tests/sign_verify.test @@ -366,6 +366,7 @@ sign_verify rsa1024 md5 0x030201:K:0080 sign_verify rsa1024 sha1 0x030202:K:0080 sign_verify rsa1024 sha224 0x030207:K:0080 expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd +expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204:K:0080 OPTS=--keyid=@test-rsa1024.cer sign_verify rsa1024 sha256 0x030204:K:0080 try_different_keys try_different_sigs -- 2.11.0 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file 2021-05-11 11:56 ` [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file Vitaly Chikunov @ 2021-06-25 12:22 ` Mimi Zohar 2021-06-26 0:27 ` Vitaly Chikunov 0 siblings, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-25 12:22 UTC (permalink / raw) To: Vitaly Chikunov, Mimi Zohar, Dmitry Kasatkin, linux-integrity On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > +/** > + * imaevm_read_keyid() - Read 32-bit keyid from the cert file. > + * @certfile: File possibly containing certificate in DER/PEM format. > + * > + * Try to read keyid from Subject Key Identifier (SKID) of certificate. > + * Autodetect if cert is in PEM or DER encoding. > + * > + * Return: 0 on error; > + * 32-bit keyid as unsigned integer in host order. > + */ > +uint32_t imaevm_read_keyid(const char *certfile) > +{ > + uint32_t keyid_raw = 0; > + > + __read_keyid(&keyid_raw, certfile, KEYID_FILE_UNK_CERT); > + return ntohl(keyid_raw); On error, __read_keyid() returns < 0, but the return value isn't checked before calling ntohl. In either case, is imaevm_params.keyid suppose to be big endian byte order? If so, the call to htonl in sign_hash_v2() would be unnecessary. thanks, Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file 2021-06-25 12:22 ` Mimi Zohar @ 2021-06-26 0:27 ` Vitaly Chikunov 2021-06-30 16:39 ` Mimi Zohar 0 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-26 0:27 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity On Fri, Jun 25, 2021 at 08:22:06AM -0400, Mimi Zohar wrote: > On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > > > +/** > > + * imaevm_read_keyid() - Read 32-bit keyid from the cert file. > > + * @certfile: File possibly containing certificate in DER/PEM format. > > + * > > + * Try to read keyid from Subject Key Identifier (SKID) of certificate. > > + * Autodetect if cert is in PEM or DER encoding. > > + * > > + * Return: 0 on error; > > + * 32-bit keyid as unsigned integer in host order. > > + */ > > +uint32_t imaevm_read_keyid(const char *certfile) > > +{ > > + uint32_t keyid_raw = 0; > > + > > + __read_keyid(&keyid_raw, certfile, KEYID_FILE_UNK_CERT); > > + return ntohl(keyid_raw); > > On error, __read_keyid() returns < 0, but the return value isn't > checked before calling ntohl. It does not need to be checked, because it also does not change value pointed by `&keyid_raw' (which is 0 by default). Yes, this is not mentioned in the `__read_keyid' description. But, otherwise (to change pointed value on error) would be a bug. > In either case, is imaevm_params.keyid > suppose to be big endian byte order? No, it's in native order. This looked reasonable, since it could be presented to the user as a hex number. Thanks, > If so, the call to htonl in > sign_hash_v2() would be unnecessary. > > thanks, > > Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file 2021-06-26 0:27 ` Vitaly Chikunov @ 2021-06-30 16:39 ` Mimi Zohar 0 siblings, 0 replies; 21+ messages in thread From: Mimi Zohar @ 2021-06-30 16:39 UTC (permalink / raw) To: Vitaly Chikunov; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity Hi Vitaly, On Sat, 2021-06-26 at 03:27 +0300, Vitaly Chikunov wrote: > > In either case, is imaevm_params.keyid > > suppose to be big endian byte order? > > No, it's in native order. This looked reasonable, since it could be > presented to the user as a hex number. My confusion must have come from the __read_keyid() comment. + * @keyid: Pointer to 32-bit value in network order, can be unaligned. Please annotate the comment and the imaevm_params.keyid appropriately. thanks, Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file 2021-05-11 11:56 [PATCH v6 0/3] ima-evm-utils: Add --keyid option Vitaly Chikunov 2021-05-11 11:56 ` [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing Vitaly Chikunov 2021-05-11 11:56 ` [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file Vitaly Chikunov @ 2021-05-11 11:56 ` Vitaly Chikunov 2021-06-25 12:22 ` Mimi Zohar 2021-06-30 17:38 ` Mimi Zohar 2 siblings, 2 replies; 21+ messages in thread From: Vitaly Chikunov @ 2021-05-11 11:56 UTC (permalink / raw) To: Mimi Zohar, Dmitry Kasatkin, linux-integrity Allow to have certificate appended to the private key of `--key' specified (PEM) file (for v2 signing) to facilitate reading of keyid from the associated cert. This will allow users to have private and public key as a single file. There is no check that public key form the cert matches associated private key. Signed-off-by: Vitaly Chikunov <vt@altlinux.org> --- README | 3 +++ src/libimaevm.c | 8 +++++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/README b/README index 0e1f6ba..ea11bde 100644 --- a/README +++ b/README @@ -127,6 +127,9 @@ for signing and importing the key. Second key format uses X509 DER encoded public key certificates and uses asymmetric key support in the kernel (since kernel 3.9). CONFIG_INTEGRITY_ASYMMETRIC_KEYS must be enabled (default). +For v2 signatures x509 certificate with the public key could be appended to the private +key (both are in PEM format) to properly determine its Subject Key Identifier (SKID). + Integrity keyrings ---------------- diff --git a/src/libimaevm.c b/src/libimaevm.c index 1c03768..bfce7ef 100644 --- a/src/libimaevm.c +++ b/src/libimaevm.c @@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, return -1; } - if (imaevm_params.keyid) + if (imaevm_params.keyid) { hdr->keyid = htonl(imaevm_params.keyid); - else - calc_keyid_v2(&hdr->keyid, name, pkey); + } else { + if (__read_keyid(&hdr->keyid, keyfile, KEYID_FILE_PEM_KEY)) + calc_keyid_v2(&hdr->keyid, name, pkey); + } st = "EVP_PKEY_CTX_new"; if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) -- 2.11.0 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file 2021-05-11 11:56 ` [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file Vitaly Chikunov @ 2021-06-25 12:22 ` Mimi Zohar 2021-06-26 0:21 ` Vitaly Chikunov 2021-06-30 17:38 ` Mimi Zohar 1 sibling, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-25 12:22 UTC (permalink / raw) To: Vitaly Chikunov, Mimi Zohar, Dmitry Kasatkin, linux-integrity On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > Allow to have certificate appended to the private key of `--key' > specified (PEM) file (for v2 signing) to facilitate reading of keyid > from the associated cert. This will allow users to have private and > public key as a single file. There is no check that public key form the > cert matches associated private key. Is this a standard formats for storing the public and private key in the same file? Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file 2021-06-25 12:22 ` Mimi Zohar @ 2021-06-26 0:21 ` Vitaly Chikunov 0 siblings, 0 replies; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-26 0:21 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity Mimi, On Fri, Jun 25, 2021 at 08:22:15AM -0400, Mimi Zohar wrote: > On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > Allow to have certificate appended to the private key of `--key' > > specified (PEM) file (for v2 signing) to facilitate reading of keyid > > from the associated cert. This will allow users to have private and > > public key as a single file. There is no check that public key form the > > cert matches associated private key. > > Is this a standard formats for storing the public and private key in > the same file? I am not aware of any standard to keep ASCII armored text x509 cert together with the private key in the same file. But, it's common usage for some web servers, such as NGINX. People commonly suggest doing it in that context: https://stackoverflow.com/questions/991758/how-to-get-pem-file-from-key-and-crt-files "cat server.crt server.key > server.includesprivatekey.pem" "cat server.crt server.key > server.pem" Thanks, > > Mimi ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file 2021-05-11 11:56 ` [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file Vitaly Chikunov 2021-06-25 12:22 ` Mimi Zohar @ 2021-06-30 17:38 ` Mimi Zohar 2021-06-30 19:10 ` Vitaly Chikunov 1 sibling, 1 reply; 21+ messages in thread From: Mimi Zohar @ 2021-06-30 17:38 UTC (permalink / raw) To: Vitaly Chikunov, Mimi Zohar, Dmitry Kasatkin, linux-integrity Hi Vitaly, On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > diff --git a/src/libimaevm.c b/src/libimaevm.c > index 1c03768..bfce7ef 100644 > --- a/src/libimaevm.c > +++ b/src/libimaevm.c > @@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > return -1; > } > > - if (imaevm_params.keyid) > + if (imaevm_params.keyid) { > hdr->keyid = htonl(imaevm_params.keyid); > - else > - calc_keyid_v2(&hdr->keyid, name, pkey); > + } else { > + if (__read_keyid(&hdr->keyid, keyfile, KEYID_FILE_PEM_KEY)) > + calc_keyid_v2(&hdr->keyid, name, pkey); > + } If the call to __read_keyid() was independent of the test and call to calc_keyid_v2(), it would make reading code the easier to understand. result = __read_keyid(...); if (result < 0) calc_keyid_v2(...); thanks, Mimi > > st = "EVP_PKEY_CTX_new"; > if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file 2021-06-30 17:38 ` Mimi Zohar @ 2021-06-30 19:10 ` Vitaly Chikunov 2021-06-30 19:26 ` Vitaly Chikunov 0 siblings, 1 reply; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-30 19:10 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity Mimi, On Wed, Jun 30, 2021 at 01:38:02PM -0400, Mimi Zohar wrote: > On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > > > diff --git a/src/libimaevm.c b/src/libimaevm.c > > index 1c03768..bfce7ef 100644 > > --- a/src/libimaevm.c > > +++ b/src/libimaevm.c > > @@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > > return -1; > > } > > > > - if (imaevm_params.keyid) > > + if (imaevm_params.keyid) { > > hdr->keyid = htonl(imaevm_params.keyid); > > - else > > - calc_keyid_v2(&hdr->keyid, name, pkey); > > + } else { > > + if (__read_keyid(&hdr->keyid, keyfile, KEYID_FILE_PEM_KEY)) > > + calc_keyid_v2(&hdr->keyid, name, pkey); > > + } > > If the call to __read_keyid() was independent of the test and call to > calc_keyid_v2(), it would make reading code the easier to understand. > > result = __read_keyid(...); > if (result < 0) > calc_keyid_v2(...); No problem to add additional variable and check __read_keyid indirectly. But, how is this independent? Call to calc_keyid_v2 is dependent to __read_keyid result. Thanks, > > thanks, > > Mimi > > > > > st = "EVP_PKEY_CTX_new"; > > if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file 2021-06-30 19:10 ` Vitaly Chikunov @ 2021-06-30 19:26 ` Vitaly Chikunov 0 siblings, 0 replies; 21+ messages in thread From: Vitaly Chikunov @ 2021-06-30 19:26 UTC (permalink / raw) To: Mimi Zohar; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity Mimi, On Wed, Jun 30, 2021 at 10:10:55PM +0300, Vitaly Chikunov wrote: > On Wed, Jun 30, 2021 at 01:38:02PM -0400, Mimi Zohar wrote: > > On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote: > > > > > > diff --git a/src/libimaevm.c b/src/libimaevm.c > > > index 1c03768..bfce7ef 100644 > > > --- a/src/libimaevm.c > > > +++ b/src/libimaevm.c > > > @@ -1021,10 +1021,12 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash, > > > return -1; > > > } > > > > > > - if (imaevm_params.keyid) > > > + if (imaevm_params.keyid) { > > > hdr->keyid = htonl(imaevm_params.keyid); > > > - else > > > - calc_keyid_v2(&hdr->keyid, name, pkey); > > > + } else { > > > + if (__read_keyid(&hdr->keyid, keyfile, KEYID_FILE_PEM_KEY)) > > > + calc_keyid_v2(&hdr->keyid, name, pkey); > > > + } > > > > If the call to __read_keyid() was independent of the test and call to > > calc_keyid_v2(), it would make reading code the easier to understand. > > > > result = __read_keyid(...); > > if (result < 0) > > calc_keyid_v2(...); > > No problem to add additional variable and check __read_keyid indirectly. > But, how is this independent? Call to calc_keyid_v2 is dependent to > __read_keyid result. I think I understood what you meant. Thanks, > > Thanks, > > > > > thanks, > > > > Mimi > > > > > > > > st = "EVP_PKEY_CTX_new"; > > > if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL))) > > ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2021-06-30 21:32 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-11 11:56 [PATCH v6 0/3] ima-evm-utils: Add --keyid option Vitaly Chikunov 2021-05-11 11:56 ` [PATCH v6 1/3] ima-evm-utils: Allow manual setting keyid for signing Vitaly Chikunov 2021-06-25 12:21 ` Mimi Zohar 2021-06-26 0:42 ` Vitaly Chikunov 2021-06-28 20:50 ` Mimi Zohar 2021-06-29 1:32 ` Vitaly Chikunov 2021-06-30 16:39 ` Mimi Zohar 2021-06-30 19:44 ` Vitaly Chikunov 2021-06-30 20:47 ` Mimi Zohar 2021-06-30 21:10 ` Vitaly Chikunov 2021-06-30 21:32 ` Mimi Zohar 2021-05-11 11:56 ` [PATCH v6 2/3] ima-evm-utils: Allow manual setting keyid from a cert file Vitaly Chikunov 2021-06-25 12:22 ` Mimi Zohar 2021-06-26 0:27 ` Vitaly Chikunov 2021-06-30 16:39 ` Mimi Zohar 2021-05-11 11:56 ` [PATCH v6 3/3] ima-evm-utils: Read keyid from the cert appended to the key file Vitaly Chikunov 2021-06-25 12:22 ` Mimi Zohar 2021-06-26 0:21 ` Vitaly Chikunov 2021-06-30 17:38 ` Mimi Zohar 2021-06-30 19:10 ` Vitaly Chikunov 2021-06-30 19:26 ` Vitaly Chikunov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).