linux-kernel - Re: linux-next: manual merge of the vfs tree with the ext4 tree

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

Message-ID: <20150414204327.GC29810@thunk.org>
Date:	Tue, 14 Apr 2015 16:43:27 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Christoph Hellwig <hch@....de>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Al Viro <viro@...IV.linux.org.uk>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, Sheng Yong <shengyong1@...wei.com>
Subject: Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 06:18:41PM +0200, Christoph Hellwig wrote:
> Also for something that while only
> implemented in one filesystem has pretty broad API implications I'd
> really expect a generalist VFS review (I plan to get to it ASAP..).

There really isn't much of an API.  We have an ioctl to set the
encryption policy (which currently is only which encryption key and
the encryption modes to be used) on an empty directory, an ioctl to
fetch the encryption policy, and an ioctl to get a per-file system
password salt[1] (to protect against rainbow tables).

We *know* that the API will be need to be extended to support more
complicated encryption policies (i.e., the use of public key, files
that can be read by possessors of more than one key, etc.), but we
also know we're not smart enough to figure out what that API will look
like right now.  So that is something that will have to be extended
later, almost certainly with a new ioctl.

So I've designed the existing interface to be things that can be
easily supported into the future, and if the existing interfaces are
only supported by ext4, and someone else wants to design a new system
call, and argue about x509 vs GPG certificates for the future use of
public key crypto, that's fine.  I just don't want the patches to be
delayed while the interface bikeshedding party is going on.  :-)

					- Ted

[1] Note that the use of the password salt, and the string-to-key
algorithm specified by NIST SP800-132, is purely optional.  It's what
the e4crypt userspace tool happens to use, but if you want to use your
own string-to-key algorithm, or just use bare AES keys, a userspace
tool can always do that.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/