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

Message-ID: <29565.1434557922@warthog.procyon.org.uk>
Date:	Wed, 17 Jun 2015 17:18:42 +0100
From:	David Howells <dhowells@...hat.com>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
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

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.  It
might not be entirely practical though and might be better off done from a
separate work item.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html