Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Jarkko Sakkinen]

On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
> During the test I discovered that not all access rights restrictions working
> correct. Examples:
> 
> Remove possessor write right:
> 
> $ KEYID=$(keyctl add user john smith @u)
> $ keyctl describe $KEYID
> 47831201: alswrv-----v------------  1000  1000 user: john
> $ keyctl print $KEYID
> smith
> $ keyctl update $KEYID dohn
> $ keyctl print $KEYID
> dohn
> $ keyctl setperm $KEYID 0x3b000000
> $ keyctl describe $KEYID
> 47831201: als-rv------------------  1000  1000 user: john
> $ keyctl update $KEYID dohn
> keyctl_update: Permission denied
> $ keyctl print $KEYID
> dohn
> 
> That OK. So, next
> Remove possessor set attributes right:
> 
> $ keyctl setperm $KEYID 0x1f000000
> $ keyctl describe $KEYID
> 47831201: -lswrv------------------  1000  1000 user: john
> $ keyctl setperm $KEYID 0x3f000000
> keyctl_update: Permission denied
> 
> That OK. So, next
> Remove possessor read right:
> 
> $ keyctl unlink $KEYID
> 1 links removed
> $ KEYID=$(keyctl add user john smith @u)
> $ keyctl describe $KEYID
> 5927639: alswrv-----v------------  1000  1000 user: john
> $ keyctl setperm $KEYID 0x3d000000
> $ keyctl describe $KEYID
> 5927639: alsw-v-----v------------  1000  1000 user: john
> $ keyctl print $KEYID
> smith
> 
> How's that? I removed the right to read, but the possessor continues
> to read it!
> 
> I opened the read function code and saw the following:
> 
> ```
>   /* see if we can read it directly */
>   ret = key_permission(key_ref, KEY_NEED_READ); /* OK, we returned error */
>                                                 /* read access */
>   if (ret = 0) /* skip that */
>     goto can_read_key;
>   if (ret != -EACCES) /* skip that */
>     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)) { /* If we possessor = can read */
>     ret = -EACCES;
>     goto key_put_out;
>   }
> 
>   /* the key is probably readable - now try to read it */
> can_read_key:
> ```
> Why can we read the key, if we don't have rights for doing this?
> 
> Alexey Krasikov (1):
>   security/keys: remove possessor verify after key permission check
> 
>  security/keys/keyctl.c | 15 +--------------
>  1 file changed, 1 insertion(+), 14 deletions(-)
> 
> -- 
> 2.17.1
> 

Thank you for the legit examples and effort in general. Looking into
this with time on Monday. Today I have to get unfortunately SGX patch
set out.

/Jarkko

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Jarkko Sakkinen]

On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
> $ KEYID=$(keyctl add user john smith @u)
> $ keyctl describe $KEYID
> 5927639: alswrv-----v------------  1000  1000 user: john
> $ keyctl setperm $KEYID 0x3d000000
> $ keyctl describe $KEYID
> 5927639: alsw-v-----v------------  1000  1000 user: john
> $ keyctl print $KEYID
> smith

A keyring default permissions are 0x3f3f0000.
A key default permissions are 0x3f010000.

Because of this:

$ KEYID=$(keyctl add user john smith @u)
$ keyctl setperm $KEYID 0x3d000000
keyctl_setperm: Permission denied

Are you sure that your example is correct?

/Jarkko

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Jarkko Sakkinen]

On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
> On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
> > On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
> > > $ KEYID=$(keyctl add user john smith @u)
> > > $ keyctl describe $KEYID
> > > 5927639: alswrv-----v------------  1000  1000 user: john
> > > $ keyctl setperm $KEYID 0x3d000000
> > > $ keyctl describe $KEYID
> > > 5927639: alsw-v-----v------------  1000  1000 user: john
> > > $ keyctl print $KEYID
> > > smith
> > A keyring default permissions are 0x3f3f0000.
> > A key default permissions are 0x3f010000.
> > 
> > Because of this:
> > 
> > $ KEYID=$(keyctl add user john smith @u)
> > $ keyctl setperm $KEYID 0x3d000000
> > keyctl_setperm: Permission denied
> > 
> > Are you sure that your example is correct?
> > 
> > /Jarkko
> 
> Yes, this example works correctly.
> 
> Why do you think, that the current keyring and key rights
> 
> shoukd not allow this to be done?

