On Mon, 14 Oct 2013 14:27:01 -0700 Anand Avati <avati@xxxxxxxxxx> wrote: Hi all, > Edward, > It looks like this patch requires a higher version of openssl (I > recall you have mentioned before that that dependency was on version > 1.0.1c? I checked yum update on the build server and the latest > available version is 1.0.0-27. Is there a "clean" way to get the > right version of openssl to a RHEL/CENTOS-6.x server? The most clean way, I think, would be to upgrade to 6.5, which is not yet released: RHEL 6.5 (and, I guess CENTOS 6.5) will be with the new openssl (1.0.1e). The next way is to replace the (old) openssl with so-called openssl10 from the "IUS commuinity repo" for CENTOS by a specail "yum-plugin-replace" plugin, which also can be found at the IUS repo: # rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/Redhat/6/x86_64/epel-release-6-5.noarch.rpm # rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/Redhat/6/x86_64/ius-release-1.0-11.ius.el6.noarch.rpm # yum install yum-plugin-replace # yum replace openssl --replace-with=openssl10 --enablerepo=ius The same for openssl-devel: if you have it installed, then replace it with openssl10-devel: # yum replace openssl-devel --replace-with=openssl10-devel --enablerepo=ius Otherwise, use "yum install openssl10-devel" instead. This works for my RHEL 6.0, and I guess it will work for the build server. Anyway, you can restore the old packages (make sure in the interactive session, that yum doesn't touch other ones). > > Also note that the previous submission of the patch was at > http://review.gluster.org/4667. The recent on > (http://review.gluster.org/6086) has a different Change-Id: in the > commit log. It will be good if you can re-submit the patch with the > old Change-Id (and abandon #6086) so that we can maintain the history > of resubmission and the old work on records. OK, I'll do it on the top of 4667 Edward. > > Thanks! > Avati > > On 10/14/2013 07:26 AM, Edward Shishkin (Code Review) wrote: > > Edward Shishkin has uploaded a new change for review. > > > > http://review.gluster.org/6086 > > > > > > Change subject: Transparent data encryption and metadata > > authentication in the systems with non-trusted server (take > > II) ...................................................................... > > > > Transparent data encryption and metadata authentication > > in the systems with non-trusted server (take II) > > > > This new functionality can be useful in various cloud technologies. > > It is implemented via a special encryption/crypt translator, which > > works on the client side and performs encryption and authentication; > > > > 1. Class of supported algorithms > > > > The crypt translator can support any atomic symmetric block cipher > > algorithms (which require to pad plain/cipher text before performing > > encryption/decryption transform (see glossary in atom.c for > > definitions). In particular, it can support algorithms with the EOF > > issue (which require to pad the end of file by extra-data). > > > > Crypt translator performs translations > > user -> (offset, size) -> (aligned-offset, padded-size) ->server > > (and backward), and resolves individual FOPs (write(), truncate(), > > etc) to read-modify-write sequences. > > > > A volume can contain files encrypted by different algorithms of the > > mentioned class. To change some option value just reconfigure the > > volume. > > > > Currently only one algorithm is supported: AES_XTS. > > > > Example of algorithms, which can not be supported by the crypt > > translator: > > > > 1. Asymmetric block cipher algorithms, which inflate data, e.g. RSA; > > 2. Symmetric block cipher algorithms with inline MACs for data > > authentication. > > > > 2. Implementation notes. > > > > a) Atomic algorithms > > > > Since any process in a stackable file system manipulates with local > > data (which can be obsoleted by local data of another process), any > > atomic cipher algorithm without proper support can lead to non-POSIX > > behavior. To resolve the "collisions" we introduce locks: before > > performing FOP->read(), FOP->write(), etc. the process should first > > lock the file. > > > > b) Algorithms with EOF issue > > > > Such algorithms require to pad the end of file with some extra-data. > > Without proper support this will result in losing information about > > real file size. Keeping a track of real file size is a > > responsibility of the crypt translator. A special extended > > attribute with the name "trusted.glusterfs.crypt.att.size" is used > > for this purpose. All files contained in bricks of encrypted volume > > do have "padded" sizes. > > > > 3. Non-trusted servers and > > Metadata authentication > > > > We assume that server, where user's data is stored on is > > non-trusted. It means that the server can be subjected to various > > attacks directed to reveal user's encrypted personal data. We > > provide protection against such attacks. > > > > Every encrypted file has specific private attributes (cipher > > algorithm id, atom size, etc), which are packed to a string > > (so-called "format string") and stored as a special extended > > attribute with the name "trusted.glusterfs.crypt.att.cfmt". We > > protect the string from tampering. This protection is mandatory, > > hardcoded and is always on. Without such protection various attacks > > (based on extending the scope of per-file secret keys) are possible. > > > > Our authentication method has been developed in tight collaboration > > with Red Hat security team and is implemented as "metadata loader of > > version 1" (see file metadata.c). This method is NIST-compliant and > > is based on checking 8-byte per-hardlink MACs created(updated) by > > FOP->create(), FOP->link(), FOP->unlink(), FOP->rename() by the > > following unique entities: > > > > . file (hardlink) name; > > . verified file's object id (gfid). > > > > Every time, before manipulating with a file, we check it's MACs at > > FOP->open() time. Some FOPs don't require a file to be opened (e.g. > > FOP->truncate()). In such cases the crypt translator opens the file > > mandatory. > > > > 4. Generating keys > > > > Unique per-file keys are derived by NIST-compliant methods from the > > > > a) parent key; > > b) unique verified object-id of the file (gfid); > > Per-volume master key, provided by user at mount time is in the root > > of this "tree of keys". > > > > Those keys are used to: > > > > 1) encrypt/decrypt file data; > > 2) encrypt/decrypt file metadata; > > 3) create per-file and per-link MACs for metadata authentication. > > > > 5. Instructions > > Getting started with crypt translator > > > > Example: > > > > 1) Create a volume "myvol" by specifying the option "encrypt": > > > > # gluster volume create myvol encrypt pepelac:/vols/xvol > > > > 2) Set location (absolute pathname) of your master key: > > > > # gluster volume set myvol encryption.master-key /home/me/mykey > > > > 3) Set other options to override default options, if needed. > > > > 4) On the client side make sure that the file /home/me/mykey exists > > and contains proper per-volume master key (that is 256-bit AES > > key). This key has to be in hex form, i.e. should be represented > > by 64 symbols from the set {'0', ..., '9', 'a', ..., 'f'}. > > The key should start at the beginning of the file. All symbols > > at offsets >= 64 are ignored. > > > > 5) Mount the volume "myvol" on the client side: > > > > # glusterfs --volfile-server=pepelac --volfile-id=myvol /mnt > > > > After successful mount the file which contains master key may be > > removed. NOTE: Keeping the master key between mount sessions is > > in user's competence. > > > > ********************************************************************** > > > > WARNING! Losing the master key will make content of all regular > > files inaccessible. Mount with improper master key allows to access > > content of directories: file names are not encrypted. > > > > ********************************************************************** > > > > 6. Options of crypt translator > > > > 1) "master-key": specifies location (absolute pathname) of the file > > which contains per-volume master key. There is no default > > location for master key. > > > > 2) "data-key-size": specifies size of per-file key for data > > encryption Possible values: > > . "256" default value > > . "512" > > > > 3) "block-size": specifies atom size. Possible values: > > . "512" > > . "1024" > > . "2048" > > . "4096" default value; > > > > 7. Test cases > > > > Any workload, which involves the following file operations: > > > > ->create(); > > ->open(); > > ->readv(); > > ->writev(); > > ->truncate(); > > ->ftruncate(); > > ->link(); > > ->unlink(); > > ->rename(); > > ->readdirp(). > > > > 8. TODOs: > > > > 1) Currently size of IOs issued by crypt translator is restricted > > by block_size (4K by default). We can use larger IOs to improve > > performance. > > > > Change-Id: Idc3523a8752888d3dd10f4fe71aa38dfc53d9ded > > Signed-off-by: Edward Shishkin <edward@xxxxxxxxxx> > > --- > > M cli/src/cli-cmd-parser.c > > M configure.ac > > M doc/gluster.8 > > M libglusterfs/src/gf-dirent.c > > M libglusterfs/src/gf-dirent.h > > M xlators/cluster/dht/src/dht-common.c > > M xlators/encryption/Makefile.am > > A xlators/encryption/crypt/Makefile.am > > A xlators/encryption/crypt/src/Makefile.am > > A xlators/encryption/crypt/src/atom.c > > A xlators/encryption/crypt/src/crypt-common.h > > A xlators/encryption/crypt/src/crypt-mem-types.h > > A xlators/encryption/crypt/src/crypt.c > > A xlators/encryption/crypt/src/crypt.h > > A xlators/encryption/crypt/src/data.c > > A xlators/encryption/crypt/src/keys.c > > A xlators/encryption/crypt/src/metadata.c > > A xlators/encryption/crypt/src/metadata.h > > M xlators/mgmt/glusterd/src/glusterd-store.c > > M xlators/mgmt/glusterd/src/glusterd-store.h > > M xlators/mgmt/glusterd/src/glusterd-volgen.c > > M xlators/mgmt/glusterd/src/glusterd-volume-ops.c > > M xlators/mgmt/glusterd/src/glusterd-volume-set.c > > M xlators/mgmt/glusterd/src/glusterd.h > > M xlators/protocol/client/src/client-rpc-fops.c > > 25 files changed, 8,733 insertions(+), 28 deletions(-) > > > > > > git pull ssh://git.gluster.org/glusterfs refs/changes/86/6086/1 > > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel
