Strong agree that sudo is dogma, and logging in as root is just fine, actually.
I think @fanf is even more right about this than he claims.
For single-user workstations, who cares about administrative access. The only real security boundary is the TPM/SEP. really(8) without any further authentication would be just fine.
The flip side is that I don't actually care about sudo's complexity or security, because it's not protecting a security boundary I care about.
@filippo@fanf I wonder if ssh might help to fill the niche of allowing users to permit other users to run specific command(s). A potential bonus is that it can be network transparent (or not).
@fanf@filippo I wonder what a bit of tooling might accomplish if it’s properly considered. ssh-copy-id is super convenient for an entirely different purpose.
What if Linux installers could put a forced command for certain typical operations (apt update/upgrade) and keypair you could copy to different accounts local or remote?
@filippo@fanf I sort of care about administrative access on my single-user workstations because I really don't want to spent all my time being one errant typo away from deleting /usr/bin. (Or having a makefile be etc etc.)
@filippo@fanf I actually want the forced tty interaction, because that makes it very hard for random scripts/Makefiles/etc to put in 'really ...' and surprise me in a very unpleasant way.
(Based on sudo logs at (university CS department) work, with our population of postdocs, graduate students, etc fetching and using random research software, there is clearly a lot of instructions and possibly scripts that already use sudo this way.)
@cks@fanf I mean, replace really(8) with a bash script that does a TTY confirm read and then calls really(8). It’s still not justifying the existence of sudo as a complex ACL based tool with reauth capabilities.
@filippo@fanf I worked at one place where we had individual accounts on the servers, but they all had uid 0. It seemed to work ok, but I'm not sure I'd repeat such an unconventional setup without thinking about it more.
@filippo@fanf That's why for example alpine linux by default only provides "su" but not "sudo". And that's basically the same as "login as root".
However I'd like to push back on "the only real security boundary is the TPM/SEP" that's not true, you forget about dropping privileges (nobody/nogroup), sandboxing, and namespacing which esp. web browsers heavily rely on.
@agowa338@fanf Fair, sandboxing is also a real security boundary, but it needs to be a carefully constructed one, not just "make a non-root user that can still see all the filesystem and execute all the SUID binaries" which is what sudo protects.
@filippo@fanf True, but at that point TPM/SEP aren't necessarily security boundaries either. Everything can be bypassed if you use it incorrectly of if it has a security flaw. ;-)
@filippo@fanf Well, which CPU do you have? Either you've a very old one or a very recent one with latest microcode update. Everything in between is vulnerable to at least one hardware flaw that would expose these secrets. Also you forget that I could just wait for you to use it and copy it then. I doubt you went the extra mile to have it stay within the TPM and not just one in ram that gets decrypted by the TPM...
(edit: also if you didn't generate it within the TPM it's exportable...)
@agowa338@fanf Most microarchitectural vulns compromised SGX-like systems, not discrete TPMs, and I am not aware of any SEP extraction… ever? Same for YubiKeys.
I also very much mean keys that live in the TPM/SEP, not in memory wrapping. Check out age-plugin-yubikey and Secretive.
Add comment