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 <redacted>
---
- 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(-)
@@ -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)-gotocan_read_key;-if(ret!=-EACCES)+if(ret!=0)gotokey_put_out;-/* we can't; see if it's searchable from this process's keyrings-*-weautomaticallytakeaccountofthefactthatitmaybe-*danglingoffaninstantiationkey-*/-if(!is_key_possessed(key_ref)){-ret=-EACCES;-gotokey_put_out;-}--/* the key is probably readable - now try to read it */-can_read_key:if(!key->type->read){ret=-EOPNOTSUPP;gotokey_put_out;
From: Eric Biggers <ebiggers@kernel.org> Date: 2021-03-23 00:56:09
On Mon, Mar 22, 2021 at 12:57:26PM +0300, Andrey Ryabinin wrote:
quoted hunk
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 <redacted>
---
- 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(-)
@@ -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)-gotocan_read_key;-if(ret!=-EACCES)+if(ret!=0)gotokey_put_out;-/* we can't; see if it's searchable from this process's keyrings-*-weautomaticallytakeaccountofthefactthatitmaybe-*danglingoffaninstantiationkey-*/-if(!is_key_possessed(key_ref)){-ret=-EACCES;-gotokey_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
From: Jarkko Sakkinen <jarkko@kernel.org> Date: 2021-03-23 02:03:32
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 <redacted>
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