I'm just saying that I cannot figure out your point in the cover letter.
It contains random dumps of keyctl output.

Maybe a better idea would be to write a test script that demonstrates
the issue?

/Jarkko

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Greg KH]

On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
> On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
> > On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
> > > On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
> > > > On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
> > > > > $ KEYID=$(keyctl add user john smith @u)
> > > > > $ keyctl describe $KEYID
> > > > > 5927639: alswrv-----v------------  1000  1000 user: john
> > > > > $ keyctl setperm $KEYID 0x3d000000
> > > > > $ keyctl describe $KEYID
> > > > > 5927639: alsw-v-----v------------  1000  1000 user: john
> > > > > $ keyctl print $KEYID
> > > > > smith
> > > > A keyring default permissions are 0x3f3f0000.
> > > > A key default permissions are 0x3f010000.
> > > > 
> > > > Because of this:
> > > > 
> > > > $ KEYID=$(keyctl add user john smith @u)
> > > > $ keyctl setperm $KEYID 0x3d000000
> > > > keyctl_setperm: Permission denied
> > > > 
> > > > Are you sure that your example is correct?
> > > > 
> > > > /Jarkko
> > > Yes, this example works correctly.
> > > 
> > > Why do you think, that the current keyring and key rights
> > > 
> > > shoukd not allow this to be done?
> > I'm just saying that I cannot figure out your point in the cover letter.
> > It contains random dumps of keyctl output.
> > 
> > Maybe a better idea would be to write a test script that demonstrates
> > the issue?
> > 
> > /Jarkko
> 
> + alexey_krasikov@mail.ru
> 
> Possible you may not be able to reproduce the problem because you have a
> different version of Linux.
> 
> I get to reproduce the problem on two systems:
> 
> Linux 4.14.74-28+yc11.91
> 
> and
> 
> Linux ubuntu 4.15.0-106-generic

Both of those are distro-specific kernels, can you reproduce this on
5.8-rc2 or 5.7 as released from kernel.org?

thanks,

greg k-h

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Jarkko Sakkinen]

On Mon, Jun 22, 2020 at 02:30:28PM +0200, Greg KH wrote:
> On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
> > On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
> > > On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
> > > > On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
> > > > > On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
> > > > > > $ KEYID=$(keyctl add user john smith @u)
> > > > > > $ keyctl describe $KEYID
> > > > > > 5927639: alswrv-----v------------  1000  1000 user: john
> > > > > > $ keyctl setperm $KEYID 0x3d000000
> > > > > > $ keyctl describe $KEYID
> > > > > > 5927639: alsw-v-----v------------  1000  1000 user: john
> > > > > > $ keyctl print $KEYID
> > > > > > smith
> > > > > A keyring default permissions are 0x3f3f0000.
> > > > > A key default permissions are 0x3f010000.
> > > > > 
> > > > > Because of this:
> > > > > 
> > > > > $ KEYID=$(keyctl add user john smith @u)
> > > > > $ keyctl setperm $KEYID 0x3d000000
> > > > > keyctl_setperm: Permission denied
> > > > > 
> > > > > Are you sure that your example is correct?
> > > > > 
> > > > > /Jarkko
> > > > Yes, this example works correctly.
> > > > 
> > > > Why do you think, that the current keyring and key rights
> > > > 
> > > > shoukd not allow this to be done?
> > > I'm just saying that I cannot figure out your point in the cover letter.
> > > It contains random dumps of keyctl output.
> > > 
> > > Maybe a better idea would be to write a test script that demonstrates
> > > the issue?
> > > 
> > > /Jarkko
> > 
> > + alexey_krasikov@mail.ru
> > 
> > Possible you may not be able to reproduce the problem because you have a
> > different version of Linux.
> > 
> > I get to reproduce the problem on two systems:
> > 
> > Linux 4.14.74-28+yc11.91
> > 
> > and
> > 
> > Linux ubuntu 4.15.0-106-generic
> 
> Both of those are distro-specific kernels, can you reproduce this on
> 5.8-rc2 or 5.7 as released from kernel.org?

