2

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.

Improve this question
6
  • 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... Commented Dec 16, 2013 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/… Commented Dec 16, 2013 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. Commented Dec 16, 2013 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. Commented Dec 17, 2013 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. Commented Dec 17, 2013 at 14:11

2 Answers 2

Reset to default
2

Instead of using sudo to grant the possibility to use unshare, you could use the setuid bit, because the unshare program is designed to work with it. It says in the man page:

The unshare command drops potential privileges before executing the target program. This allows to setuid unshare.

So after executing sudo chmod u+s /usr/bin/unshare, running unshare -m will give you a shell as your own user, not as root.

If only a specific group of users should get the possibility to run unshare, set the permissions to something like

-rwsr-x--- 1 root unshare 10432 Feb 12 19:53 /usr/bin/unshare

Now only users in the group unshare will be able to execute it. Note that you can't restrict parameter values like you can with sudo.

Improve this answer
1

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.

Improve this answer
3
  • 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. Commented Dec 17, 2013 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. Commented Dec 17, 2013 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. Commented Dec 17, 2013 at 14:39

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.