I'm struggling to understand any situation where you should ever be typing either your LUKS password or your root password into a fully operating/running system.
If you're using sudo correctly, you do not enter your root password. Frankly, the only time I can remember being prompted for a root password in years is when the system has failed to boot and offers entry to a recovery/maintenance shell.
If you're using LUKS correctly for your boot drive, you enter it only during startup before the system has booted.
If someone has access to your disk and has your LUKS key, the root password is merely a formality.
You are entirely correct and it is too bad I did not delete my comment in time. Here I am with an intense dislike of bogus criticism on HN and yet perpetuating some. Sleep before you post...
You can't erase remote logs, or logs written to a write-only logging device (the one's I've seen seem essentially to be a serial port/usb device that emulates a line printer).
What I found problematic (unless I'm missing something) was the suggestion that your day-to-day user should be in the wheel group: if that's the case, once your user is compromised the attacker can edit .bashrc to change $PATH and use a patched sudo to take over the machine.
IMHO "sudo" (or "doas") should be used from a different user, by switching to a different VT. Or at least only allowing certain commands for you day to day user.
You don't need wheel to modify your terminal environment, $PATH or .bashrc. If your user account is compromised, your user account is compromised. Anything else is lipstick.
And I agree that the typical sudoers config that allows opening terminals as root isn't a good idea.
What I prefer lately is using a yubikey neo to ssh access a root shell. You can configure sudo and authorized_keys to allow directly opening a root shell and you never enter any passwords anywhere except the pin to unlock the yubikey's openpgp applet. The yubikey will lock the key after six unsuccessful pin attemps and you can just yank the key out when it's not being used.
Now all I need is some sort of phone app that reaches out to me on a side-channel to pops up asking me to authorize each login (something like libpam-askmeonmyphone)--(I really like the way the Microsoft Account 2FA phone app works in this regard). If I could change one thing about the yubikey neo, it's that I'd require it to make me physically interact with it to decrypt anything (beyond entering the PIN).
You misread my post, what I meant was that your day-to-day account is vulnerable, since you run your applications with it. If that's the account belonging to wheel, once your user account is compromised the attacker is root as well. One should use a different account, hopefully harder to compromise since is used only for sudo.
That said, I like your use of yubikeys, even better than the phone that's the sort of stuff that should be triggered using a smartwatch.
Basically, this is a GNU vs BSD misunderstanding. On BSD, only wheel members can use su to become root after entering the root password. On GNU/linux anyone can su to root by entering the root password regardless of whether they belong to wheel or not.[0]
The confusion with respect to these guidelines is because some BSD-inspired GNU/linux distributions confugure their sudo to use a "wheel" group.
> once your user account is compromised the attacker is root as well
... but only if they also know the root password.
Anyway, the long and short of it is that on GNU/Linux, wheel is only relevant on distributions that use wheel in their default sudo config.
Right, I kept using "wheel" to mantain the terminology in the github page, but clearly this created confusion.
But my point was that, regardless of whether you use sudo or su, on GNU/Linux or on *BSD, if the account used to elevate priviledges is compromised, the next you elevate you priviledges you should expect the attacker to follow you.
This is what I meant by "the attacker is root as well": it's just a matter of waiting for the next time you use su or sudo.
sudo'ing as your day-to-day user is dangerous for another reason, too: the default 15 minute password timeout lets subprocesses in your shell use your sudo credentials, even if you didn't intend them to. e.g. sudo command, then later ./some-installer.sh - you didn't want to give some-installer.sh root, but it opportunistically uses 'sudo' and succeeds.
(I disable credential caching with "Defaults timestamp_timeout=0" in /etc/sudoers.)
Sure, it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done. See also the fact that OSX ships with tty_tickets disabled.
Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.
it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done
That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every command reminds them they're acting as root.
If you advocate for only using sudo as a different way to authenticate for a root shell that's cool and all (I often use it like that too), but you're going to run into a disagreement around the nature of sudo.
Sure, although I never found that reason to hold much ground given that in reality most distros ship with accounts that can open a shell (instead of having a list of allowed commands) and have the timeout not set to zero, so any security benefit that would come from not using "sudo -s" is pretty much voided.
And I'm skeptical that having users type sudo a bunch of time when they add a PPA and install a program somehow results in greater awareness, but this is purely an opinion of mine.
The other big reason for using sudo is the ability to change policy wrt which users can be root without changing root password everytime, and that clearly is true.
When you have multiple commands to run, chances are that only some of them require root privilege. Prefixing only those with `sudo` instead of executing all of them in a root shell allows you to reduce damage, should the "normal" commands are typed wrong or have bugs.
> That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every command reminds them they're acting as root.
I do not think that is accurate. As I remember it, sudo gained popularity because it provided better control over access to the "root password" for teams of administrative staff. sudo was lightyears easier and provided much more fine-grained control than figuring out how to design POXIX groups.
1) A mechanism to provide better control over access to root privileges where administrative access must be shared between multiple users.
2) An auditing mechanism to record both operations completed as the root user, as well as failed attempts to perform operations as root (usually authentication failures).
3) A way to remind the user that commands are running as root, as well as a way to avoid accidentally running commands as root, since you're never (without "sudo -i" or "sudo -s" or similar) at an actual root shell.
If you're using "sudo -i"/"sudo -s" all the time, you don't lose anything for #1, and losing #3 is mostly just an inconvenience (it's an extra layer of protection, but it's not even really foolproof even with sudo). Losing #2 (auditing) can be a big deal, though, because, if everything's happening at a root shell (rather than via the sudo command), you lose the audit log that traces what's being done at root. Gaps like that in audit logs should be an indicator that something bad might've happened, but you can't make that assumption if you're routinely doing it yourself, too.
Sudo is more often than not a security risk. If a program is not made to run as root it is usually because it would give too much power to a user (ie sudo mount is supid).
Add that to not having a root password and you have a single (weaker) point of failure (wheel group).
If you're using sudo correctly, you do not enter your root password. Frankly, the only time I can remember being prompted for a root password in years is when the system has failed to boot and offers entry to a recovery/maintenance shell.
If you're using LUKS correctly for your boot drive, you enter it only during startup before the system has booted.
If someone has access to your disk and has your LUKS key, the root password is merely a formality.