Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1532752 > unrolled thread

Re: [RFD] Common userspace tool for fscypto

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFD] Common userspace tool for fscypto Richard Weinberger <richard@nod.at> - 2016-11-29 21:50 +0100
    Re: [RFD] Common userspace tool for fscypto Joe Richey <joerichey@google.com> - 2016-11-29 22:50 +0100
      Re: [RFD] Common userspace tool for fscypto Richard Weinberger <richard@nod.at> - 2016-11-29 23:10 +0100
        Re: [RFD] Common userspace tool for fscypto Eric Biggers <ebiggers@google.com> - 2016-11-30 01:10 +0100
          Re: [RFD] Common userspace tool for fscypto Richard Weinberger <richard@nod.at> - 2016-11-30 09:30 +0100
            Re: [RFD] Common userspace tool for fscypto Eric Biggers <ebiggers@google.com> - 2016-12-03 01:50 +0100
        Re: [RFD] Common userspace tool for fscypto Theodore Ts'o <tytso@mit.edu> - 2016-11-30 22:10 +0100

#1532752 — Re: [RFD] Common userspace tool for fscypto

Michael,

On 19.10.2016 19:36, Michael Halcrow wrote:
>> That said, what about implementing such a tool as part of util-linux to control
>> fscrypto? We (David and I) would volunteer.
> 
> While discussing several changes we have staged for release (we're
> trying to minimize churn by batching a large set of format changes all
> at once), we've recently recognized this need on my team and were
> planning on starting work on exactly what you propose.

Did this plan already materialize? :-)

Thanks,
//richard

[toc] | [next] | [standalone]

#1532799

[Multipart message — attachments visible in raw view] — view raw

Hi Richard,

I'm Joe Richey, and I work on Mike's team. We've been playing around
with a few design
ideas regarding a tool for managing filesystem encryption. After going
though some iterations
with Ted, we have a fairly good idea about where to head design wise,
and I'm working on a
design document for it. It's a bit preliminary at this point, but I
can share it if you want.

Our goal is to have a finished doc by end of Q4 and then get your and
Jaegeuk's feedback.

Thanks,
Joe

On Tue, Nov 29, 2016 at 12:48 PM, Richard Weinberger <richard@nod.at> wrote:
>
> Michael,
>
> On 19.10.2016 19:36, Michael Halcrow wrote:
> >> That said, what about implementing such a tool as part of util-linux to control
> >> fscrypto? We (David and I) would volunteer.
> >
> > While discussing several changes we have staged for release (we're
> > trying to minimize churn by batching a large set of format changes all
> > at once), we've recently recognized this need on my team and were
> > planning on starting work on exactly what you propose.
>
> Did this plan already materialize? :-)
>
> Thanks,
> //richard
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1532813

Joe,

On 29.11.2016 22:42, Joe Richey wrote:
> Hi Richard,
> 
> I'm Joe Richey, and I work on Mike's team. We've been playing around
> with a few design
> ideas regarding a tool for managing filesystem encryption. After going
> though some iterations
> with Ted, we have a fairly good idea about where to head design wise,
> and I'm working on a
> design document for it. It's a bit preliminary at this point, but I
> can share it if you want.
> 
> Our goal is to have a finished doc by end of Q4 and then get your and
> Jaegeuk's feedback.

Thanks for your quick response!
I hoped you had already some code, but having a decent design document
is also nice. I'm eager to read it.

Do you also plan to address d/page cache related issues?
i.e. when two users are logged into the system user rw
is able to see decrypted file names and contents in /home/dags/
if user dags installs a key and accessed a file.

Or files in /home/dags/ are still readable even after
user dags purged the key.

The tool could play games with CLONE_NEWNS to hide directories.
To provide a correct "logout" we could expose shrink_dcache_parent()
to usespace such that the emerging tool can purge the key and flush
the dcache on the encrypted directory. But I fear exposing shrink_dcache_parent()
is not a good idea. :-)

Just some random ideas...

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1532855

On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote:
> 
> Do you also plan to address d/page cache related issues?
> i.e. when two users are logged into the system user rw
> is able to see decrypted file names and contents in /home/dags/
> if user dags installs a key and accessed a file.
> 

As far as I know, there are no plans to make it possible for one user to see
plaintext while another user sees ciphertext.  Fundamentally, the dentry, inode,
and page caches are shared systemwide.  This cannot be changed by using
namespaces; it can only be changed by doing something like an ecryptfs-style
stacked mount where the plaintext and ciphertext are actually exposed by
different filesystems.  And it was a fundamental design goal of ext4 encryption
to not do a stacked mount.

So the expectation is that to restrict access by other users once a key has been
provisioned, file permissions should be used.

> Or files in /home/dags/ are still readable even after
> user dags purged the key.

If you revoke the key (with 'keyctl revoke') rather than unlink the key (with
'keyctl unlink') then it actually does appear to work currently.  The difference
is that revoking the key is a modification of the key, whereas unlinking the key
is only removing a link to the key without affecting any links which the kernel
may have internally or which userspace may have in other keyrings.  Revocation
(but not unlinking) is detected by fscrypt_get_encryption_info() when someone
tries to open an encrypted file or directory.  There's also a d_revalidate
dentry operation which cause a dentry to be invalidated if it's a plaintext name
but the directory key is no longer valid, or if it's a ciphertext name but the
directory key is now valid.

