Sudo without a setuid binary or SSH over a Unix socket

In a broad sense, this is the direction that Linux based systems are going. Specifically, replacing usages of setuid with sending commands to a process already running as root to execute on your behalf.

For instance, try running "systemctl stop sshd" as a non-root admin user. You will be prompted for a password, and ultimately able to do it; but no setuid binary is involved.

Instead, your command is sent to an already running daemon, which performs its own policy checks to see if you are allowed to proceed, before executing the action on your behalf.

At a glance, this sounds a lot like how setuid binaries work. The main difference is that setuid processes inherit a lot of state from the calling process. As a result, there have been a lot of attacks based on setting up the environment before calling a setuid program. The message passing approach removes that entire class of attacks.

In the case of a sudo replacement, you often want that state to pass through. However, a message passing sudo can still pass the state, and have the daemon set it when spawning the requested command. Since you can pass file descriptors between processes, you don't even need to take a performance hit (other than possibly increase overhead in the time before execution starts)

I'm intrigued by the idea, but I think this only replaces sudo, and set[ug]id is related but not identical?

What I am thinking of is that set[ug]id should already be superseded by capabilities(7). Now, I know CAP_SYS_ADMIN gets flak for being too overpowered and not being better than sudo. However, there are other capabilities which are sometimes sufficient. For example, slock used to require setuid, but now it is sufficent to add CAP_DAC_READ_SEARCH and CAP_SYS_RESOURCE to the generated binary.

So, as cool as the idea is, when it comes to setuid/setgid, I don't see what it gives me relative to capabilities.

The more interesting use case, from where I'm sitting, is that it makes it easy to use a yubikey for 2FA access to sudo, whereas until now I only heard about needing to muck around with PAM.

Edit: Ah, I just re-read the lede and I think I misunderstood what the article was going for. It's not talking about replacing set[ug]id in general, it's using the stigma of set[ug]id as a motivation for replacing sudo. That's probably not the way I would have chosen to motivate the technique, but I can also see that my above criticism was ill-premised.

I might be missing something but doesn't this give you net worse security, because it allows running any arbitrary command with zero confirmation or authentication.

Sudo by default requires users to authenticate with their own password to perform the action (with a grace period for multiple invocations in the same shell within a given timeframe)

This also seems like it would then allow those same users to ssh directly to root from a remote connection (ie consider users who ssh to their own account on a machine and need sudo on it; this then allows them to ssh straight to root)

I have been hankering for this kind of thing but for remote filesystem sharing. My specific use case is having separate NAS and compute machines in my homelab, and I have workloads running in nomad/k8s/docker-swarm/whatever on the compute machines, and I want the workloads to keep their state on the NAS.

NFS is this mire of needing users and groups to be the same everywhere (possibly also needing to configure some translation layer(s)). MacOS starts numbering users at 501, most linux distros I'm aware of start at uid 1000, and I don't know, can you even mount NFS on windows? Most of the guides I've seen completely punt on any kind of homelab authentication, just advising to squash all users to nobody and have everything on the share be 0777 or whatever completely open facl that equates to.

With NFS, you don't authenticate as a storage consumer directly to the remote storage, you authenticate as a user to the OS and it deals with the storage on your behalf, but this seems like a layering/concerns violation.

From what I can tell SMB is a bit better because your client authenticates directly to the SMB server, but I have never figured out all the Windows-specific identity, groups, ACLs, etc.

All of these are kind of heavyweight for certain use cases too -- it would be handy to have userspace remote filesystems available on microcontrollers, but I don't necessarily want to run a tiny linux on them.

But.. if clients could sign remote storage connection requests with private keys and then that lets them mount whatever storage is on the other end with FUSE or something similar for microcontrollers.. then access to remote storage is completely agnostic of operating system.

While I appreciate the idea, I think a purpose-built daemon would be significant improvement here. You could use SCM_CREDENTIALS with unix sockets for kernel-backed authentication, avoiding the complexities of key managment etc, and you could pass file-descriptors (stdin/out/err or tty) of the elevated child from the daemon to the caller, avoiding potentially expensive encryption and copying data. Of course there is also the benefit of needing far smaller code-base here, hopefully making things more robust

