101–110 of 114 posts
Earlier quoted context omitted.
> And since the sshd approach doesn't allow you to restrict root access to only certain commands [...] The ForcedCommand infrastructure.
There's also a command argument that can be provided in the authorized keys setup, which can force connections with a particular key to hit an entry-point application.
One of the issues with ssh is that spawning processes isn't part of the protocol. And it's a remote protocol, so it can't pass local resources to the child. So you can't pass a null-separated array of arguments, pass extra file descriptors or specify an executable. Instead it just passes a string to a server-configured shell. So you need to shell-escape things and know which shell is running on the server side. To us…
There's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it's *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user's UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).
One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways.
My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…
Personally I use etckeeper[0] to make sure all changes to /etc are tracked, either by software installs / upgrades, or done by humans. It's also great when needing to upgrade a machine to a newer release as you can create a patch file with all your local changes and apply that patch to a clean install and do a three way merge that will highlight all conflicts and keep you up to date and any changes required from one…
If you're going to set a root password, you might as well just do this and if I'm not mistaken it accomplishes everything you want
alias sudo="su -c"Earlier quoted context omitted.
If you could configure your linux kernel without suid support, that would be huge benefit for security, IMO. suid feature is huge security hole. Whether fighting one particular suid binary worth it, is questionable indeed. But this is good direction. Another modern approach to this problem is run0 from systemd.
> IMO. suid feature is huge security hole. As opposed to running background processes as root...? This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.
When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control.
Libraries rarely treat data from socket as "trusted" but often blindly trust environment variables, or stdin/stdout/stderr.
Am I missing something? How is logging into ssh (sshd) AS root more secure than using sudo? I honestly don’t even know how dangerous that is because I’ve always been told to never allow it. I see here thought goes into preventing that for a remote user, so I’m not talking about that aspect of security here. Maybe it has to do with #3 in the sudo limitations — I certainly don’t see any benefits vis-a-vis #1. I totally…
The sudo binary is suid root / privileged and is exposed directly to the untrusted user. If anything goes wrong inside of sudo (with the user's entire environment as the surface area), it may be exploited. The ssh approach does not expose a suid binary. Instead it uses the ssh network layer so it is no less secure than accessing ssh over a network, which is considered pretty secure.
To be clear, I love SSH and we even run a userify instance to distribute keys, but juts comparatively the surface area of the ssh daemon alone is greater than sudo alone.
(however, even with the extra complexity, you might trust the history of portable OpenSSH more than sudo, and that's a good, but different, conversation to have also.)
Earlier quoted context omitted.
The sudo binary is suid root / privileged and is exposed directly to the untrusted user. If anything goes wrong inside of sudo (with the user's entire environment as the surface area), it may be exploited. The ssh approach does not expose a suid binary. Instead it uses the ssh network layer so it is no less secure than accessing ssh over a network, which is considered pretty secure.
This premise is incorrect: SSH doesn't need to be an suid binary because it's already running as root, and then SSH creates a new environment for the user, exactly like sudo does, but with all the added complexity and overhead (and surface) of privileged network access. To be clear, I love SSH and we even run a userify instance to distribute keys, but juts comparatively the surface area of the ssh daemon alone is gre…
Earlier quoted context omitted.
Maybe also make /usr/bin/sudo immutable? would that help prevent a package manager from messing with it? I think so.
The downside of this is that if you have your system set up to automatically install package updates, then it will start failing, which might kill all automatic updates. On Debian, for example, I have unattended-upgrades set up to automatically install security updates. sudo is reasonably likely to have updates for security reasons.
https://wiki.debian.org/DebianAlternatives
https://www.debian.org/doc/debian-policy/ap-pkg-diversions.h...
Earlier quoted context omitted.
> IMO. suid feature is huge security hole. As opposed to running background processes as root...? This is just mindless dogma at this point. You're going to need something to elevate permissions, and setuid is as good of a scheme as any. ssh or run0 are not magic and just as "vulnerable" as setuid or anything else. Any of these schemes are "security holes" if you abuse it.
The argument is, that in case of sudo, the caller (potential attacker) controls the environment. In many cases, software or libraries are not made with a hostile environment in mind. Think of LD_PRELOAD or PATH ... When there's a daemon running in the background, the attack surface is more commonly understood. The environment is not under attacker control. Libraries rarely treat data from socket as "trusted" but ofte…
sudo etc. already clear much of the environment. And you're going to want to keep some of it because people expect "sudo foo" to work (which you can't do without PATH).