Move sudo to community

Summary

At present, sudo is in the main repository, which requires us to provide security support for 2 years. Upstream sudo does not provide an "LTS" lifecycle, so this requires either performing security upgrades during the maintenance lifecycle, or backporting security fixes by hand.

Benefit to Alpine

Prior to the creation of the security team, there was an unofficial preference to push doas as the preferred pivot tool for Alpine. This reinforces that messaging.

Additionally, we do not have to support sudo for a 2 year lifecycle, since there are no LTS branches for it.

Contingency Plan

If there is a problem with implementing this plan, we will move sudo back to main from community, but no such problem is expected.

Documentation

This will need to be documented in the release notes. We should recommend doas as the preferred pivot tool, noting that sudo is available in community if explicitly wanted.

Owners

@kdaudt and @kaniini will implement this change on behalf of @team/security.

Timeline

We would like to implement this change within the next few weeks, with TSC approval.

@jirutka notes that nagios-plugins-openrc package in main depends on sudo. This was not picked up by ap due to being in a subpackage.

We may need to add some functionality to doas in order to compensate.

I suggest (and if nobody else volunteers can do) to create a wiki page prior to 3.15 release titled "Sudo in Alpine Linux" explaining the situation, to explain users how to manage with doas instead.

There’s already an issue/feature-request for this in OpenDoas: #61. Adding support for “include” into OpenDoas to allow modular configuration as sudo does, so package or configuration management can add/remove rules simply by adding/removing a file into/from /etc/doas.d/, would allow me to finally replace sudo with doas.

I'm ok with the change - and I like Jakub's suggestion as well

In case upstream rejects the /etc/doas.d/ idea, we could have an update-doas-conf trigger that monitors /etc/doas.d/:

#!/bin/sh
set -e

new=/etc/doas.conf.new
echo "# Generated by update-doas-conf. DO NOT EDIT" > "$new"
for i in /etc/doas.d/*.conf; do
    if [ -r "$i" ]; then
        printf "%s\n%s\n\n" "# imported from $i" "$(cat $new)" >> "$new"
    fi
done
chmod 440 "$new"
mv "$new" /etc/doas.conf

You mean package trigger? That would work just for config snippets installed by APK packages, not by any third-party configuration management system.

they would need to add the files to /etc/doas.d/ and then make sure that update-doas-conf runs one way or the other.

I am not sure if we want to endorse an unoffical port of doas as the "preferred pivot tool for alpine". See my post on the ML for details.

Thanks for your response, these are valid concerns!

I personally don’t care whether it’s official or unofficial port, as long as it’s maintained by someone competent who can be trusted. However, I don’t have enough information nor expertise to evaluate this.

OpenDoas is just about 2,500 LoC including the portability layer, so it should be feasible to do a security audit of the code, right? I think that we have people who may be capable of doing that, @skarnet, @kaniini, …?

refers to their optional persist implementation as "new and potentially dangerous"

That timestamp-based persist implementation is inspired by sudo and well described, so it shouldn’t be too hard to evaluate whether the described approach is correct.

…there is just a possibly for vulnerabilities to occur in the portability layer of OpenDoas. In my view OpenDoas actually deviates quite heavily from the original OpenBSD doas codebase which is why I am personally still using sudo.

Well, there’s always a possibility of vulnerabilities and the probability grows with lines of code. Keep in mind that we are comparing it with sudo, about 14,500 LoC if I don’t count bundled libs and plugins and horrifying 147,000 LoC if I count everything! And this record of CVEs…

Speaking with security hat on: after reviewing the design and implementation, I can say that the timestamp implementation is reasonably secure.

I understand the concerns @nmeum has raised, albeit that even if OpenDoas deviates from openBSD doas, it is simpler, and more secure due to its fairly small codebase, which is a big plus on my book.

Thanks for the vote of confidence, @jirutka, but I don't want to be involved in anything that has to do with OpenBSD code. It is way too much maintenance effort.

If I were to be involved in this, it would be to build a sudo replacement with the tools I already have and that are already in Alpine: s6-ipcserver and s6-sudod. All s6 is missing to provide a proper suidless sudo replacement is three pieces:

• A utility that checks that the current uid/gid is authorized to run a given command, with a configuration found in the environment. That's quite easy to write.
• A trivial sudo shim.
• A parser for sudo-like configuration files that would convert them into an access rules file for s6-ipcserver, so the filtering for unauthorized users can be performed as early as possible. That's the annoying part and the reason why I haven't bothered so far.

Thanks for your answer! I’m not asking you to maintain OpenDoas, just read the code and tell your opinion, if the code and assumptions inside it looks correct and is written with security-in-mind, or not so much.

I trust your code and expertise, but the problem with s6-* is that it’s like that object-programming metaphor: “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” In this case, banana is a small sudo alternative, gorilla is s6 supervision suite and jungle is skalibs. Don’t get me wrong, that’s just my feeling I always had when I’ve been considering using some of the small utilities from s6 collection of tools.

I think you will find that there is no such thing as a "small sudo alternative". To perform the same thing sudo does without suid programs, you need:

• a daemon running with the privileges of your target user (typically root)
• credentials passing over a Unix domain socket
• stdin/stdout/stderr, argv and envp transmission over that socket as well
• client access control and rejection via credentials checking
• stdin/stdout/stderr, argv and envp transmission over that socket as well which is exactly what s6-ipcserver + s6-ipcserver-access + s6-sudod provide; you're not getting any useless code here.

Now, if you're talking about dependencies, this is a subject we have discussed several times, with lengthy explanations from me, and that I have no wish to discuss further if, as it appears, you are still under the delusion that my software uses more resources than other software doing the same thing would.

To perform the same thing sudo does without suid programs

As I know, there’s no requirement to avoid using suid. As you explained, it would greatly increase complexity of the solution, so I’m really not sure if it’s worth it.

you are still under the delusion that my software uses more resources than other software doing the same thing would.

No, not at all, this never was my concern! My concern is just about number of dependencies and their size (in LoC which correlates with binary size). I understand that you don’t wanna discuss it here, neither I want. I just wanted to explain why I’m personally not so thrilled in replacing sudo with s6-*.

(BTW, there are two ways how to reply to a comment – adding a standalone comment or adding a comment in the thread under the comment you’re responding to. It’s more clear to use the second option.)

I actually like the idea of using a daemon to mediate the privilege escalation but think that writing something domain-specific makes more sense. @nmeum seems to agree based on talks in IRC.

If we want depend on a daemon, why not just use sshd?

Well, we could do it that way. But it would need to be integrated outside the normal ssh setup I think.

Does this mean moving cloud-init and the rest too?

https://pkgs.alpinelinux.org/package/edge/main/x86_64/sudo

added agenda:proposal label

added type:system-change label

added agenda:scheduled label and removed agenda:proposal label

The TSC voted to move forward with @ncopa's proposal to use doas as the default privilege escalation tool, with update-doas-conf.

Regarding cloud-init, this was not brought up, but previous discussion with the cloud-init maintainer indicated that he is willing to write a doas plugin for it.

sudo is not to be moved into community until both of these issues are resolved.

I’m disappointed, update-doas-conf is just a hacky workaround, not a real solution. Why have you rejected downstream patch to doas implementing support for /etc/doas.d/*? It’s no so complicated to implement, is it?

Do you have a patch for that? Are you willing to work with upstream (OpenBSD) to create a such patch? If upstream rejects the idea, are you willing to maintain such a patch downstream?

The options we have are:

• keep sudo and back port security fixes (this is not realistic since we are not able to fix the oldest stable and sudo does not provide long time support)
• keep sudo, and strictly follow the version of sudo that ubuntu LTS/debian uses, so we can re-use there back ported patches for sudo.
• move sudo to community and use some alternative:
  • write own implementation from scratch
  • fork doas and maintain missing functionality
  • use doas, with update-doas-conf

The lowest hanging fruit here was the update-doas-conf and it also solves the problem with /etc/doas.conf being write protected. If it isn't doas refuses to run. So to modify doas.conf you need to manually copy it, edit it, verify it, adjust the permissions and copy it back. The update-doas-conf would set the permissions after new config has been verified.

It would also solve the problem with packages in main depending on sudo.

The only downside would be that 3rd party tools that adds stuff to /etc/doas.d/ would need to manually run update-doas-conf. It might be a good idea to verify the config before pushing it for production anyway.

But then again, if you are willing to create and maintain a patch for doas, we will be willing to reconsider.

For what it's worth, Duncaen is open to having a patch in opendoas. I am willing to write it, if we can agree on how -C should work. But I think that update-doas-conf approach is cleaner.

added agenda:follow-up label and removed agenda:scheduled label

mentioned in merge request alpine-conf!24 (merged)

mentioned in commit aports@0d85d8f3

mentioned in issue aports#12972 (closed)

Current status: doas supports configuration directories in edge. We are just waiting on cloud-init before we can move sudo to community.

Doas support was added to cloud-init in 21.3-r1.

We are just waiting on cloud-init before we can move sudo to community.

This wasn't actually relevant as cloud-init is in community, not main.

mentioned in commit kdaudt/aports@4403a4cf

mentioned in merge request aports!27605 (merged)

@HRio suggested on IRC to wait with moving sudo to community in 3.15, and first give the opportunity for users to migrate to doas (which will just have been added to main in 3.15).

I'm open to this suggestion, as we give users a clear migration path, rather than having to fix it immediately (sudo has not been removed yet, aports!27605 (merged)).

The downside is that we have to support sudo in main for 6 more months (3.12, 3.13, 3.14, 3.15). Anyone opposed to this idea?

mentioned in commit kdaudt/aports@4afb3be6

changed title from 3.15: Move sudo to community to Move sudo to community

I think this is a great idea and proper process - deprecating, giving one more release for moving on.

mentioned in commit kdaudt/aports@06b07360

The move has been completed with aports!27605 (merged)

closed

mentioned in issue aports#14930