There's an scenario that I'm worried about, and I'm not sure if it's possible to archieve. I got a machine with this setup:

  • A LUKS-ciphered main system partition.
  • An user with sudo access (added to sudoers list).
  • The sudoer canno't log in as root (since he doesn't know the password), also - canno't do "sudo su".
  • I got, as sysadmin, root access.

The question is: can I prevent or deny somehow the sudoer user from changing the LUKS Master Key?

I can deny him from executing dm-setup or cryptsetup, but he could always move and rename the files, or he may could download some library and program himself an application to change the MK. I don't know if there's something to prevent him from execute a linux action from kernel level, which dm-setup/cryptsetup interfaces to.

So, if I give sudoer access to an user, is there any way to keep the LUKS Master Key unchanged?

2 Answers 2


You are drawing a false dichotomy between "logging in as root" and "having sudo access". These shouldn't be thought of as such different things. If you don't trust your users with root access then don't let them use sudo! Blocking just the command sudo su is nonsense anyway, there is a sudo -s to get a root shell or you can sudo bash. Or there are a million other ways.

Basically you cannot create a blacklist of things sudo users cannot do. You will fail as it was not meant to work that way. Once you have access to a handful of things as PID 1 the system is yours.

What you can do is whitelist specific processes. Make sure these processes are not also writable by the user and make sure they don't accept user input or arguments in a way that would allow arbitrary command execution. Beware many common unix tools allow arbitrary commands in one way or another. A good method if they only need sudo access to do one task is to create a wrapper script that does just that one task and accepts no arguments and allow the user to execute that script as root.


If by master key you mean the key used to encrypt content, that can't be changed without re-writing the LUKS container: unlock to access data, backup data, recreate LUKS container, and restore from backup.

If what you mean by master key is simply one of the passphrases used to unlock the LUKS container, then yes those can be changed, but you have to know an existing passphrase first.

In short, if you don't want the other user to be able to mess with the LUKS keys, then don't tell him/her the passphrase. You don't need to do anything with sudo. And of course, make an off-site backup of the LUKS header so that you can restore it if it's ever corrupted or tampered with.

Your Answer

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

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