Alexey,

A shell script containing the keyctl command chain with some output, and
then your version of the output when running the script would be also
very useful for better comparison.

/Jarkko

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Alexey Krasikov]

On 6/23/20 4:28 AM, Jarkko Sakkinen wrote:
> On Mon, Jun 22, 2020 at 02:30:28PM +0200, Greg KH wrote:
>> On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
>>> On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
>>>> On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
>>>>> On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
>>>>>> On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>> $ keyctl describe $KEYID
>>>>>>> 5927639: alswrv-----v------------  1000  1000 user: john
>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>> $ keyctl describe $KEYID
>>>>>>> 5927639: alsw-v-----v------------  1000  1000 user: john
>>>>>>> $ keyctl print $KEYID
>>>>>>> smith
>>>>>> A keyring default permissions are 0x3f3f0000.
>>>>>> A key default permissions are 0x3f010000.
>>>>>>
>>>>>> Because of this:
>>>>>>
>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>> keyctl_setperm: Permission denied
>>>>>>
>>>>>> Are you sure that your example is correct?
>>>>>>
>>>>>> /Jarkko
>>>>> Yes, this example works correctly.
>>>>>
>>>>> Why do you think, that the current keyring and key rights
>>>>>
>>>>> shoukd not allow this to be done?
>>>> I'm just saying that I cannot figure out your point in the cover letter.
>>>> It contains random dumps of keyctl output.
>>>>
>>>> Maybe a better idea would be to write a test script that demonstrates
>>>> the issue?
>>>>
>>>> /Jarkko
>>> + alexey_krasikov@mail.ru
>>>
>>> Possible you may not be able to reproduce the problem because you have a
>>> different version of Linux.
>>>
>>> I get to reproduce the problem on two systems:
>>>
>>> Linux 4.14.74-28+yc11.91
>>>
>>> and
>>>
>>> Linux ubuntu 4.15.0-106-generic
>> Both of those are distro-specific kernels, can you reproduce this on
>> 5.8-rc2 or 5.7 as released from kernel.org?
> Alexey,
>
> A shell script containing the keyctl command chain with some output, and
> then your version of the output when running the script would be also
> very useful for better comparison.
>
> /Jarkko

Ok. I have the following script:

----------------------------------------------------------------------------
#!/usr/bin/sh

uname -r

KEYID=$(keyctl add user john smith @u)
keyctl describe $KEYID
keyctl setperm $KEYID 0x3d000000
keyctl describe $KEYID
keyctl print $KEYID
----------------------------------------------------------------------------

I installed the Manjaro distribution, updated the kernel to version 5.7.0-3,
and when running this script, I got the following output:

****************************************************************************
5.7.0-3-MANJARO
914983072: alswrv-----v------------  1000  1000 user: john
914983072: alsw-v------------------  1000  1000 user: john
smith
****************************************************************************

In fairness, I note that none of these distro-specific kernels
does not change the work logic of the Linux keyring.

/Alexey

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Jarkko Sakkinen]

