[Gluster-devel] Transparent encryption in GlusterFS: Implications on manageability

[Edward Shishkin]

Hi all,

Unfortunately it is impossible to validate non-trusted volfiles
using existing glusterfs options. Semantic and format of values
passed by the --xlator-option don't allow to "deliver" trusted
values without compromises with security.

So I have added a new --secure-xlator-option,
Please, review:
review.gluster.org/8657

Thanks,
Edward.


On Wed, 13 Aug 2014 12:26:29 -0700
Anand Avati <avati at gluster.org> wrote:

> +1 for all the points.
> 
> 
> On Wed, Aug 13, 2014 at 11:22 AM, Jeff Darcy <jdarcy at redhat.com>
> wrote:
> 
> > >             I.1 Generating the master volume key
> > >
> > >
> > > Master volume key should be generated by user on the trusted
> > > machine. Recommendations on master key generation provided at
> > > section 6.2 of the manpages [1]. Generating of master volume key
> > > is in user's competence.
> >
> > That was fine for an initial implementation, but it's still the
> > single largest obstacle to adoption of this feature.  Looking
> > forward, we need to provide full CLI support for generating keys in
> > the necessary format, specifying their location, etc.
> >
> > >            I.2 Location of the master volume key when mounting a
> > >            volume
> > >
> > >
> > > At mount time the crypt translator searches for a master volume
> > > key on the client machine at the location specified by the
> > > respective translator option. If there is no any key at the
> > > specified location, or the key at specified location is in
> > > improper format, then mount will fail. Otherwise, the crypt
> > > translator loads the key to its private memory data structures.
> > >
> > > Location of the master volume key can be specified at volume
> > > creation time (see option "master-key", section 6.7 of the man
> > > pages [1]). However, this option can be overridden by user at
> > > mount time to specify another location, see section 7 of manpages
> > > [1], steps 6, 7, 8.
> >
> > Again, we need to improve on this.  We should support this as a
> > volume or mount option in its own right, not rely on the generic
> > --xlator-option mechanism.  Adding options to mount.glusterfs isn't
> > hard.  Alternatively, we could make this look like a volume option
> > settable once through the CLI, even though the path is stored
> > locally on the client.  Or we could provide a separate
> > special-purpose command/script, which again only needs to be run
> > once.  It would even be acceptable to treat the path to the key
> > file (not its contents!) as a true volume option, stored on the
> > servers.  Any of these would be better than requiring the user to
> > understand our volfile format and construction so that they can add
> > the necessary option by hand.
> >
> > >                II. Check graph of translators on your client
> > > machine after mount!
> > >
> > >
> > > During mount your client machine receives configuration info from
> > > the non-trusted server. In particular, this info contains the
> > > graph of translators, which can be subjected to tampering, so
> > > that encryption won't be invoked for your volume at all. So it is
> > > highly important to verify this graph. After successful mount
> > > make sure that the graph of translators contains the crypt
> > > translator with proper options (see FAQ#1, section 11 of the
> > > manpages [1]).
> >
> > It is important to verify the graph, but not by poking through log
> > files and not without more information about what to look for.  So
> > we got a volfile that includes the crypt translator, with some
> > options.  The *code* should ensure that the master-key option has
> > the value from the command line or local config, and not some
> > other.  If we have to add special support for this in
> > otherwise-generic graph initialization code, that's fine.
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> >