15

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.

forest
  • 64,616
  • 20
  • 206
  • 257

2 Answers2

20

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.

forest
  • 64,616
  • 20
  • 206
  • 257
0

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.

Freedim
  • 11
  • 2
  • 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
  • @forest: So if it's just me at my computer, Freedim is right, correct? The only security issue here is when **other users** are added to the veracrypt group. If that doesn't happen, the system is as save as before, yes? – Grimm Jun 13 '20 at 12:27
  • 1
    @Grimm No, it's unsafe even if it's just you at the computer. Just because it's "your" user doesn't mean that your user can't be compromised, and this setup will allow an attacker to elevate from your user (which they compromise) to root. – forest Oct 12 '20 at 23:13
  • 1
    @forest But since my account is the only account on my computer, it already has sudo-privileges. If this user is compromised, all is lost. :D So from my point of view, nothing has changed. Please correct me, if I'm missing something. – Grimm Oct 13 '20 at 08:45
  • I want my VeraCrypt partition to be decrypted and mounted at start up automatically, thus I use a key file and no password. However, for super sensitive data I still have a veracrypt folder container with a super strong password. The method described by @Forest will protect your most sensitive data even when your user is compromised while the password-less method will effectively protect your data either at rest or online but only as long as your user was not compromised. One might want to use both methods for two different types of data. I do. – Freedim Oct 14 '20 at 05:02
  • @Grimm You may have sudo privileges, but you don't have root without knowing your password. If your browser is compromised (for example), it will not know your password. If you do this though, then it will be able to _trivially_ elevate to root. – forest Jan 01 '21 at 03:36
  • The new edit I have just added should end the discussion by providing a proper clean solution. – Freedim Mar 17 '21 at 12:48