linux-ext4 - Re: [RFC] keyctl {clear,revoke} serialization with key-users

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 18 Jun 2015 13:43:11 +0300
From:	Dmitry Monakhov <dmonakhov@...nvz.org>
To:	David Howells <dhowells@...hat.com>
Cc:	dhowells@...hat.com, keyrings@...ux-nfs.org,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] keyctl {clear,revoke} serialization with key-users

David Howells <dhowells@...hat.com> writes:

> Dmitry Monakhov <dmonakhov@...nvz.org> wrote:
>
>> But currently there is not synchronization between 'keyctl clear' and dirty
>> page buffers write-back, which result in data loss(because key no longer
>> available).
>
> The way fs/afs/ deals with this is to attach the key to the pending writeback
> record.  However, this would also benefit from writeback being triggered at
> key invalidation.
>
>> But currently there is not synchronization between 'keyctl clear' and dirty
>> page buffers write-back, which result in data loss(because key no longer
>> available).
>>
>> There are several ways to synchronize key-management with key-usage
>> 1) ext4 specific way via userspace
>>    add 'del_key' command to e4crypto which will do:
>>        ioctl(ext4_del_key)          # sync and invalidate all inodes which referees given key
>>        keyctl(KEYCTL_INVALIDATE,..) # wipe key from kernel
>
> I'm not keen on this because it's too easy to bypass half the process and miss
> the ioctl.
>
>> 2) Generic keyring way:
>>    Add kernel API to register event listeners for a key so any subsystem
>>    may listen for such events and performs necessary actions once it happen.
>>    For example:
>>    key = request_key(....)
>>    notify_changes_key(key, event_mask, my_callback)
>> 
>> 
>>    keyring_clear() {
>>    for_each_listener{
>>         notify_key(callback, KEY_CLEAR)
>>    }
>>    
>> First one is easy and clean also it preserves original keyring management
>> assumptions, but second one is more generic (since other fs will likely to
>> implement encryption in near future), the only visible changes of second
>> option is that callbacks must be synchronous so 'keyctl clear @s' may takes
>> long time. IMHO such implicit synchronization is good for 99% use-cases, the
>> only exception is 'emergency key clear' case where we do not care about data
>> consistency but do care about key to be wiped ASAP.
>> 
>> I would like to implement second option. Please rise your objections if any.
>
> I agree that the second is the best option.  It's something I thought about
> originally for keys that are tied to some sort of removable hardware but I
> never actually implemented.
>
> I would suggest that you consider driving the notification from the
> gc.
AFAIU it is too late to perform notifications from GS because key is
already tagged as INVALIDATED or DEAD so key_validate() will fail.

BTW: I try to find synchronous way to clear a key the one which
explicitly wait for scheduled gc work to complete. But I can not find it.
Please guide me.
>It might not be entirely practical though and might be better off done from a
> separate work item.
I'll try to implement this case.
>
> David

Download attachment "signature.asc" of type "application/pgp-signature" (473 bytes)