On Sun, Jun 28, 2020 at 03:27:37AM +0300, Alexey Krasikov wrote:
> On 6/23/20 4:28 AM, Jarkko Sakkinen wrote:
> > On Mon, Jun 22, 2020 at 02:30:28PM +0200, Greg KH wrote:
> > > On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
> > > > On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
> > > > > On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
> > > > > > On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
> > > > > > > On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
> > > > > > > > $ KEYID=$(keyctl add user john smith @u)
> > > > > > > > $ keyctl describe $KEYID
> > > > > > > > 5927639: alswrv-----v------------  1000  1000 user: john
> > > > > > > > $ keyctl setperm $KEYID 0x3d000000
> > > > > > > > $ keyctl describe $KEYID
> > > > > > > > 5927639: alsw-v-----v------------  1000  1000 user: john
> > > > > > > > $ keyctl print $KEYID
> > > > > > > > smith
> > > > > > > A keyring default permissions are 0x3f3f0000.
> > > > > > > A key default permissions are 0x3f010000.
> > > > > > > 
> > > > > > > Because of this:
> > > > > > > 
> > > > > > > $ KEYID=$(keyctl add user john smith @u)
> > > > > > > $ keyctl setperm $KEYID 0x3d000000
> > > > > > > keyctl_setperm: Permission denied
> > > > > > > 
> > > > > > > Are you sure that your example is correct?
> > > > > > > 
> > > > > > > /Jarkko
> > > > > > Yes, this example works correctly.
> > > > > > 
> > > > > > Why do you think, that the current keyring and key rights
> > > > > > 
> > > > > > shoukd not allow this to be done?
> > > > > I'm just saying that I cannot figure out your point in the cover letter.
> > > > > It contains random dumps of keyctl output.
> > > > > 
> > > > > Maybe a better idea would be to write a test script that demonstrates
> > > > > the issue?
> > > > > 
> > > > > /Jarkko
> > > > + alexey_krasikov@mail.ru
> > > > 
> > > > Possible you may not be able to reproduce the problem because you have a
> > > > different version of Linux.
> > > > 
> > > > I get to reproduce the problem on two systems:
> > > > 
> > > > Linux 4.14.74-28+yc11.91
> > > > 
> > > > and
> > > > 
> > > > Linux ubuntu 4.15.0-106-generic
> > > Both of those are distro-specific kernels, can you reproduce this on
> > > 5.8-rc2 or 5.7 as released from kernel.org?
> > Alexey,
> > 
> > A shell script containing the keyctl command chain with some output, and
> > then your version of the output when running the script would be also
> > very useful for better comparison.
> > 
> > /Jarkko
> 
> Ok. I have the following script:
> 
> ----------------------------------------------------------------------------
> #!/usr/bin/sh
> 
> uname -r
> 
> KEYID=$(keyctl add user john smith @u)
> keyctl describe $KEYID
> keyctl setperm $KEYID 0x3d000000
> keyctl describe $KEYID
> keyctl print $KEYID

pam_keyinit.so should create user keyring when the login session is
created. If the user space stack is working correclty, you should not
end up to be the possessor for the user keyring.

However, I can simulate your environment with the session keyring:

KEYID=`keyctl add user john smith @s`

keyctl describe $KEYID
keyctl setperm $KEYID 0x3d000000
keyctl describe $KEYID
keyctl print $KEYID

And yes I do get:

564302411: alswrv-----v------------  1000  1000 user: john
564302411: alsw-v------------------  1000  1000 user: john
smith

Here's another sequence that also removes setattr:

KEYID=`keyctl add user john smith @s`

keyctl describe $KEYID
keyctl setperm $KEYID 0x08000000
keyctl describe $KEYID
keyctl print $KEYID

700153280: alswrv-----v------------  1000  1000 user: john
keyctl_describe_alloc: Permission denied
smith

David, this look at least with a quick sight somewhat weird: my
possessor permissions are only "search", so why does reading the
payload succeed?

/Jarkko

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Alexey Krasikov]

