We, the siduction team, have decided to use a real root account and have not configured Sudo. For users who are used to Sudo and don’t want to do without its functionality, the slim alternative Doas is a good choice. Doas is tailored to desktop systems, having only about 1/100 of code lines in comparison to Sudo. With siduction 2021.3 wintersky, Doas is automatically installed in version 6.8.1-3, but is not yet fully configured.
The only thing missing to be able to use Doas is the configuration
file /etc/doas.conf
. It contains line-by-line
rules that assign actions to a user. A #
introduces
comments. Doas reads the lines one after the other, executing the action
of the last applicable rule. To understand the rules in the
configuration file, there are a few things to keep in mind.
- Only actions for which at least one rule applies are executed. - By
the fact that Doas evaluates the rules line by line one after the other,
hierarchies can be built up. - For rules that contain commands with
arguments, the arguments must be specified exactly and completely. -
Rules with commands that require variable arguments are not possible. -
Doas checks the syntax of the configuration file before executing the
requested action. In case of incorrect rules, Doas outputs
doas: syntax error at line 4
and then exits. The write
access to the configuration file is then only possible with the
root account.
The configuration is particularly simple if only one user account
exists on the siduction system. A single line is sufficient to execute
commands with root privileges using the prefix “doas”.
Log in to a terminal as root and execute the following
command, replacing “tux” with the name of your user account.
tux@sidu:~$ su
Password:
root@sidu:/home/tux# echo "permit keepenv nopass tux" > /etc/doas.conf
root@sidu:/home/tux# exit
tux@sidu:~$
The configuration line consists of:
The action permit|deny with
the option keepenv (this allows to start graphical programs
like gparted),
the option nopass|persist (no password request|the one-time
password entry remains valid for a limited time), and
the user tux to which the action is to be applied.
If the username stands alone, tux may execute
commands as any user present on the system. The default is
root. If the execution of the action is to be allowed
only with the rights of a user other than root, the
name must be specified within the rule (e.g. tux as anne).
Instead of the user, a group (e.g. :vboxusers) can gain
permissions by prepending a :
.
Example
On the workstation PC, in addition to tux, three other
users named anne, bob, and
lisa are allowed to log in.
Anne only wants to allow Bob to run two of her scripts from her
/home directory. Anne has restrictively set the
permissions on her scripts to 700.
Lisa is especially trustworthy, so she should be in charge of system
upgrades.
Now, as user tux, we use Doas in a terminal to edit the configuration file.
tux@sidu:~$ doas mcedit /etc/doas.conf
We convert the previously mentioned permissions into rules and add some comments to the file.
# doas config file /etc/doas.conf
# tux gets root privileges
permit keepenv nopass tux
# bob may execute anne's script
permit bob as anne cmd /home/anne/bin/script1 args -n
permit bob as anne cmd /home/anne/bin/script2 args
# lisa may execute system upgrade
permit persist lisa cmd init
deny lisa cmd init args 1
deny lisa cmd init args 5
permit persist lisa cmd apt args update
permit persist lisa cmd apt args full-upgrade
Explanations
bob may execute the scripts script1 and
script2 inside Anne’s /home/anne/bin directory
(the former exclusively with the argument -n, the latter must
not be given any argument). Specifying args in the rule line
for the script2 without a following argument forces the file to
be called without an argument and thus without potentially malicious
code. bob must supply the username when calling
scripts, using the -u option.
bob@sidu:~$ doas -u anne /home/anne/bin/script1 -n
doas (bob@sidu) password:
bob@sidu:~$
The script was executed without comment after Bob entered his user password.
To allow Lisa to perform the system upgrade, she
should switch to multi-user.target (init 3) and perform a
systemctl reboot (init 6) after completion. The rule line
permit persist lisa as root cmd init
without specifying
args causes all other calls of init are allowd, except those
that are prohibited by the following rules below. Therefore, she cannot
go directly from the multi-user.target to the
graphical.target (init 5). Here we see the structure of a
hierarchy.
Notes
If you keep typing sudo, the line
alias sudo="doas"
in your .bashrc will help.
Doas plays its decisive advantage where only one user is granted root
rights by doas. The above example with Lisa shows how extensive
the configuration for a restricted rights assignment can become.
Furthermore, a rule for a program call with variable arguments
(e.g. apt install <package name>) is not possible.
Sources
man doas
man doas.conf
github, doas
DE:
LinuxNews, Linux Rechtemanagement, sudo durch doas ersetzen
DE:
LinuxUser 08.2021, Kleiner Bruder