| Message ID | 20210322095726.14939-1-arbn@yandex-team.ru (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | keys: Allow disabling read permissions for key possessor | expand |
On Mon, Mar 22, 2021 at 12:57:26PM +0300, Andrey Ryabinin wrote: > keyctl_read_key() has a strange code which allows possessor to read > key's payload regardless of READ permission status: > > $ keyctl add user test test @u > 196773443 > $ keyctl print 196773443 > test > $ keyctl describe 196773443 > 196773443: alswrv-----v------------ 1000 1000 user: test > $ keyctl rdescribe 196773443 > user;1000;1000;3f010000;test > $ keyctl setperm 196773443 0x3d010000 > $ keyctl describe 196773443 > 196773443: alsw-v-----v------------ 1000 1000 user: test > $ keyctl print 196773443 > test > > The last keyctl print should fail with -EACCESS instead of success. > Fix this by removing weird possessor checks. > > Signed-off-by: Andrey Ryabinin <arbn@yandex-team.ru> > --- > > - This was noticed by code review. It seems like a bug to me, > but if I'm wrong and current behavior is correct, I think we need > at least better comment here. > > > security/keys/keyctl.c | 15 +-------------- > 1 file changed, 1 insertion(+), 14 deletions(-) > > diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c > index 96a92a645216d..2ec021c7adc12 100644 > --- a/security/keys/keyctl.c > +++ b/security/keys/keyctl.c > @@ -845,22 +845,9 @@ long keyctl_read_key(key_serial_t keyid, char __user *buffer, size_t buflen) > > /* see if we can read it directly */ > ret = key_permission(key_ref, KEY_NEED_READ); > - if (ret == 0) > - goto can_read_key; > - if (ret != -EACCES) > + if (ret != 0) > goto key_put_out; > > - /* we can't; see if it's searchable from this process's keyrings > - * - we automatically take account of the fact that it may be > - * dangling off an instantiation key > - */ > - if (!is_key_possessed(key_ref)) { > - ret = -EACCES; > - goto key_put_out; > - } > - This might be intentional, given the comment above the function: * The key must either grant the caller Read permission, or it must grant the * caller Search permission when searched for from the process keyrings. The 'is_key_possessed()' check is implementing the second part, right? Maybe check if this shows up in the documentation and tests too. - Eric
On Mon, Mar 22, 2021 at 12:57:26PM +0300, Andrey Ryabinin wrote: > keyctl_read_key() has a strange code which allows possessor to read > key's payload regardless of READ permission status: > > $ keyctl add user test test @u > 196773443 > $ keyctl print 196773443 > test > $ keyctl describe 196773443 > 196773443: alswrv-----v------------ 1000 1000 user: test > $ keyctl rdescribe 196773443 > user;1000;1000;3f010000;test > $ keyctl setperm 196773443 0x3d010000 > $ keyctl describe 196773443 > 196773443: alsw-v-----v------------ 1000 1000 user: test > $ keyctl print 196773443 > test > > The last keyctl print should fail with -EACCESS instead of success. > Fix this by removing weird possessor checks. > > Signed-off-by: Andrey Ryabinin <arbn@yandex-team.ru> I wrote a new test. If you include a test into a commit please describe it so that it can be easily executed. Otherwise, it is somewhat useless. Anyway, https://gist.github.com/jarkk0sakkinen/7b417be20cb52ed971a90561192f0883 David, why all of these end up allowing to still print the payload? /Jarkko
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c index 96a92a645216d..2ec021c7adc12 100644 --- a/security/keys/keyctl.c +++ b/security/keys/keyctl.c @@ -845,22 +845,9 @@ long keyctl_read_key(key_serial_t keyid, char __user *buffer, size_t buflen) /* see if we can read it directly */ ret = key_permission(key_ref, KEY_NEED_READ); - if (ret == 0) - goto can_read_key; - if (ret != -EACCES) + if (ret != 0) goto key_put_out; - /* we can't; see if it's searchable from this process's keyrings - * - we automatically take account of the fact that it may be - * dangling off an instantiation key - */ - if (!is_key_possessed(key_ref)) { - ret = -EACCES; - goto key_put_out; - } - - /* the key is probably readable - now try to read it */ -can_read_key: if (!key->type->read) { ret = -EOPNOTSUPP; goto key_put_out;
keyctl_read_key() has a strange code which allows possessor to read key's payload regardless of READ permission status: $ keyctl add user test test @u 196773443 $ keyctl print 196773443 test $ keyctl describe 196773443 196773443: alswrv-----v------------ 1000 1000 user: test $ keyctl rdescribe 196773443 user;1000;1000;3f010000;test $ keyctl setperm 196773443 0x3d010000 $ keyctl describe 196773443 196773443: alsw-v-----v------------ 1000 1000 user: test $ keyctl print 196773443 test The last keyctl print should fail with -EACCESS instead of success. Fix this by removing weird possessor checks. Signed-off-by: Andrey Ryabinin <arbn@yandex-team.ru> --- - This was noticed by code review. It seems like a bug to me, but if I'm wrong and current behavior is correct, I think we need at least better comment here. security/keys/keyctl.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-)