On 7/3/20 4:14 AM, Jarkko Sakkinen wrote:
> On Sun, Jun 28, 2020 at 03:27:37AM +0300, Alexey Krasikov wrote:
>> On 6/23/20 4:28 AM, Jarkko Sakkinen wrote:
>>> On Mon, Jun 22, 2020 at 02:30:28PM +0200, Greg KH wrote:
>>>> On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
>>>>> On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
>>>>>> On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
>>>>>>> On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
>>>>>>>> On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
>>>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>>>> $ keyctl describe $KEYID
>>>>>>>>> 5927639: alswrv-----v------------  1000  1000 user: john
>>>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>>>> $ keyctl describe $KEYID
>>>>>>>>> 5927639: alsw-v-----v------------  1000  1000 user: john
>>>>>>>>> $ keyctl print $KEYID
>>>>>>>>> smith
>>>>>>>> A keyring default permissions are 0x3f3f0000.
>>>>>>>> A key default permissions are 0x3f010000.
>>>>>>>>
>>>>>>>> Because of this:
>>>>>>>>
>>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>>> keyctl_setperm: Permission denied
>>>>>>>>
>>>>>>>> Are you sure that your example is correct?
>>>>>>>>
>>>>>>>> /Jarkko
>>>>>>> Yes, this example works correctly.
>>>>>>>
>>>>>>> Why do you think, that the current keyring and key rights
>>>>>>>
>>>>>>> shoukd not allow this to be done?
>>>>>> I'm just saying that I cannot figure out your point in the cover letter.
>>>>>> It contains random dumps of keyctl output.
>>>>>>
>>>>>> Maybe a better idea would be to write a test script that demonstrates
>>>>>> the issue?
>>>>>>
>>>>>> /Jarkko
>>>>> + alexey_krasikov@mail.ru
>>>>>
>>>>> Possible you may not be able to reproduce the problem because you have a
>>>>> different version of Linux.
>>>>>
>>>>> I get to reproduce the problem on two systems:
>>>>>
>>>>> Linux 4.14.74-28+yc11.91
>>>>>
>>>>> and
>>>>>
>>>>> Linux ubuntu 4.15.0-106-generic
>>>> Both of those are distro-specific kernels, can you reproduce this on
>>>> 5.8-rc2 or 5.7 as released from kernel.org?
>>> Alexey,
>>>
>>> A shell script containing the keyctl command chain with some output, and
>>> then your version of the output when running the script would be also
>>> very useful for better comparison.
>>>
>>> /Jarkko
>> Ok. I have the following script:
>>
>> ----------------------------------------------------------------------------
>> #!/usr/bin/sh
>>
>> uname -r
>>
>> KEYID=$(keyctl add user john smith @u)
>> keyctl describe $KEYID
>> keyctl setperm $KEYID 0x3d000000
>> keyctl describe $KEYID
>> keyctl print $KEYID
> pam_keyinit.so should create user keyring when the login session is
> created. If the user space stack is working correclty, you should not
> end up to be the possessor for the user keyring.
>
> However, I can simulate your environment with the session keyring:
>
> KEYID=`keyctl add user john smith @s`
>
> keyctl describe $KEYID
> keyctl setperm $KEYID 0x3d000000
> keyctl describe $KEYID
> keyctl print $KEYID
>
> And yes I do get:
>
> 564302411: alswrv-----v------------  1000  1000 user: john
> 564302411: alsw-v------------------  1000  1000 user: john
> smith
>
> Here's another sequence that also removes setattr:
>
> KEYID=`keyctl add user john smith @s`
>
> keyctl describe $KEYID
> keyctl setperm $KEYID 0x08000000
> keyctl describe $KEYID
> keyctl print $KEYID
>
> 700153280: alswrv-----v------------  1000  1000 user: john
> keyctl_describe_alloc: Permission denied
> smith
>
> David, this look at least with a quick sight somewhat weird: my
> possessor permissions are only "search", so why does reading the
> payload succeed?
>
> /Jarkko
ping

/Alexey

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Alexey Krasikov]

