Supportng DOAS

[rafaelm7o]

User story

OpenBSD uses doas by default. Add support for using doas to run commands.

Describe the solution you would like

Use the SUDO implementation as the basis for DOAS, except for the password option, since DOAS doesn't support it
I've been enabling DOAS support, and it works. The files I have modified or added are:

Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: bin/rex
modified: lib/Rex.pm
modified: lib/Rex/CLI.pm
modified: lib/Rex/Commands.pm
modified: lib/Rex/Commands/Run.pm
modified: lib/Rex/Group/Entry/Server.pm
modified: lib/Rex/Interface/Connection/Base.pm
modified: lib/Rex/Interface/Connection/Local.pm
new file: lib/Rex/Interface/Exec/Doas.pm
new file: lib/Rex/Interface/File/Doas.pm
new file: lib/Rex/Interface/Fs/Doas.pm
modified: lib/Rex/Interface/Shell/Base.pm
modified: share/rex-tab-completion.zsh
modified: t/0.31.t

Additional context

No response

[ferki]

Thanks for starting this discussion, @rafaelm7o, and sharing an initial approach in the draft PR!

doas serves as the default OpenBSD way of privilege escalation, so I agree with the idea to find a way to teach Rex to use it. The list of modified files indicates you’ve already found the right neighbourhood for it in the codebase 👍

Dumping my brain below for transparency and posterity as I go through the details. Not as decisions yet, more like thinking out loud, noting important bits and recording any questions.

1. Current sudo approach hardcodes a specific tool, instead of serving the wider underlying principle of privilege escalation. I would like to think through how a second escalation method fits best, preferably without mirroring a tool-specific approach.

2. Previous similar discussions halted due to doas lacking a way to pass passwords. Ideas included using Expect to detect prompts, or using connection-dependent STDIN piping, though nobody decided to pick that up. Supporting only passwordless doas seems like an acceptable first step. This likely means a different mechanic would fit doas better than what a “sudo-except-password” approach might lead us to.

3. Forking the sudo interface into a parallel doas interface essentially doubles maintenance now, and sets up a path to linear growth when others decide to support further privilege escalation methods in the future. I feel concerned about inflating the public interface, as that sounds especially expensive to consolidate later. The modified file list and the draft PR seem to show this already, so let’s compare alternatives before we set it in stone.

Overall, what I wonder the most about a long-term maintenance perspective: would a single pluggable privilege escalation interface mean less total work than two parallel interfaces? 🤔

I often find it a good exercise to check how other similar projects approach the same challenge to collect inspiration and alternatives. For example Ansible opted for a pluggable become approach. Let’s collect our options before reinventing something we may reuse.

[rafaelm7o]

Great idea! enabling a modular approach for this would be really useful!
I did some brief research into how other projects handle privilege escalation:
Ansible (per task):

- name: Install package
  become: true
  become_method: sudo
  become_user: root

or globally

[privilege_escalation]
become = True
become_method = doas
become_ask_pass = False

Reference: https://docs.ansible.com/projects/ansible/latest/plugins/become.html

Puppet Bolt (in the config file):

targets:
  - uri: server.example.com
    config:
      ssh:
        user: deploy
        run-as: root
        run-as-command:
          - doas
          - -n
          - -u

Reference: https://help.puppet.com/bolt/current/topics/privilege_escalation.htm

Salt SSH (only supports sudo):

web1:
  host: server.example.com
  user: deploy
  sudo: true
  sudo_user: root

Reference: https://docs.saltproject.io/en/3006/topics/ssh/roster.html

Others, like Chef and Puppet, use identity switching, which I consider a completely different approach

[ferki]

Thanks for collecting those examples, @rafaelm7o!

To summarize our main findings from our previous chat:

1. Current sudo approach feels rigid and hard to generalize/extend (as the initial exploration on the draft PR suggests)
2. We suspect we can get better results sooner through a new extensible interface for privilege escalation (new means we do not have to entrench any historical baggage, and extensible means allowing external plugins add privilege escalation methods)

The initial expected major todo items we collected to enable a decision:

1. write call summary, only neutral facts about what we talked about (FErki)
2. write initial use case from above, focusing on minimal form we identified here, and just hinting at possible futures as non-essential-but-inspiring-points (FErki)
3. check other projects approach (Rafael)

And then for an implementation:

4. compare our options, choose one by defining the target interface
5. create an issue about the now-accepted work item to invest into along with acceptance criteria
6. implement on a reference PR (interface tests, interface code, then the doas plugin)

We initially envisioned such sample code to inspire/explore alternatives as an interface we aim for:

use Rex -feature => qw[1.4 exec_autodie];

# global syntax sugar
sudo TRUE;
become TRUE;
become_method 'sudo';

# config interface
Rex::Config->become(1);
Rex::Config->become_method('doas');

# sample usage
task 'test', sub {
    # direct run
    run 'whoami';

    # run with sudo/doas 
    sudo 'whoami';
    doas 'whoami';

    # unified run
    become('whoami');
    become(
        cmd  => 'whoami',
        user => 'another',
    );

    # alternative
    run_privileged(…);
};

The most of the above covers the convenience sugar syntax around privilege escalation, and not the core feature itself. Therefore I took a closer look of what a minimal initial implementation could target. That means the least amount of changes needed to lay the foundations for a better integrated privilee escalation mechanism.

First, I found this for running commands (and not Fs/File/similar management yet), which may help others as a workaround today:

sub doas {
  my $command = shift; # optionally accept a user argument too
  run "doas -n $command";
};

task 'test', sub {
  doas 'whoami';
};

Then I realized that the built-in run from Rex::Commands::Run already takes many parameters (see run docs). So I currently would vote for on this as an initial idea to explore:

run $command,
  privileges_with => 'doas'; # or sudo

We can grow that interface later for other options around privilege escalation:

run $command,
  privileges_with => 'doas'; # or sudo
  # as_user => 'root', # optional in truly minimal approach, though we likely need to handle a user parameter in general
  # privilege_password => $pass; # optional for current doas target, though we likely need to handle a password for privilege escalation

Alternatively as a single option bundle for all privilege escalation:

run $command,
  run_as => {
    user => 'root',
    with => 'doas'
    pass => $password,
  };

It looks like enough initial examples to consider, though feel free to add more into the pool of ideas, so we can get further inspired about how such an interface could look like.

Just to make sure this is now here to give us enough options and ideas for a decision, not the decision itself yet.

What do you folks think: which one feels the most natural to write? What do I miss as an alternative syntax? Can we make it even simpler as a first experiment?

[rafaelm7o]

I like the idea of extending run() rather than introducing a separate command just for privilege escalation

Since run() already accepts options, I'd gravitate around a single privilege parameter supporting both a short form and an explicit one:

run 'id', privilege => 'doas';

run 'id',
    privilege => {
        method => 'sudo',
        user   => 'root',
    };

This keeps a common case without limiting us if we need additional config later

I would still favor a small backend interface for sudo, doas and other, so the execution logic doesn't need to know the details of each mechanism

Since run accepts options such as only_if, unless and others; one thing worth deciding early is how these interact.