linux-ext4 - [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-next>] [day] [month] [year] [list]

Message-ID: <87ioapt1fj.fsf@openvz.org>
Date:	Mon, 15 Jun 2015 18:51:28 +0300
From:	Dmitry Monakhov <dmonakhov@...nvz.org>
To:	keyrings@...ux-nfs.org
CC:	ext4 development <linux-ext4@...r.kernel.org>, dhowells@...hat.com
Subject: [RFC] keyctl {clear,revoke} serialization with key-users

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.




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