There is however still work needed to make key revocation interact sanely with
ongoing filesystem operations.

Eric

[toc] | [prev] | [next] | [standalone]

#1533062

Eric,

On 30.11.2016 01:04, Eric Biggers wrote:
> On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote:
>>
>> Do you also plan to address d/page cache related issues?
>> i.e. when two users are logged into the system user rw
>> is able to see decrypted file names and contents in /home/dags/
>> if user dags installs a key and accessed a file.
>>
> 
> As far as I know, there are no plans to make it possible for one user to see
> plaintext while another user sees ciphertext.  Fundamentally, the dentry, inode,
> and page caches are shared systemwide.  This cannot be changed by using
> namespaces; it can only be changed by doing something like an ecryptfs-style
> stacked mount where the plaintext and ciphertext are actually exposed by
> different filesystems.  And it was a fundamental design goal of ext4 encryption
> to not do a stacked mount.

Well, we could over-mount /home/rw with an empty directory for every user except rw.

> So the expectation is that to restrict access by other users once a key has been
> provisioned, file permissions should be used.
> 
>> Or files in /home/dags/ are still readable even after
>> user dags purged the key.
> 
> If you revoke the key (with 'keyctl revoke') rather than unlink the key (with
> 'keyctl unlink') then it actually does appear to work currently.  The difference
> is that revoking the key is a modification of the key, whereas unlinking the key
> is only removing a link to the key without affecting any links which the kernel
> may have internally or which userspace may have in other keyrings.  Revocation
> (but not unlinking) is detected by fscrypt_get_encryption_info() when someone
> tries to open an encrypted file or directory.  There's also a d_revalidate
> dentry operation which cause a dentry to be invalidated if it's a plaintext name
> but the directory key is no longer valid, or if it's a ciphertext name but the
> directory key is now valid.

Ahh, in my quick and dirty tests I've always used purge. Let me try revoke. :)

BTW: This limitations needs to be clearly documented somewhere.
Usually an user thinks that only she can access encrypted files...

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1535283

On Wed, Nov 30, 2016 at 09:27:28AM +0100, Richard Weinberger wrote:
> 
> BTW: This limitations needs to be clearly documented somewhere.
> Usually an user thinks that only she can access encrypted files...
> 
> Thanks,
> //richard

For what it's worth, I've been making a few updates to the public design
document for ext4 encryption based on what's actually upstream now:

https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg

It still needs work, though.  It doesn't really answer the questions about
access control and key revocation, for example, and of course now the upstream
code isn't actually ext4 specific anymore.

At some point it might be nice to write some in-tree documentation for fscrypto,
e.g. a file Documentation/filesystems/fscrypto.txt.

Eric

[toc] | [prev] | [next] | [standalone]

#1533579

On Tue, Nov 29, 2016 at 10:59:28PM +0100, Richard Weinberger wrote:
> Thanks for your quick response!
> I hoped you had already some code, but having a decent design document
> is also nice. I'm eager to read it.

To be clear, the design document which Joe is working on is only
addressing a new way of transforming a password or passphrase into a
key.  Previouly, we used PBKDF2 using a per-file system salt.  (Well,
that's what e4crypt used.  Android used a completely random key that
was protected by the user's pin or passphrase --- possibly stored in
ARM TrustZone on some handsets.)

The goal is to come up with something that works well with
single-signon (i.e., can be integrated into PAM), as well as removable
storage devices and directories that are protected by some passphrase
other than the user's login for those people who are especially
security conscious.  It should also handle the password change case.

It probably won't cover key recovery initially (that's probably more
of a V2 or V3 thing), but the design should accomodate that.

> Do you also plan to address d/page cache related issues?
> i.e. when two users are logged into the system user rw
> is able to see decrypted file names and contents in /home/dags/
> if user dags installs a key and accessed a file.
> 
> Or files in /home/dags/ are still readable even after
> user dags purged the key.
> 
> The tool could play games with CLONE_NEWNS to hide directories.
> To provide a correct "logout" we could expose shrink_dcache_parent()
> to usespace such that the emerging tool can purge the key and flush
> the dcache on the encrypted directory. But I fear exposing shrink_dcache_parent()
> is not a good idea. :-)

Right now, the best thing I can suggest is "echo 3 >
/proc/sys/vm/drop_caches" in executed PAM module on when the user
terminates their login session.  If you're really paranoid, make sure
all processes running under the user's pid are terminated with extreme
prejudice first.

We don't have a good solution for a high security directory (e.g.,
$HOME/bitcoin) where you want to drop its keys and cached data in the
middle of a user login session today.  The drop_caches solution
doesn't work well on a time sharing system since it drops *all*
caches.  Also, if you have anything keeping pages or file descriptors,
etc., pinned, the drop_cache solution won't address that either.

I suspect any realistic solution will require changes that will need
to be run by the Al Viro and the MM folks, and may require adding
something like BSD's revoke(2) functionality.  To be honest, this
isn't a particularly high priority item at the moment for me or
Michael's team at the moment, so if someone wants to work on it, feel
free.  As they say, high quality patches are always accepted.  :-)

Cheers,

					- Ted

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web