HyperWiki

Differences

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

Link to this comparison view

Next revision 		Previous revision
en:philosophy:sudo_complexity [2022/03/26 20:13]
i3_relativism create first draft for this page 		en:philosophy:sudo_complexity [2022/11/03 14:08] (current)
throgh [Solution with a strict and lightweight replacement]
Line 1: Line 1:
-doas - dedicated openbsd application subexecutor +====== The complexity of "sudo" ======
-Three days of the doas.+
  
-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. +