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:system:userspace:open_doas [2023/02/20 21:28]
rachad [Opendoas] 		en:system:userspace:open_doas [2023/02/22 20:29] (current)
throgh [External resources]
Line 8: Line 8:
   * the **super** user.   * the **super** user.
   * and **regular** users.    * and **regular** users. 
-OpenBSD **doas** and **opendoas**, while still respecting this principals, don't give the [[https://en.wikipedia.org/wiki/Superuser|super user]] power **all the time**, think of the **concentration of power** and the **responsibility** that would entail. Given usually we only need **super user** powers to perform a **single** task. Doas still like [[en:philosophy:sudo_complexity|sudo]] command, allows for [[https://en.wikipedia.org/wiki/Principle_of_least_privilege|subdivision of super user privileges]], while taking a diferent approach, by **keeping things simple** and only granting them such power when doing **specific tasks**.+**opendoas**, while still respecting this principals, don't give the [[https://en.wikipedia.org/wiki/Superuser|super user]] power **all the time**, think of the **concentration of power** and the **responsibility** that would entail. Given usually we only need **super user** powers to perform a **single** task. Doas still like [[en:philosophy:sudo_complexity|sudo]] command, allows for [[https://en.wikipedia.org/wiki/Principle_of_least_privilege|subdivision of super user privileges]], while taking a different approach, by **keeping things simple** and only granting them such power when doing **specific tasks**.
  
 ===== Installation ===== ===== Installation =====
Line 24: Line 24:
 The [[https://www.hyperbola.info/packages/core/x86_64/opendoas|doas]] command can be used like **sudo**: The [[https://www.hyperbola.info/packages/core/x86_64/opendoas|doas]] command can be used like **sudo**:
  
-To begin using ''doas'' as a non-privileged user, it must be properly configured. See [[#Configuration]].+To begin using <color #620BB9/#EEDDFF>/etc/doas</color> as a **non-privileged user**, it must be properly configured. See [[#Configuration]].
  
-To use ''doas'', simply prefix a command and its arguments with **doas** and a space:+To use **doas**, simply prefix the command with it and its related arguments with a space in between:
  
 <code bash> <code bash>
Line 52: Line 52:
 </note> </note>
  
-The general syntax form of <color #620BB9/#EEDDFF>/etc/doas.conf</color> is:+The general syntax form of its rules is:
  
 <code bash> <code bash>
Line 61: Line 61:
 The configuration file must end with a newline The configuration file must end with a newline
 </note> </note>
 +
 +For example, to allow members of the <color #620BB9/#EEDDFF>libre</color> group to run **smartctl** without password as **Root user**.
 +
 +Edit <color #620BB9/#EEDDFF>/etc/doas.conf</color>:
 +
 +<code bash>
 +permit nopass :libre as root cmd /usr/bin/smartctl
 +</code>
 ==== Basic setup ==== ==== Basic setup ====
  
-To allow members of group //wheel// to run commands as other users, create a configuration file with the following content, at <color #620BB9/#EEDDFF>/etc/doas.conf</color>:+In config file, to allow members of group //wheel// to run commands as other users, create a configuration file with the following content:
  
 <code bash> <code bash>
Line 85: Line 93:
 It is imperative that <color #620BB9/#EEDDFF>/etc/doas.conf</color> is free of syntax errors! It is imperative that <color #620BB9/#EEDDFF>/etc/doas.conf</color> is free of syntax errors!
 </note> </note>
- 
-To allow members of the <color #620BB9/#EEDDFF>plugdev</color> group to run **smartctl** without password as **Root user**: 
- 
-Edit <color #620BB9/#EEDDFF>/etc/doas.conf</color>: 
- 
-<code bash> 
-permit nopass :plugdev as root cmd /usr/bin/smartctl 
-</code> 
- 
-WIP??!question 
-what is smartctl is this systemd related? 
-endWIP??! 
 ==== Rulesets ==== ==== Rulesets ====
  
 The [[|doas]] tool allows the creation of rules which only apply to certain commands. The [[|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//+A rule can be specified to allow a certain user to use a command only available to //root//.
  
 In <color #620BB9/#EEDDFF>/etc/doas.conf</color>. Allow a user to use the **reboot** command without a password: In <color #620BB9/#EEDDFF>/etc/doas.conf</color>. Allow a user to use the **reboot** command without a password:
Line 119: Line 115:
 </code> </code>
  
-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:+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.
  
 Deny a user to execute a command, in <color #620BB9/#EEDDFF>/etc/doas.conf</color>: Deny a user to execute a command, in <color #620BB9/#EEDDFF>/etc/doas.conf</color>:
Line 136: Line 132:
 If there’s **no configuration** file at all, doas will instead exit after printing a message that it is **not enabled**. If there’s **no configuration** file at all, doas will instead exit after printing a message that it is **not enabled**.
  
-The simplest useful configuration probably looks more like this.+The simplest useful configuration probably looks more like this:
  
 <code bash> <code bash>
Line 159: Line 155:
 Adding the **<color #816E00/#FAE65B>nopass</color>** keyword to a rule means the user is **always permitted** to run the command without entering a password. We’ve seen this above in the rule for //root//. The user is already //root//, so they can do anything they like and there’s no reason to require a password. Adding the **<color #816E00/#FAE65B>nopass</color>** keyword to a rule means the user is **always permitted** to run the command without entering a password. We’ve seen this above in the rule for //root//. The user is already //root//, so they can do anything they like and there’s no reason to require a password.
  
-By adding the **<color #816E00/#FAE65B>persist</color>** keyword, <color #620BB9/#EEDDFF>doas</color> will remember that the user authenticated previously and not require further confirmation for a **timeout of five minutes**.+By adding the **<color #816E00/#FAE65B>persist</color>** keyword, <color #620BB9/#EEDDFF>doas</color> will remember that the user authenticated previously and not require further confirmation for a **timeout of five minutes**:
  
 <code bash> <code bash>
Line 171: Line 167:
 </note> </note>
  
-If you have multiple shell logins to a machine, each login will require authentication. Additionally, the authentication information includes the parent shell process ID. This means that executing <color #620BB9/#EEDDFF>doas</color> again in a shell script will require authentication. Or, to repeat that another way, if you run a script or program of uncertain quality, it **won’t** be able to **silently elevate privileges**. (That’s the theory anyway. In practice the check leaves quite some wiggle room.)+If you have multiple shell logins to a machine, each login will require authentication. Additionally, the authentication information includes the parent shell process ID. This means that executing <color #620BB9/#EEDDFF>doas</color> again in a shell script will require authentication. Or, to repeat that another way, if you run a script or program of uncertain quality, it **won’t** be able to **silently elevate privileges**. (That’s the theory anyway. In practice the check leaves quite some wiggle room.):
  
 <code bash> <code bash>
Line 188: Line 184:
 There are two config keywords related to environment, **<color #816E00/#FAE65B>keepenv</color>** and **<color #816E00/#FAE65B>setenv</color>**. The first is very simple. We’ve seen it before, in the rule for //root// above. **<color #816E00/#FAE65B>keepenv</color>** simply means that the entire environment should be retained and **passed as is** to the executed command. This is a convenient shortcut for trusted users. There are two config keywords related to environment, **<color #816E00/#FAE65B>keepenv</color>** and **<color #816E00/#FAE65B>setenv</color>**. The first is very simple. We’ve seen it before, in the rule for //root// above. **<color #816E00/#FAE65B>keepenv</color>** simply means that the entire environment should be retained and **passed as is** to the executed command. This is a convenient shortcut for trusted users.
  
-Using **<color #816E00/#FAE65B>setenv</color>** is a little more complicated, because it allows a combination of adding, modifying, and deleting environment variables. Let’s look at an example.+Using **<color #816E00/#FAE65B>setenv</color>** is a little more complicated, because it allows a combination of adding, modifying, and deleting environment variables. Let’s look at an example:
  
 <code bash> <code bash>
Line 200: Line 196:
 Each rule in <color #620BB9/#EEDDFF>doas.conf</color> applies to an **individual or group**, specified after **<color #816E00/#FAE65B>permit</color>** and any options. There’s no keyword to distinguish between users and groups. Instead, syntax similar to **chown** is used, with user names by themselves or :group names with a leading colon. Now is a good time for a reminder that rules are always evaluated in order with the last matching rule winning. Specific user rules are not automatically preferred over group rules unless they come later in the file. Each rule in <color #620BB9/#EEDDFF>doas.conf</color> applies to an **individual or group**, specified after **<color #816E00/#FAE65B>permit</color>** and any options. There’s no keyword to distinguish between users and groups. Instead, syntax similar to **chown** is used, with user names by themselves or :group names with a leading colon. Now is a good time for a reminder that rules are always evaluated in order with the last matching rule winning. Specific user rules are not automatically preferred over group rules unless they come later in the file.
  
-In most situations, <color #620BB9/#EEDDFF>doas</color> is used to run commands as //root//. This requires no additional syntax. However, we may also wish to restrict some rules to targeting certain users.+In most situations, <color #620BB9/#EEDDFF>doas</color> is used to run commands as //root//. This requires no additional syntax. However, we may also wish to restrict some rules to targeting certain users:
  
 <code bash> <code bash>
Line 210: Line 206:
 === Commands === === Commands ===
  
-We’re nearing the end of our tour of the <color #620BB9/#EEDDFF>doas.conf</color> syntax. **doas** can also be restricted so that rules only apply for certain commands, or even certain commands with particular arguments.+We’re nearing the end of our tour of the <color #620BB9/#EEDDFF>doas.conf</color> syntax. **doas** can also be restricted so that rules only apply for certain commands, or even certain commands with particular arguments:
  
 <code bash> <code bash>
-permit nopass :operator cmd reboot+permit nopass :libre cmd reboot
 </code> </code>
  
-Normally, reboot requires //root// privileges. It is instead executed indirectly by the setuid program **shutdown**, whose execution is restricted to the operator group. The above rule allows these users to run **reboot** directly. However, operators won’t be able to run other commands as //root// or obtain a shell.+Normally, reboot requires //root// privileges. It is instead executed indirectly by the setuid program **shutdown**, whose execution is restricted to the libre group. The above rule allows these users to run **reboot** directly. However, libre's won’t be able to run other commands as //root// or obtain a shell:
  
 <code bash> <code bash>
Line 226: Line 222:
 In both of these examples, the **cmd** was specified with only the base name. In these cases, <color #620BB9/#EEDDFF>doas</color> will restrict itself to only executing commands in the system <color #620BB9/#EEDDFF>PATH</color> (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin). //alice// won’t be able to install a **sh binary** in his home directory and set <color #620BB9/#EEDDFF>PATH</color> to <color #620BB9/#EEDDFF>~/bin</color> to subvert our intentions. Absolute pathnames can also be specified, however the user will also be required to type them out in full. In both of these examples, the **cmd** was specified with only the base name. In these cases, <color #620BB9/#EEDDFF>doas</color> will restrict itself to only executing commands in the system <color #620BB9/#EEDDFF>PATH</color> (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin). //alice// won’t be able to install a **sh binary** in his home directory and set <color #620BB9/#EEDDFF>PATH</color> to <color #620BB9/#EEDDFF>~/bin</color> to subvert our intentions. Absolute pathnames can also be specified, however the user will also be required to type them out in full.
  
-Any command arguments specified must be specified in their entirety.+Any command arguments specified must be specified in their entirety:
  
 <code bash> <code bash>
Line 235: Line 231:
 These two rules will allow //alice// to turn the wifi interface on and off, but not change any of its other parameters. These two rules will allow //alice// to turn the wifi interface on and off, but not change any of its other parameters.
  
-Some userland utilities that gather information from the kernel only present a restricted subset of information when as regular users. To see the full information requires running as //root//. For example, **fstat** will only print minimal information about unix domain sockets.+Some userland utilities that gather information from the kernel only present a restricted subset of information when as regular users. To see the full information requires running as //root//. For example, **fstat** will only print minimal information about unix domain sockets:
  
 <code bash> <code bash>
Line 245: Line 241:
 </code> </code>
  
-But when run again as //root//, we see much more information.+But when run again as //root//, we see much more information:
  
 <code bash> <code bash>
Line 256: Line 252:
  
 <note tip> <note tip>
-This allows us to match these sockets up with the process on the other end.+This allows us to match these sockets up with the process on the other end:
  
 <code bash> <code bash>
Line 265: Line 261:
 </note> </note>
  
-These kernel addresses are normally hidden because they reveal information about the kernel’s memory layout which can be used to facilitate exploits, but if we trust //bob//,  then we can change this with a simple config rule.+These kernel addresses are normally hidden because they reveal information about the kernel’s memory layout which can be used to facilitate exploits, but if we trust //bob//,  then we can change this with a simple config rule:
  
 <code bash> <code bash>
Line 275: Line 271:
 === deny === === deny ===
  
-In contrast to all the **<color #816E00/#FAE65B>permit</color>** rules we’ve seen so far, it’s also possible to create a **<color #816E00/#FAE65B>deny</color>** rule that specifically denies command execution. This feature is most useful as a **safeguard** against **accidental typos** by trusted operators. It **should not** be used as a **security feature** because an exhaustive blacklist is exhausting to create. Better to craft a **ruleset** that doesn’t grant **unintentional privileges**.+In contrast to all the **<color #816E00/#FAE65B>permit</color>** rules we’ve seen so far, it’s also possible to create a **<color #816E00/#FAE65B>deny</color>** rule that specifically denies command execution. This feature is most useful as a **safeguard** against **accidental typos** by trusted libre's. It **should not** be used as a **security feature** because an exhaustive blacklist is exhausting to create. Better to craft a **ruleset** that doesn’t grant **unintentional privileges**:
  
 <code bash> <code bash>
Line 288: Line 284:
 The **doas** command itself has a few options. The **doas** command itself has a few options.
  
-Since we just finished looking at the config file syntax, the <color #620BB9/#EEDDFF>-C</color> option can be used to syntax check a new file before installing. It also permits checking the result of rule set evaluation for a given command and arguments without actually running the command. Continuing with the **fstat** example from earlier, we can check that only the command with arguments is matched.+Since we just finished looking at the config file syntax, the <color #620BB9/#EEDDFF>-C</color> option can be used to syntax check a new file before installing. It also permits checking the result of rule set evaluation for a given command and arguments without actually running the command. Continuing with the **fstat** example from earlier, we can check that only the command with arguments is matched:
  
 <code bash> <code bash>
Line 298: Line 294:
  
 When writing possibly noninteractive scripts that incorporate **doas**, the <color #620BB9/#EEDDFF>-n</color> option is helpful to prevent future failures. Only **<color #816E00/#FAE65B>nopass</color>** rules will successfully execute. Any rule that requires a password will instead immediately fail. This includes any rules with the **<color #816E00/#FAE65B>persist</color>** keyword, regardless of whether the user recently authorized. When writing possibly noninteractive scripts that incorporate **doas**, the <color #620BB9/#EEDDFF>-n</color> option is helpful to prevent future failures. Only **<color #816E00/#FAE65B>nopass</color>** rules will successfully execute. Any rule that requires a password will instead immediately fail. This includes any rules with the **<color #816E00/#FAE65B>persist</color>** keyword, regardless of whether the user recently authorized.
-thanks 
  
 ==== Authentication ==== ==== Authentication ====
 +=== Nopass feature ===
  
-The **<color #816E00/#FAE65B>nopass</color>** keyword provides the ability to perform actions without having to enter a password:+The **<color #816E00/#FAE65B>nopass</color>** keyword provides the ability to perform actions without having to enter a password.
  
 Edit <color #620BB9/#EEDDFF>/etc/doas.conf</color>, to allow all users in the //wheel// group to perform actions as //root// without authentication: Edit <color #620BB9/#EEDDFF>/etc/doas.conf</color>, to allow all users in the //wheel// group to perform actions as //root// without authentication:
Line 310: Line 306:
 </code> </code>
  
-<note warning> +=== Persist feature ===
-Due to OpenBSD-specific kernel API required by **doas** to set and clear timeouts, the **<color #816E00/#FAE65B>persist</color>** feature is disabled by default in the ''OpenDoas'' port. +
-</note>+
  
-With the **<color #816E00/#FAE65B>persist</color>** keyword **doas** can remember an authenticated user and will not require confirmation by password for **five minutes**:+**doas** provides the <color #620BB9/#EEDDFF>persist</color> feature: after the user successfully authenticates. There will be presistance and an authenticated user, will be remember, and not be prompted or a password will not require be required confirmation for **five minutes** . It is disabled by default, enable it with the **<color #816E00/#FAE65B>persist</color>** option.
  
-Edit  <color #620BB9/#EEDDFF>/etc/doas.conf</color>, to not require passwords for five minutes for all users in the //wheel//+Edit  <color #620BB9/#EEDDFF>/etc/doas.conf</color>, to not require passwords for five minutes for all users in the //wheel//:
  
 <code bash> <code bash>
Line 322: Line 316:
 </code> </code>
  
 +<note warning>
 +Due to OpenBSD-specific kernel API required by **doas** to set and clear timeouts, the **<color #816E00/#FAE65B>persist</color>** feature is disabled by default in the ''OpenDoas'' port, and because it is new and potentially dangerous. In the original ''doas'', a kernel API is used to set and clear timeouts. This API is OpenBSD specific and no similar API is available on other operating systems. As a workaround, the **<color #816E00/#FAE65B>persist</color>** feature is implemented using timestamp files similar to ''sudo''.
 +</note>
 ==== Testing ==== ==== Testing ====
  
Line 350: Line 347:
 The **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 //wheel//) and users (like //larry//) is a leading colon.  The **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 //wheel//) and users (like //larry//) is a leading colon. 
  
-Edit <color #620BB9/#EEDDFF>/etc/doas.conf</color>, to allow a user to perform actions as another user|1=+Edit <color #620BB9/#EEDDFF>/etc/doas.conf</color>, to allow a user to perform actions as another user:
  
 <code bash> <code bash>
Line 358: Line 355:
 By adding this rule, the user //larry// is allowed to perform actions as the //postgres// user without having to enter a password. By adding this rule, the user //larry// is allowed to perform actions as the //postgres// user without having to enter a password.
  
-==== Bash tab completion ====+===== Bash tab completion =====
  
-By default 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 WIP.bashrc, or the global /etc/bash.bashrc:+By default 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 .bashrc, or the global /etc/bash.bashrc:
  
 <code bash> <code bash>
Line 366: Line 363:
 </code> </code>
  
-===== Tips and tricks ===== 
- 
-==== doas persist feature ==== 
- 
-''doas'' provides a "persist" feature: after the user successfully authenticates, they will not be prompted for a password again for some time. It is disabled by default, enable it with the **<color #816E00/#FAE65B>persist</color>** option in <color #620BB9/#EEDDFF>/etc/doas.conf</color>: 
- 
-<code bash> 
-permit persist :wheel 
-</code> 
- 
-<note> 
-The **<color #816E00/#FAE65B>persist</color>** feature is disabled by default and because it is new and potentially dangerous. In the original ''doas'', a kernel API is used to set and clear timeouts. This API is OpenBSD specific and no similar API is available on other operating systems. As a workaround, the **<color #816E00/#FAE65B>persist</color>** feature is implemented using timestamp files similar to ''sudo''. 
-</note> 
  
-==== Smooth transition sudo to doas ====+===== Smooth transition sudo to doas =====
  
 For a smooth transition from ''sudo'' to ''doas'' and to stay downward compatible, you could add to your environment: For a smooth transition from ''sudo'' to ''doas'' and to stay downward compatible, you could add to your environment:
Line 406: Line 390:
 </note> </note>
  
-==== See also ====+===== See also =====
  
   * See also [[en:philosophy:sudo_complexity|sudo]].   * See also [[en:philosophy:sudo_complexity|sudo]].
Line 414: Line 398:
 ==== External resources ==== ==== External resources ====
  
-WIP 
 "It would not have been possible to finish doas without the support of many other OpenBSD developers and users. In particular, Vadim Zhukov contributed immensely to the config parser and regress testsuite; Todd Miller, Damien Miller, and Martijn van Duren provided ideas and inspiration; Theo de Raadt provided backup to rejecting feature requests; Henning Brauer gave me the idea for tying authorization persistence to the terminal; and I owe Michael Lucas for stealing a catchy title." "It would not have been possible to finish doas without the support of many other OpenBSD developers and users. In particular, Vadim Zhukov contributed immensely to the config parser and regress testsuite; Todd Miller, Damien Miller, and Martijn van Duren provided ideas and inspiration; Theo de Raadt provided backup to rejecting feature requests; Henning Brauer gave me the idea for tying authorization persistence to the terminal; and I owe Michael Lucas for stealing a catchy title."