[RFC] keyctl {clear,revoke} serialization with key-users

[Dmitry Monakhov <dmonakhov@openvz.org>]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

Hi,
I'm not an expert in security/keyring stuff but I want to solve an
issue which originally comes from ext4 in most convenient way

Description:
ext4 now use security/key infrastructure for data encryption (keytype = 'logon')
see: https://github.com/torvalds/linux/blob/master/fs/ext4/crypto_key.c
There are use-cases where key added and removed dynamically
#################
# User login and add user's key
e4crypt add_key -S /home/$USER  # analog of keyctl add $SOME_ARG
# some activity
echo test > /home/$USER/my_file
#Logout
keyctl clear @s
############
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
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.




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]