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.
Dmitry Monakhov <[email protected]> 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. It
might not be entirely practical though and might be better off done from a
separate work item.
David
David Howells <[email protected]> writes:
> Dmitry Monakhov <[email protected]> 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