On 7/13/20 2:53 PM, Alexey Krasikov wrote:
> On 7/3/20 4:14 AM, Jarkko Sakkinen wrote:
>> On Sun, Jun 28, 2020 at 03:27:37AM +0300, Alexey Krasikov wrote:
>>> On 6/23/20 4:28 AM, Jarkko Sakkinen wrote:
>>>> On Mon, Jun 22, 2020 at 02:30:28PM +0200, Greg KH wrote:
>>>>> On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
>>>>>> On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
>>>>>>> On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
>>>>>>>> On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
>>>>>>>>> On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
>>>>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>>>>> $ keyctl describe $KEYID
>>>>>>>>>> 5927639: alswrv-----v------------  1000  1000 user: john
>>>>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>>>>> $ keyctl describe $KEYID
>>>>>>>>>> 5927639: alsw-v-----v------------  1000  1000 user: john
>>>>>>>>>> $ keyctl print $KEYID
>>>>>>>>>> smith
>>>>>>>>> A keyring default permissions are 0x3f3f0000.
>>>>>>>>> A key default permissions are 0x3f010000.
>>>>>>>>>
>>>>>>>>> Because of this:
>>>>>>>>>
>>>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>>>> keyctl_setperm: Permission denied
>>>>>>>>>
>>>>>>>>> Are you sure that your example is correct?
>>>>>>>>>
>>>>>>>>> /Jarkko
>>>>>>>> Yes, this example works correctly.
>>>>>>>>
>>>>>>>> Why do you think, that the current keyring and key rights
>>>>>>>>
>>>>>>>> shoukd not allow this to be done?
>>>>>>> I'm just saying that I cannot figure out your point in the cover 
>>>>>>> letter.
>>>>>>> It contains random dumps of keyctl output.
>>>>>>>
>>>>>>> Maybe a better idea would be to write a test script that 
>>>>>>> demonstrates
>>>>>>> the issue?
>>>>>>>
>>>>>>> /Jarkko
>>>>>> + alexey_krasikov@mail.ru
>>>>>>
>>>>>> Possible you may not be able to reproduce the problem because you 
>>>>>> have a
>>>>>> different version of Linux.
>>>>>>
>>>>>> I get to reproduce the problem on two systems:
>>>>>>
>>>>>> Linux 4.14.74-28+yc11.91
>>>>>>
>>>>>> and
>>>>>>
>>>>>> Linux ubuntu 4.15.0-106-generic
>>>>> Both of those are distro-specific kernels, can you reproduce this on
>>>>> 5.8-rc2 or 5.7 as released from kernel.org?
>>>> Alexey,
>>>>
>>>> A shell script containing the keyctl command chain with some 
>>>> output, and
>>>> then your version of the output when running the script would be also
>>>> very useful for better comparison.
>>>>
>>>> /Jarkko
>>> Ok. I have the following script:
>>>
>>> ---------------------------------------------------------------------------- 
>>>
>>> #!/usr/bin/sh
>>>
>>> uname -r
>>>
>>> KEYID=$(keyctl add user john smith @u)
>>> keyctl describe $KEYID
>>> keyctl setperm $KEYID 0x3d000000
>>> keyctl describe $KEYID
>>> keyctl print $KEYID
>> pam_keyinit.so should create user keyring when the login session is
>> created. If the user space stack is working correclty, you should not
>> end up to be the possessor for the user keyring.
>>
>> However, I can simulate your environment with the session keyring:
>>
>> KEYID=`keyctl add user john smith @s`
>>
>> keyctl describe $KEYID
>> keyctl setperm $KEYID 0x3d000000
>> keyctl describe $KEYID
>> keyctl print $KEYID
>>
>> And yes I do get:
>>
>> 564302411: alswrv-----v------------  1000  1000 user: john
>> 564302411: alsw-v------------------  1000  1000 user: john
>> smith
>>
>> Here's another sequence that also removes setattr:
>>
>> KEYID=`keyctl add user john smith @s`
>>
>> keyctl describe $KEYID
>> keyctl setperm $KEYID 0x08000000
>> keyctl describe $KEYID
>> keyctl print $KEYID
>>
>> 700153280: alswrv-----v------------  1000  1000 user: john
>> keyctl_describe_alloc: Permission denied
>> smith
>>
>> David, this look at least with a quick sight somewhat weird: my
>> possessor permissions are only "search", so why does reading the
>> payload succeed?
>>
>> /Jarkko
> ping
>
> /Alexey
ping, ping!!!

Hello everybody!

David, have you watched my correspondence with Jarkko?
Do you have any ideas about this strange behavior of keyctl?

/Alexey

Re: [RFC PATCH 0/1] security/keys: remove possessor verify after key

[Alexey Krasikov]

