Is it secure to mount Veracrypt without sudo password in this way

Question

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.

Answer 1

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.

Answer 2

EDIT 17/03/2021: All this topic is probably moot when knowing the following proper solution (many thanks to lady Serendipity, I wish I had read that before): https://www.computercorrect.com/2018/operating-systems/linux/ubuntu/auto-mounting-a-veracrypt-volume-under-ubuntu-debian-linux/

---

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.

Answer 3

Yes it is somewhat safe.

Generally speaking it is possible to gain root using an unrestricted mount permission e.g. by mounting a filesystem with a setuid bash in it.

But VeraCrypt always mounts filesystems using FUSE defaults which are nodev,nosuid, so this specific attack vector isn't really possible.

<GoryDetails>

See man mount.fuse:

Filesystems are mounted with nodev,nosuid by default, which can only be overridden by a privileged user.

And the source of VeraCrypt where it prepares the mount.fuse call:

        list <string> args;
        args.push_back (FuseService::GetDeviceType());
        args.push_back (fuseMountPoint);

#ifdef TC_MACOSX
        args.push_back ("-o");
        args.push_back ("noping_diskarb");
        args.push_back ("-o");
        args.push_back ("nobrowse");

        if (getuid() == 0 || geteuid() == 0)
#endif
        {
            args.push_back ("-o");
            args.push_back ("allow_other");
        }

        ExecFunctor execFunctor (openVolume, slotNumber);
        Process::Execute ("fuse", args, -1, &execFunctor);

Then Process::Execute subsequently invokes execvp, which in itself is immune to arguments quoting/escaping attacks (so one can't provide fuseMountPoint with additional flags appended to it). ExecFunctor also doesn't do much.

As we can see there is no way to add -o suid or any other flag, the list is essentially hardcoded.

</GoryDetails>

With that said, there could be other bugs in VeraCrypt that could be exploited to gain root. So it is safer to only allow trusted users (e.g. sudoers) to use VeraCrypt.