That was about security vs customization. Also that was a really abstract questions. If users really understand what’s at stake, they might decide otherwise.
This is not so much customization. This is more about security vs inconvenience.
This is more about security vs stability / bad surprises. Upgrade → cannot use “sudo” anymore. Terminal-only users couldn’t even run “sudo reboot”.
Maybe. Well, Whonix / Kicksecure don’t come with openssh-server installed by default. OpenSSH root login allowed by default or not setting doesn’t change much. Should change anyhow? How? Modify files in /etc/ssh
? There is no configuration snippet drop-in folder (“.d
”). Seems really intrusive → dpkg interactive conflict resolution dialog
( Configuration Files - Kicksecure )
Users who have openssh-server installed and then install security-misc or some other package are a different case.
We had a case we didn’t foresee a case where a user got locked out from his own server: Is security-misc suitable for hardening bridges and relays? - #4 by minimal
We’re already locking su
. (Restrict root access)
Some users don’t use sudo
. Maybe we should tell them they should. Maybe sane to require that.
Now we’re considering to remove user user
from group sudo
through an upgrade.
I am not saying we shouldn’t do it. Just thinking it all through aloud.
How much security would we gain from that anyhow? Let’s assume most times users boot into user user
with sudo disabled. Ok… Let’s say their user account gets comprised through a remote exploit. That malware would have a harder time to break out since no easy escalation to root level, kernel level. Let’s say the malware starts itself through ~/.bashsrc or any of the many dotfiles. Then the user wants to upgrade and reboots in sudo=1
mode. The user now enters its user user
password and gains root rights by using sudo. Boom. Malware can hijack that / sniff the password and become root too. We don’t get that much security from that?
How do we prevent that? Rely on VirusForget? 1) doesn’t exist. 2) not sure it will be finished 3) not that great, might be holes, not sure yet.
Instead, I am re-thinking about the old idea of user admin
as per this very post: Restrict root access - #14 by Patrick.
Yes, once the plan is getting more specific, this will be a good idea. (Specifically if going the user admin
route.)