On 7/3/20 4:14 AM, Jarkko Sakkinen wrote:
> On Sun, Jun 28, 2020 at 03:27:37AM +0300, Alexey Krasikov wrote:
>> On 6/23/20 4:28 AM, Jarkko Sakkinen wrote:
>>> On Mon, Jun 22, 2020 at 02:30:28PM +0200, Greg KH wrote:
>>>> On Mon, Jun 22, 2020 at 12:04:29PM +0300, Alexey Krasikov wrote:
>>>>> On 6/15/20 8:00 PM, Jarkko Sakkinen wrote:
>>>>>> On Tue, Jun 02, 2020 at 01:30:52PM +0300, Alexey Krasikov wrote:
>>>>>>> On Mon, June 1, 2020 at 08:34PM +300, Jarkko Sakkinen wrote:
>>>>>>>> On Fri, May 29, 2020 at 09:00:39AM +0300, Alexey Krasikov wrote:
>>>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>>>> $ keyctl describe $KEYID
>>>>>>>>> 5927639: alswrv-----v------------  1000  1000 user: john
>>>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>>>> $ keyctl describe $KEYID
>>>>>>>>> 5927639: alsw-v-----v------------  1000  1000 user: john
>>>>>>>>> $ keyctl print $KEYID
>>>>>>>>> smith
>>>>>>>> A keyring default permissions are 0x3f3f0000.
>>>>>>>> A key default permissions are 0x3f010000.
>>>>>>>>
>>>>>>>> Because of this:
>>>>>>>>
>>>>>>>> $ KEYID=$(keyctl add user john smith @u)
>>>>>>>> $ keyctl setperm $KEYID 0x3d000000
>>>>>>>> keyctl_setperm: Permission denied
>>>>>>>>
>>>>>>>> Are you sure that your example is correct?
>>>>>>>>
>>>>>>>> /Jarkko
>>>>>>> Yes, this example works correctly.
>>>>>>>
>>>>>>> Why do you think, that the current keyring and key rights
>>>>>>>
>>>>>>> shoukd not allow this to be done?
>>>>>> I'm just saying that I cannot figure out your point in the cover letter.
>>>>>> It contains random dumps of keyctl output.
>>>>>>
>>>>>> Maybe a better idea would be to write a test script that demonstrates
>>>>>> the issue?
>>>>>>
>>>>>> /Jarkko
>>>>> + alexey_krasikov@mail.ru
>>>>>
>>>>> Possible you may not be able to reproduce the problem because you have a
>>>>> different version of Linux.
>>>>>
>>>>> I get to reproduce the problem on two systems:
>>>>>
>>>>> Linux 4.14.74-28+yc11.91
>>>>>
>>>>> and
>>>>>
>>>>> Linux ubuntu 4.15.0-106-generic
>>>> Both of those are distro-specific kernels, can you reproduce this on
>>>> 5.8-rc2 or 5.7 as released from kernel.org?
>>> Alexey,
>>>
>>> A shell script containing the keyctl command chain with some output, and
>>> then your version of the output when running the script would be also
>>> very useful for better comparison.
>>>
>>> /Jarkko
>> Ok. I have the following script:
>>
>> ----------------------------------------------------------------------------
>> #!/usr/bin/sh
>>
>> uname -r
>>
>> KEYID=$(keyctl add user john smith @u)
>> keyctl describe $KEYID
>> keyctl setperm $KEYID 0x3d000000
>> keyctl describe $KEYID
>> keyctl print $KEYID
> pam_keyinit.so should create user keyring when the login session is
> created. If the user space stack is working correclty, you should not
> end up to be the possessor for the user keyring.
>
> However, I can simulate your environment with the session keyring:
>
> KEYID=`keyctl add user john smith @s`
>
> keyctl describe $KEYID
> keyctl setperm $KEYID 0x3d000000
> keyctl describe $KEYID
> keyctl print $KEYID
>
> And yes I do get:
>
> 564302411: alswrv-----v------------  1000  1000 user: john
> 564302411: alsw-v------------------  1000  1000 user: john
> smith
>
> Here's another sequence that also removes setattr:
>
> KEYID=`keyctl add user john smith @s`
>
> keyctl describe $KEYID
> keyctl setperm $KEYID 0x08000000
> keyctl describe $KEYID
> keyctl print $KEYID
>
> 700153280: alswrv-----v------------  1000  1000 user: john
> keyctl_describe_alloc: Permission denied
> smith
>
> David, this look at least with a quick sight somewhat weird: my
> possessor permissions are only "search", so why does reading the
> payload succeed?
>
> /Jarkko
ping

-- 
With best regards,
Alexey Krasikov,
+7-999-789-0-789