sudo / doas / sudoless / privleap

From Kicksecure
< Dev
Jump to navigation Jump to search

Info This page is archived.

sudo replacement development considerations - doas / sudoless / privleap

This has been implemented. Past notes.

Introduction[edit]

See also No Access to Privilege Escalation Tools for Limited Accounts.

Changes[edit]

goals[edit]

  • sudoless

non-goals[edit]

  • doas

List[edit]

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

  • doas:
    • More commands with nopasswd exceptions.
  • sudoless:
    • start calamares only in sysmaint (form sysmaint-panel) or in unrestricted admin mode
  • Status
    • Implemented.

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 sysmaint mode instead?
    • With privleap, port to privleap and keep all functionality.
  • Status
    • In progress, using privleap-based solution.

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

  • doas:
    • User-specific nopasswd exceptions for specific commands. Easy to translate.
  • sudoless:
    • Same as above.
  • Status
    • In progress, using privleap-based solution.

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.
  • Status
    • No longer needs done, the only sudoers config left here is actually just umask config stuff.

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.
  • Status
    • In progress, using privleap-based solution.

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 sysmaint would be able to run systemcheck.
  • Status
    • In progress. Requires changes to setup-dist and setup-wizard-dist to properly implement.

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.
  • Status
    • In progress, using privleap-based solution.

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

  • doas:
    • More user- and group-specific nopasswd exceptions. Easily translatable.
  • sudoless:
    • Same as above.
  • Status
    • In progress, using privleap-based solution.

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

  • doas:
    • Group-specific nopasswd exception, easily translatable.
  • sudoless:
    • Only sysmaint should be able to run upgrade-nonroot.
  • Status
    • In progress.

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. Whonix-Gateway could always boot into unrestricted admin mode?
    • We want to support sudoless on Whonix-Gateway, so this probably should be dealt with.
  • Status
    • In progress, using privleap-based solution.

/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 "sysmaint".
    • Alternatively, could introduce support for setting environment variables universally in all executables run by privleap?
  • Status
    • Needs discussion.

/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:

/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:
    • Not a problem, because umask is inherited from privleapd which has a "normal" umask, while umask for user user remains locked down.

pkexec[edit]

  • sudoless:
    • List of affected applications summarized from https://forums.whonix.org/t/cannot-use-pkexec/8129archive.org iconarchive.today icon already:
      • gdebi -> use sysmaint
      • synaptic -> use sysmaint
      • partition manager -> use sysmaint
      • xfce auto mounter -> TODO
    • Only sysmaint should be able to use pkexec?
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=93024"