The original article has load-bearing typography in the title, which was lost when it was posted here.

dang, can you add some punctuation to change the title to "Sudo without a setuid binary; or, SSH over a Unix socket"?

I'm using a Yubikey for both sudo and ssh 2FA:

# /etc/pam.d/sudo

    auth      optional  pam_faildelay.so delay=5000000
    auth      [success=1 default=ignore] pam_yubico.so authfile=/home/user/auth_file id=16 
    session   required  pam_env.so readenv=1 user_readenv=0
    session   required  pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
    @include  common-auth
    @include  common-account
    @include  common-session-noninteractive

# /etc/pam.d/sshd

    auth     optional   pam_faildelay.so delay=5000000
    auth     requisite  pam_yubico.so authfile=/home/user/auth_file id=16 debug
    account  include    base-account
    auth     required   pam_env.so
    auth     required   pam_nologin.so successok

There's improper quoting in the `sudohost` function. You have to use either `printf %q` or `${var@Q}` to properly quote a variable or array into a single string (appending `@Q` is perhaps the only time `${*}` or `${arr[*]}` is safe to use). If you're using a deficient shell, you can badly implement `printf %q` via `sed` (but beware of newlines).

I'm skeptical that `cd` is a reasonable/sufficient thing to do given how many other parts of process environment get dropped, or for that matter that `SHELL` is ever a safe thing to reference.

***

Regarding the general advisability of this approach ... using normal `ssh root@remotehost` is strictly more secure than `ssh user@remotehost` and then using `sudo` (since it cuts the attack surface in half), contrary to the common FUD (which dates to a time when you couldn't expect people to use keys).

But this article's approach seems worse than `sudo` in at least some ways.

  doas

I’m surprised ‘doas’ has not been mentioned.

It’s essentially a safer version of sudo, created by the OpenBSD folks (and has ports for other OS).

https://man.openbsd.org/doas.1

This is also similar to how root used to work on Android devices. Since SElinux policies were enforced preventing the su binary from becoming root through setuid/setgid, a daemon used to start up at boot, and the su command was simply a proxy that connected to the daemon whenever called by an app.

However I wouldn’t call for the deprecation of setuid entirely: ping and traceroute still use them to set up raw sockets to send out IP data grams with custom values.

Having user-level credentials, whereby you talk to an already-running 'higher-level' process to give you another set of credentials reminds me of Plan 9's factotum(4):

* http://man.9front.org/4/factotum

* https://en.wikipedia.org/wiki/Factotum_(software)

* http://9p.io/sys/doc/auth.html

A bit Kerberos-like.

> I am of the opinion that setuid/setgid binaries are a UNIX legacy that should be deprecated.

Hmmm. I can agree with this pretty quickly at a superficial level. suid is extremely overused, however, I'm currently building a purpose-built container/sandbox runtime and I can't see how subordinate IDs (/etc/sub[ug]id) would work. Unless that portion of shadowutils was moved into the kernel? I can't see Linus being on board with that at all.

Some sort of ACL for which users a user+process is allowed to become might be useful, but that's what shadowutils is (mostly) doing anyway.

I like the idea in theory. Even in the presence of SELinux and on UNIXes as far back as SunOS, I've always felt uncomfortable with setgid and setsid binaries and would like to mount all the things nosuid. Also, a general complaint is that sudo is far too configurable.

The danger though is being locked out on alternative init systems or those that can't run su because there's no root password or the root password is unavailable.

This is neat. I recently needed to run host/docker commands within a container (an automated test framework that I was deploying via container for simplicity) and struggled to think of a way to do it at first, until realizing that I could of course just SSH to localhost . I’ll have to dig through this to clean up my setup.

Just wanted to share my blog post about why I think sudo is broken: https://cedwards.xyz/sudo-is-broken/

Oh I thought you can operate a Linux box after deleting the sudo binary. I was confused to see the author trying to "sudo systemctl daemon-reload"

In really this is just systemd running root and spawn a managed child process `sshd` and allows a unix socket connection with a shell tty attached to it.

All this seems like overcomplecated engineering? Can we just simply spawn child shell from a root process instead? How about we give it alias and call it.... wait for it ... sudo ?