dyne / Tomb

the Crypto Undertaker

Home Page:https://dyne.org/software/tomb

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Privilege Escalation

nerun opened this issue · comments

This is my /etc/sudoers.d/tomb:

# BASED UPON tomb manual pages
# Section "PRIVILEGE ESCALATION"

# Command alias specification
Cmnd_Alias TOMB = /usr/bin/tomb

# Avoid that tomb execution is logged by syslog
Defaults!TOMB !syslog

# Allow all users to execute "tomb" without password
ALL ALL=NOPASSWD: TOMB

It works well, but not for tomb lock nor tomb open. They still requires sudo password. Any workaround?

commented

Thanks for the note. I will try to take a look at the issue this weekend.
There may be some update necessary. I faintly remember there being some change in the sudoers syntax which may playing a part in this.
For completeness: What version of sudo are you using?

  • Linux Mint 21.1 x86_64
  • 5.19.0-45-generic
  • sudo 1.9.9
  • tomb 2.9.0
commented

Took a quick look and the sudoers config from the man-page still works without adjustments with sudo 1.9.13.p3 .
Just to make sure:

  • Your main sudoers config file contains a line with @includedir /etc/sudoers.d?
  • You did run sudo tomb open (...) instead of tomb open (...)?

Oh my... Yes to both questions. I run just tomb open (...) and no sudo password was asked.

Sorry, i tried again and it asked for password. I remembered that terminal sessions store sudo password.

sudorequired

/etc/sudoers.d/tomb

# BASED UPON tomb manual pages
# Section "PRIVILEGE ESCALATION"

# Command alias specification
Cmnd_Alias TOMB = /usr/bin/tomb

# Avoid that tomb execution is logged by syslog
Defaults!TOMB !syslog

# Allow all users to execute "tomb" without password
ALL ALL=NOPASSWD: TOMB

/etc/sudoers

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults	use_pty

# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"

# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"

# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"

# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"

# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"

# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin	ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "@include" directives:
@includedir /etc/sudoers.d
commented

Config looks good.
Maybe my second question wasn't clear enough, but seeing the picture confirms the pitfall I also fell into :D I notice, that you still run tomb directly (unless you have a shell alias set?).
Instead of $ tomb lock tumba.lock -k tumba.tomb.key you need to run $ sudo tomb lock tumba.lock -k tumba.tomb.key.
The sudo calls in tomb itself are calling different tools which don't apply to the Cmnd_alias and therefore the sudoers rule won't get applied. It isn't aware that it is called from within.
But calling tomb itself with sudo will apply the rule and the tools within.

See my picture
blubb2

First call to open und close is with sudo and doesn't require the password. The second call to open and close is the default one. There the password is needed for the open and still cached for the close call.

And you can always set an alias in your .$SHELLrc

alias tomb='sudo tomb'
commented

And if that still doesn't work check the output of whereis tomb. The path reported for the script must match with the Cmnd_alias path in sudoers.

Now it worked! I have used sudo tomb, no sudo password was required. Even with sudo dig the tomb is created with right ownership / group (user:user not root:root) it was one of my fears.

I have tested alias tomb=' sudo tomb', with space, and worked like a charm too!

THANK YOU VERY MUCH!