Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm a graduate student trying to use a cluster at my university. These machines are shared, so I want to protect the source code I use (I signed a NDA, so I'm scared about publishing the code by accident or making it public very easily). So far, I managed to put my source code in a ecryptfs. To disable access from other users, I use:

unshare -m /bin/bash 

and then:

mount -n -t ecryptfs ~home/crypt ~home/crypt

This works very nice on my workstation, encrypting the folder ~home/crypt only in the current session. Even the same user cannot access the encrypted files without mounting it again. The problem I have is that I need to be a sudoer to run these commands.

The cluster administrator gave access to:

sudo mount -n -t ecryptfs ~/crypt ~/crypt

But,

sudo unshare -m /bin/bash

would give me a root shell and this is a show stopper.

Is there another solution for this? Can a sudoers config solve this kind of problem?

I'm compiling a C++ system using some external libraries. So far, I'm building a VM to compile my code with the same libraries used on the Cluster (same Linux distro, etc). But this solution won't be ok for a long time, as Cluster updates would break my next build/release cycle. I will try to release my code in static mode too, but I really don't like this approach.

I'm using a Linux CentOS 6.3 64 bits (Intel) machine.

Source files are stored in a NAS (8TB) with FTP access and a very weak web interface.

share|improve this question
1  
Sit down with your advisor and possibly a representative of the Uni's legal department and then contact the party you signed the NDA with. Discuss with them what are reasonable and sufficient measures to meet the requirements of your NDA. If you can't run your code on your workstation and must use shared resources like that cluster to complete your computations in a timely manner there's only so much you can reasonably do. In many shared environments chmod 700 $HOME is probably the most... You can't really run mount -t ecryptfs ~home/crypt ^2 on each cluster node... –  HBruijn Dec 16 '13 at 17:37
    
As you are already keeping the data in a directory, archive the directory (tar,zip) and encrypt the archive with gpg. Otherwise, without root access, permissions of 700 on /home are likely sufficient and will protect your data from all but root. See cyberciti.biz/tips/… –  bodhi.zazen Dec 16 '13 at 18:46
    
from my manual The unshare command drops potential privileges before executing the target program. This allows to setuid unshare. -- or sudo it. Though my experiments show this to be not true. –  richard Dec 16 '13 at 23:11
    
Hi HBruijn, I would use encryption just on the source code. Once compiled, the binaries are distributed in a shared file system to all other machines on the cluster. I will definitively check with them about the NDA. –  nmenezes Dec 17 '13 at 14:06
    
@bodhi.zazen, root is a nice guy, what I'm afraid is about other sudoers (but I checked them again, there aren't many and their sudo is limited to few commands). The file permissions are not ok for me, as they are set in NAS with a web interface and a Windows 95 like security control. The root of the NAS is publicly writable and so far, there is no other way to change this. The NAS is managed by one department and the cluster by another one... I think the best is to keep source code on the Linux home and protect it with ecriptfs just in case the hd goes rogue. –  nmenezes Dec 17 '13 at 14:11
show 1 more comment

1 Answer

Encryption is a red herring here. It only protects against a very small set of threats.

The administrator of the cluster can read all your files as soon as you enter the key to decrypt them. Encryption would only protect you against the administrator if you never decrypted the files on the cluster, in which case you could use some offline form of encrypted storage such as PGP.

Other users are constrained by file permissions. Whether the files are stored encrypted or not is irrelevant; they can't even know that except by checking the location of the files against the encrypted filesystem mount points — and technically they can't be sure whether a FUSE filesystem stored its data in an encrypted way.

Encryption only protects against someone who would access the storage while it's unmounted, in particular backups made without accessing your ecryptfs mount point. This is a very limited threat. Your laptop (if you have one and store these files on it) is more of a risk

Unless you have explicit instructions to protect against these rare threats, don't bother with encryption: it's the wrong tool. What you need, whether you use encryption or not, is proper file permissions.

If you set a directory to be readable only by you (chmod 700 /path/to/directory or chmod u+rwx,go= /path/to/directory, showing as drwx------ in the ls -l output), then other users can't access any file that's under this directory. The lack of x permission on the directory prevents them from accessing any file or subdirectory in it.

share|improve this answer
    
Hi Gilles, file permissions would be fine if my files weren't stored in a NAS. The problem is that this NAS has a web interface, very, very permissive. The root is publicly writable, so anybody can change the directory permissions. –  nmenezes Dec 17 '13 at 14:15
    
with the unshare command, other users, even root, would have to search for the mount point at /proc. In my tests, even if I log in another terminal, the files still encrypted. I think I will mix this solution, to encrypt the source code files at the Linux Home, and not at the NAS. –  nmenezes Dec 17 '13 at 14:17
    
Oh, I see. This is important information, you should have mentioned it in your question! In this case, based on the incomplete information I have about your setup, it looks like you should encrypt the files on the NAS and mount them on the cluster and decrypt them there. You don't need to use unshare: just ensure that the encryptfs mount point (or a directory above it) has permissions 700. –  Gilles Dec 17 '13 at 14:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.