0

I have been adding lines similar to this to a file in /etc/sudoers.d/:

%mygroupname ALL=(ALL) NOPASSWD: /sbin/mount, /sbin/umount

However, I believe that can be improved upon. For example, I am considering this version:

%mygroupname host9=(%wheel) NOPASSWD: /sbin/mount, /sbin/umount

The commands listed are just examples. In actual use these may be custom scripts or system commands.

My intention here, if I understand this correctly, is to allow members of mygroupname to execute mount and umount only on the specific host9 machine and to further prevent execution from being runas "ALL". Do I gain anything from these extra steps? I'm especially interested in how to leverage the runas list so that commands cannot be runas ALL.

My thought is that if the runas limitation is not defined or is defined as ALL, that opens up more potential security holes than if a more limited runas definition is used. I am considering creating a user or group with specific priviledges for this purpose, but some of the commands being run in scripts require sudo rights. Do I gain anything from this extra effort? Any suggestions regarding best practices are appreciated.

My specific question is how to properly define the runas list to tighten security on these priviledged commands that ordinary users are allowed to run.

  • mount is a particularly bad example for this. Assuming root is in wheel, these users could simply bind-mount over /etc/sudoers and get whatever privileges they need. runas-whitelisting may be worth it if not granting such broad privileges to a user. – muru Aug 13 '18 at 4:54
  • Actually, mount is an interesting example for the reason you point out. This is the type of gotcha that I am trying to avoid. For mounts, I currently use a script that mounts only specific network shares. But I want to tighten things up further and I would like to know how to use "runas-whitelisting" as you called it. – MountainX Aug 13 '18 at 5:10
  • Then it's mostly a question of whether these mounts are in fstab and have the user/users options specified - because otherwise mount needs to be run as root, so running mount as other users isn't very useful. – muru Aug 13 '18 at 5:16

Your Answer

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

Browse other questions tagged or ask your own question.