sudo / doas / sudoless

From Kicksecure
< Dev
Jump to navigation Jump to search

sudo replacement development considerations - doas / sudoless

Changes[edit]

List[edit]

kicksecure/desktop-config-dist/etc/sudoers.d/desktop-config-dist[edit]

  • doas:
    • Should be translatable to doas. nopasswd exceptions for specific commands with specific argument sets, for specific users and groups.
      • %sudo ALL=NOPASSWD: /bin/lsblk --noheadings --raw --output RO
    • Translates to:
      • permit nopass :sudo cmd /bin/lsblk args --noheadings --raw --output RO
  • sudoless:
    • A systemd unit running as root (with limited capabilities as future hardening) would gather the information and write it into a file. The desktop systray the would no longer need to run lsblk itself.

kicksecure/live-config-dist/etc/sudoers.d/live-config-dist[edit]

  • doas:
    • More commands with nopasswd exceptions.
  • sudoless:
    • TODO: Unclear. Perhaps the ISO should be booted into admin mode by default?

kicksecure/sdwdate/etc/sudoers.d/sdwdate[edit]

  • doas:
    • This one's a problem. Whereas the previous files provide nopasswd exceptions to specific users and groups, this file allows *anyone* to run /usr/sbin/sdwdate-clock-jump as root. doas lacks the ability to express a universal exception such as this, you can only grant exceptions to specific users or groups. The only files that actually attempt to use sdwdate-clock-jump via sudo are:
      • kicksecure/sdwdate-gui/usr/lib/python3/dist-packages/sdwdate_gui/sdwdate_gui.py
      • kicksecure/sdwdate-gui/usr/lib/python3/dist-packages/sdwdate_gui/sdwdate_gui_qubes.py
      • kicksecure/sdwdate-gui/etc/qubes-rpc/whonix.GatewayCommand
    • It's likely that all of these can be coped with by using doas's configuration by simply determining the users or groups these run as, and adding them to the configuration file. Adding the users group to the config would also be advisable as Debian's adduser tool will automatically add new "standard" user accounts to this group. Unfortunately useradd doesn't do this, but the end-user can probably resolve this themselves if they so choose.
      • ALL ALL=NOPASSWD: /usr/sbin/sdwdate-clock-jump
    • Translates roughly to:
      • permit nopass :users cmd /usr/sbin/sdwdate-clock-jump
  • sudoless:
    • Use capabilities?
    • OR don't allow user to set the clock? Tell users to boot into admin mode instead?

kicksecure/sdwdate-gui/etc/sudoers.d/sdwdate-gui[edit]

  • doas:
    • User-specific nopasswd exceptions for specific commands. Easy to translate.
  • sudoless:
    • Same as above.

kicksecure/security-misc/etc/sudoers.d/security-misc[edit]

  • doas:
    • One user-specific and one group-specific nopasswd exception, easily translatable.
  • sudoless:
    • Could be re-implemented using a .done file and systemd unit files.

kicksecure/setup-dist/etc/sudoers.d/setup-dist[edit]

  • doas:
    • Simple group-specific nopasswd exception, easily translatable.
  • sudoless:
    • setup-dist does not do much anymore anyhow. The done file could be moved to user home location.

kicksecure/systemcheck/etc/sudoers.d/systemcheck[edit]

  • doas:
    • Complex, but looks doable. Many user-specific nopasswd exceptions, however some of these are targeted to allow the user to execute a command as another user *other than root*. Thankfully doas supports this.
      • user ALL=(sdwdate) NOPASSWD: /usr/libexec/helper-scripts/onion-time-pre-script
    • Translates to:
      • permit nopass user as sdwdate cmd /usr/libexec/helper-scripts/onion-time-pre-script
  • sudoless:
    • Only user "admin" would be able to run systemcheck.

kicksecure/tb-starter/etc/sudoers.d/tb-starter[edit]

  • doas:
    • A user-specific nopasswd exception with some environment variable allowances. Can be handled using techniques mentioned earlier.
  • sudoless:
    • Could be re-implemented using systemd unit files and/or Debian maintainer scripts.

kicksecure/tb-updater/etc/sudoers.d/tpo-downloader[edit]

  • doas:
    • More user- and group-specific nopasswd exceptions. Easily translatable.
  • sudoless:
    • Same as above.

kicksecure/usability-misc/etc/sudoers.d/upgrade-passwordless[edit]

  • doas:
    • Group-specific nopasswd exception, easily translatable.
  • sudoless:
    • Only user admin should be able to run upgrade-nonroot.

whonix/anon-gw-anonymizer-config/etc/sudoers.d/anonymizer-config-gateway[edit]

  • doas:
    • More user-specific nopasswd exceptions. Easily translatable.
  • sudoless:
    • Whonix issue only. Not a Kicksecure issue. Perhaps Whonix-Gateway could always boot into admin mode or not have user/admin mode split package (yet to be named) installed by default.

/etc/sudoers.d/qt_x11_no_mitshm[edit]

  • doas:
    • Specifies an environment variable to be preserved that affects all utilities on the system that leverage Qt. Depending on how exactly this rule is used, this could be trivial to translate, or it could be slightly tricky.
      • Defaults env_keep += "QT_X11_NO_MITSHM"
    • Translates to (roughly):
      • permit setenv { QT_X11_NO_MITSHM } :sudo
  • sudoless:
    • Only user "admin".

/etc/sudoers.d/qubes[edit]

  • doas:
    • This looks like a generic account-wide nopasswd exception for the qubes group. There's some SELinux stuff going on with it that can't be ported, but since Kicksecure is based on Debian, I don't expect this to be a problem (I don't believe SELinux is even *used* in Whonix or other Debian-based Qubes).
  • sudoless:
    • Not an issue since also not an issue for doas.

/etc/sudoers.d/qubes-input-trigger[edit]

  • doas:
    • Contains several NOPASSWD exceptions for starting various Qubes input-related services as root. There are four sets of nine services each, each set is handled by one line of sudoers config, which covers all nine services with the help of a regex match. We don't get regex matching in doas, so this would have to be replaced with 36 lines of doas configuration. Not great, but not horrible.
      • user ALL=(root) NOPASSWD:/bin/systemctl --no-block start qubes-input-sender-keyboard@event[0-9].service
    • Translates to:
      • permit nopass user as root cmd /bin/systemctl args --no-block start qubes-input-sender-keyboard@event0.service, plus eight more lines with event1.service, event2.service, etc.
  • sudoless:
    • TODO

/etc/sudoers.d/umask[edit]

  • doas:
    • Trouble. This one changes umask settings for sudo commands in general. doas handles umask configuration entirely on its own and does not allow the end-user to configure it. Thus this cannot be translated. Depending on what doas's umask settings are and how vital this configuration is, this may or may not be a blocker.
  • sudoless:
    • TODO

pkexec[edit]

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/sudo&oldid=89228"