12

Does this way have any security issues other than what's mentioned in that post?

For reference:

Create a new group called say veracryptusers and give it the necessary permissions to use VeraCrypt without root password. Any user that belongs to that group will be able to use VeraCrypt. Note: this slightly increases attack surface for user rights elevation, so be sure to add only trusted users to this group.

$ groupadd veracryptusers

Now let's give this group sudo permissions limited to VeraCrypt:

$ sudo visudo -f /etc/sudoers.d/veracrypt
GNU nano 2.5.3        File: /etc/sudoers.d/veracrypt.tmp                      

Users in the veracryptusers group are allowed to run veracrypt as root.

%veracryptusers ALL=(root) NOPASSWD:/usr/bin/veracrypt

Also please make sure that veracrypt and /usr/bin have the proper permissions and are NOT writable by groups nor others:

$ ls -al /usr/bin/vera*
-rwxr-xr-x 1 root root 6341016 paź 17  2016 /usr/bin/veracrypt
$ ls -ald /usr/bin
drwxr-xr-x 2 root root 69632 lip 25 10:09 /usr/bin

Otherwise a malicious user may replace the executable and gain total root right at his wish.

Now reboot (or relogin) to have groups membership revaluated and voilà - you can mount and unmount your favourite volumes.

16

This is extremely insecure. I'm glad you asked elsewhere before running this setup yourself! I hope those 3000+ people on AskUbuntu were similarly cautious. So, why is this insecure? What can an attacker do if you put them in the group? That group will be able to elevate privileges to root. The reason is simple: VeraCrypt allows mounting an encrypted volume of arbitrary file permissions, using an arbitrary filesystem with arbitrary mount flags. Consider the following scenario:

  1. An evil user is put in your special group, letting them run VeraCrypt as root without a password. This user wants to exploit your setup to get a root shell, allowing them to run commands other than /usr/bin/veracrypt as root. Their final goal is simple: bypass the restrictions you have in place and run arbitrary commands as root.

  2. An encrypted volume is created, owned and writable by the evil user. It is formatted, and a bash binary is copied to the filesystem. As the volume is directly writable, the setuid bit can be set on the binary. This is normally impossible, but our attacker can modify the volume.

  3. The evil user runs VeraCrypt as root and mounts the volume to /mnt (a normally privileged operation). They run /mnt/bash and get a root shell, from which they are able to execute any command as a privileged user. They have their root shell and can execute anything they want.

Normally, a user-mountable filesystem will have several restrictions in place. Such filesystems are typically configured by mounting with the user flag. According to the mount(8) manpage:

user

Allow an ordinary user to mount the filesystem. The name of the mounting
user is written to mtab so that he can unmount the filesystem again. This
option implies the options noexec, nosuid, and nodev (unless overridden
by subsequent options, as in the option line user,exec,dev,suid). 

When a filesystem is mounted by an unprivileged user this way, despite the fact that they can create a filesystem with a setuid executable, the system will not honor the setuid bit when the filesystem is mounted. VeraCrypt has no way of knowing all this, and happily mounts the writable filesystem as root, with full support for setuid binaries. This safeguard is bypassed, and the attackers gets root, despite you only allowing one "safe" command via sudoers.

I'm sure there are other possible attacks as well. Does your filesystem have any mount flags that, on their own, can give an attacker root? Can keyfiles or new volumes be written to arbitrary locations? If so, can their contents be chosen by the user? When you bypass an important safeguard, you suddenly must rely on the designers of VeraCrypt writing the program in such a way that it protects from a threat model they never even considered. Unlike the mount program, which was designed from the start to be safe even when run as root by an unprivileged user, VeraCrypt had no such goals. The same considerations should apply to anything before you run it as root.

-1

I have looked for a solution to that problem and bumped into several warnings about this method's security.

I believe the warnings are totally justified, although I believe that for the quite mainstream use case where a user that is part of the group "root" just wants to mount the VeraCrypt container without having to enter their password (for example in a script run at session opening), the method described in the original post is safe.

In this case, the user already has root privileges anyway, and the described method will just allow them to transparently and automatically mount encrypted containers/partitions like LUKS would do.

That said, I am not entirely sure of it and it should be confirmed by really knowledgeable people.

  • This isn't correct. The user doesn't "already have root privileges". They have the ability to become root with a password, but they are not already root. This method essentially gives someone with no knowledge of your root or wheel password to elevate themselves to root, which is extremely insecure. – forest Oct 26 '19 at 21:53
  • @forest true, I had not thought of the case where a user is part of the group "root" without actually being granted the password. I was more thinking of mainstream use cases, as mentioned, where the considered non-root user is a person who also happen to own the root account, which is the most frequent case for people owning their computer and using it privately. – Freedim Oct 28 '19 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy