HyperWiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
en:philosophy:sudo_complexity [2022/03/26 20:19]
i3_relativism 		en:philosophy:sudo_complexity [2022/11/03 14:08] (current)
throgh [Solution with a strict and lightweight replacement]
Line 1: Line 1:
-===== +====== The complexity of "sudo" ======
  
-I started working on doas quite some time ago after some personal issues with the default sudo config. The “safe environment” was under constant revision and I regularly found myself unable to run pkg_add or build a flavored port or whatever because the expected variables were being excised from the environment. If I had been paying attention, keeping sudoers up to date probably would not have been such an ordeal, but I don’t like change.+Starting with the release of Milky Way v0.3 we have been using foremost <color #620BB9/#EEDDFF>opendoas</color> as direct replacement for using administrative rights with an unprivileged user-account. With the release of Milky Way v0.4 we have therefore now concluded this step as <color #620BB9/#EEDDFF>opendoas</color> is for sure in our perspective the better way instead to stay on top for <color #620BB9/#EEDDFF>sudo</color>.
  
-The core of the problem was really that some people like to use sudo to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. Some people (me) like to use sudo to get a root shell without remembering two passwords. And so there was considerable tension trying to ship a default config that would mostly work with the second group, but not be too permissive for the first group.+===== Introduction and basic problem =====
  
-Writing a small simple replacement meant that we could ship something in base which was totally unsuitable for the power sysadmin group. It could only work for me, and I would be happy. Meanwhile, those who truly needed all the flexibility of sudo would install it from ports, and they would be happy.+The program <color #620BB9/#EEDDFF>sudo</color> (sometimes also referred as shortened version for **S**uper-**u**ser **do**)  is designed to let some users executing commands as root (or another user). The basic philosophy is to give as few privileges as possible but still allow people to get their administrative tasks in relation towards the basic system done. The major issues is nevertheless the complexity within <color #620BB9/#EEDDFF>sudo</color> as program itself.
  
-The code was just sitting around in a spare source tree for a while because any “like this, but different” software release immediately results in a flood of email. “It’s different!” And despite my reasoning above, I seemed to be the only person actually unhappy with the situation, so there was no motivation to add the necessary polish to reach minimal replacement level.+Documented reports like [[https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3156|CVE-2021-3156]] show the reasoning for an alternative: The escalation of root-privileges being for about 10 years not directly discovered because of the basic code-complexity.
  
-Talking with deraadt and millert, however, I wasn’t quite alone. There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough. (As shipped in OpenBSD, the compiled sudo was already five times larger than just about any other setuid program.) Hurray, tension. It wasn’t the problem I was trying to solve, but it was an opening from which to launch my diabolical plan.+There are furthermore issues reported with the default <color #620BB9/#EEDDFF>sudo</color> config. The “safe environment” is under constant revision and regularly unable to run pkg_add or build a flavored port, because the expected variables were being excised from the environment. Even when sudoers is keept up to date probably would not have been such an ordeal, but constant software change, creates major security loopholes. So the core of the problem was and is that people like to use <color #620BB9/#EEDDFF>sudo</color> to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. People are therefore invited to use <color #620BB9/#EEDDFF>sudo</color> to get a root shell without remembering two passwords. And so there is a considerable tension trying to ship a default config that would mostly work with the second group, but not be too permissive for the first group.
  
-First, doas needed a new name because nobody ever likes the first name. A few suggestions were made. sux (already taken by su, now with more X. machtfrei (too many letters). powershell (if only). datass (submitted after contest end).+===== Solution with a strict and lightweight replacement =====
  
-In to cvs it went as doas. Incidentally, doas appears to be an alternative (mis)spelling for duas, but the initial commit was a few days late for Laylat al-Qadr. +Using <color #620BB9/#EEDDFF>opendoas</color> as static replacement for administrative privileges was a first priority for Hyperbola as lightweight defined system. Intended as a minimalist replacement for <color #620BB9/#EEDDFF>sudo</color>, providing "95% of the features of <color #620BB9/#EEDDFF>sudo</color> with a fraction of the codebase", improving security. It is a port of the OpenBSD command by the same name. It also has a much simpler configuration format, simplifying also the setup in general.
- +
-And then the real hacking and chopping could begin. I always thought the most important feature of sudo was that it insulted the user after entering a bad password. Apparently the world is filled with poor typists; the first diff to doas was to add a config option noinsults. Unfortunately, this was a poor compromise that complicated the grammar and required further documentation, so the feature was dropped entirely. There was also another proposal to change the error message from “Permission denied” to “Sorry” to match su, but not implemented. doas will not apologize for your failures. +
- +
-Deleting a dozen lines of insults made space for one new feature. A simple -s option is almost compatible with sudo if muscle memory proves too difficult to overcome. +
- +
-The config file syntax is crudely inspired by pf.conf. Instead of pass and block keywords, there are permit and deny keywords. There are some limitations. Trying to deny a single command can be tricky because “ksh” and “/bin/ksh” and “///bin/ksh” are all interpreted differently. Don’t do that. My instinct was that adding deny as a means to counteract permit was a natural idiom; certainly that’s how pf works. In retrospect though, a default pass ruleset already is the default, while permit default is certainly not. The keyword should perhaps be escalate. Phrasing it as trying to remove escalation after granting it makes the potential danger more clear. +
- +
-We’ve been contemplating a different config syntax which reverses the ordering of user and command. Instead of a user focused approach, specify the command first, then the set of permitted users. It should be equivalent in expression, but perhaps the reversed order would encourage users to think about minimal permission grants. I’m not entirely convinced, but I would like it to be at least as natural to express a secure, limited config as a convenient, permissive config. +
- +
-Coming full circle, the majority of tweaking and polishing of doas now appears to have returned to refinement of the good environment list and the bad environment list. I have built the thing I hate. At least it’s small. +
- +
-The doas code lives in cvs. +
- +
-doas was created to run on OpenBSD. I suppose you could port it, but I don’t plan to. Figuring out a replacement for auth_userokay is probably the hard part. +
- +
- +
- +
- +
-The '''doas''' command [[Article description::provides a way to perform commands as another user.]] It aims to be a a simplified and lightweight replacement for {{c|[[Sudo|sudo]]}}. The {{c|doas}} tool was originally written for [https://www.openbsd.org/ OpenBSD] by Ted Unangst. ''OpenDoas'' is a port of {{c|doas}} for Linux, which is available as the {{Package|app-admin/doas}} package. +
- +
-== Installation == +
- +
-=== USE flags === +
- +
-{{USEflag|package=app-admin/doas}} +
- +
-=== Emerge === +
- +
-{{Emerge|app-admin/doas}} +
- +
-== Configuration == +
- +
-The {{c|doas}} tool is configured by the ruleset specified in {{Path|/etc/doas.conf}}. By using an empty configuration file the default ruleset will be applied which denies all actions. +
- +
-=== Basic configuration === +
- +
-A simple skeleton configuration could be to specify a rule which allows all users in the {{c|wheel}} group to perform any action as root. +
- +
-{{FileBox|filename=/etc/doas.conf|title=Allow all users in the {{c|wheel}} group to execute any command as root|1= +
-permit :wheel +
-}} +
- +
-It's also possible to deny certain actions to specified users. The ruleset is evaluated in a hierarchical manner, thus adding a new rule can override the previous one: +
- +
-{{FileBox|filename=/etc/doas.conf|title=Deny a user to execute a command|1= +
-permit :wheel +
-deny larry cmd fdisk +
-}} +
- +
-The user {{c|larry}} is part of the {{c|wheel}} group and therefore may perform actions available to root, but the second rule denies this user access to the {{c|fdisk}} command. +
- +
-=== Authentication === +
- +
-The {{c|nopass}} keyword provides the ability to perform actions without having to enter a password: +
- +
-{{FileBox|filename=/etc/doas.conf|title=Allow all users in the {{c|wheel}} group to perform actions as root without authentication|1= +
-permit nopass :wheel +
-}} +
- +
-{{Note|Due to OpenBSD-specific kernel API required by {{c|doas}} to set and clear timeouts, the persist feature is disabled by default in the ''OpenDoas'' port.}} +
- +
-With the {{c|persist}} keyword {{c|doas}} can remember an authenticated user and will not require confirmation by password for five minutes: +
- +
-{{FileBox|filename=/etc/doas.conf|title=Do not require passwords for five minutes for all users in the {{c|wheel}} group|1= +
-permit persist :wheel +
-}} +
- +
-=== Commands === +
- +
-The {{c|doas}} tool allows the creation of rules which only apply to certain commands. +
- +
-A rule can be specified to allow a certain user to use a command only available to root: +
- +
-{{FileBox|filename=/etc/doas.conf|title=Allow a user to use the {{c|reboot}} command without a password|1= +
-permit nopass larry cmd reboot +
-}} +
- +
-This allows the user {{c|larry}} to execute the {{c|reboot}} command without having to enter a password. This may allow users to use restricted commands without providing complete root access. +
- +
-=== Testing === +
- +
-A configuration file can be tested as follows: +
- +
-{{Cmd|doas -C /etc/doas.conf}} +
- +
-Specifying a command will show you whether you have permissions to perform this command: +
- +
-{{Cmd|doas -C /etc/doas.conf cat}} +
- +
-This test will output {{c|deny}} if you do not have the permissions to execute {{c|cat}}. +
- +
-You can also check permissions for a specified user: +
- +
-{{Cmd|doas -C /etc/doas.conf cat -u larry}} +
- +
-If the user {{c|larry}} has permissions to access {{c|cat}} it may output {{c|permit}}. +
- +
-=== Targets === +
- +
-The {{c|doas}} can not only be used to perform actions with root privileges, it also allows to target certain users and groups. The syntax to distinguish between groups (like {{c|:wheel}}) and users (like {{c|larry}}) is a leading colon.  +
- +
-{{FileBox|filename=/etc/doas.conf|title=Allow a user to perform actions as another user|1= +
-permit nopass larry as postgres +
-}} +
- +
-By adding this rule, the user {{c|larry}} is allowed to perform actions as the {{c|postgres}} user without having to enter a password. +
- +
-=== Bash tab completion === +
- +
-By default {{c|bash}} will only tab complete files and directories within the current or referenced directory. To tell bash to complete arguments as if they were separate commands (also leveraging the tab completion settings of other commands) the following can be added to either the users {{Path|.bashrc}}, or the global {{Path|/etc/bashrc}}. +
- +
-{{FileBox|filename=~/.bashrc|title=Configure tab completion|lang=bash|1= +
-# Configure completion for doas +
-# -c : Complete arguments as if they were commands +
-#     (eg: `doas emer<tab>` -> `doas emerge`) +
-#     (eg: `doas dd status=p<tab>` -> `doas dd status=progress`) +
-# -f : Complete arguments as if they were directory names (default behaviour) +
-#     (eg: `doas /bi<tab>` -> `doas /bin/`) +
-complete -cf doas +
-}} +
- +
-== Usage == +
- +
-The {{c|doas}} command can be used like {{c|sudo}}: +
- +
-{{Cmd|doas emerge -uDN world}} +
- +
-See [https://man.openbsd.org/doas doas(1)] for more information. +
- +
-== See also == +
- +
-* {{See also|sudo}} +
- +
-== External resources == +
- +
-* [https://man.openbsd.org/doas.conf.5 doas configuration file man page] +
- +
-[[Category:Software]]+