[Question] Debian sudoers and user best practice
Hi everyone π
TLDR
How do you work with debian and su permission and what's the best way to do it for better security?
- Add an user in the sudoers?
- Give special permissions to a group? User?
- Always connect to su - (default root)?
- Add users to groups?
The story is unrelated to the question, but is a direct cause
This is rookie question even though I use linux (ubuntu and recently debian) regularly and have alot of selfhosted docker containers on an old spare laptop.
While this is probably one of the basics you need to know right away when playing arround with sudo or su I wasn't aware of how you can f#ck everything up with a single command
chmod -R xxx /home/$USER
chown -R ...
Why would you do that? Because I'm stupid and how sometimes no idea what I'm doin? I was actually trying to change some permission to create a samba share (that's another story xD).
Trying to revert everything, alot of my docker containers, certificates and special files were unreadable, unexecutable... That broke my nextcloud instance, synchthing functionalities, linkding http shortcut...
With that big incident, I learned how users, root, sudo/su permission work and recently found out you can add users to groups, like docker so you don't have to 'sudo docker' everytime.
My question
How do you work with debian and su permission and what's the best way to do it for better security?
- Add an user in the sudoers?
- Give special permissions to a group? User?
- Always connect to su - (default root)?
- Add users to groups?
Because this is in a homelab environment, there is a minimal risk compared to exposed instances, but I'm interested to learn the best practice right away !
Thank you π
like this
moobythegoldensock, Ratz, zzz711, drone509, TheLongPrice, Zeko9381, tubbadu, funky_dude, FrostyCaveman, Theifokit, Aeroatrix, koala, RozaΕtuno, TiTeY`, MarshReaper, rsza, Matt, doricub, XPost3000, yesbot, Kristof12, newbeni, pipe01 and iamdanno like this.
FutileRecipe
in reply to deepdive • • •Have you read their page about sudo? Gives some pretty good insight. For bonus points, at the bottom of that page are links for security and administration.
wiki.debian.org/sudo
sudo - Debian Wiki
wiki.debian.orglike this
Ratz, yarn, PHLAK, FrostyCaveman, wildbus8979, deepdive, augustus672 and pipe01 like this.
Kallioapina doesn't like this.
deepdive
in reply to FutileRecipe • • •pipe01 likes this.
jsveiga
in reply to deepdive • • •In my home pc, I don't use sudo because my wife is the main user, and in the ultra rare occasion I need to be root in the command line (for example, if she didn't update packages from the GUI for long, I'll update but I like aptitude better), then I use su. It's a LTS 18.04 Kubuntu btw. Real users don't need root. Distro hoppers and tinkerers (nothing wrong with it) do.
On servers, I also use su. I ssh as a normal user (root ssh is usually disabled), then often immediately su, as if I'm logging into the server, it's for root work. I sometimes su - down to some specific "service" user to do that user's tasks (such as git on a gitlab server, or ndbadm on a HANA DB server).
I only tinker with sudo if I want to create users that will have one single purpose, which needs root permissions, such as restarting a service. In this case that user will be in the sudoers file, with permission for a single script or command, and often that command will be its default shell in /etc/passwd, and someone can ssh (pre shared key) to trigger it if necessary.
Ratz
in reply to deepdive • • •Being bad at a thing is the first step to being kinda good at a thing.
First, many distros ship with sudo so its pretty ubiquitous, anything you learn about managing sudo will apply to most if not all distros, not just debian. (Great choice though β€οΈ)
The correct answer is "it depends".
In a production environment you'll typically have some external authentication source like IdM, FreeIPA or active directory set up. In this case its common to just give full sudo access to the group that comprise your admin team, as in most cases you have to trust that they know what they're doing.
Ideally you want to follow the priciple of least access and avoid privilege escalation as much as possible. For example, there may be specific instances where a non-priv user needs to run $x as a super user, in which case, you should only grant the ability to 'sudo' for that executable as opposed to 'ALL'.
As you've already discovered, with great power comes great responsibility. π
like this
joey, CaptainDawn, NeroToro, FrostyCaveman, r0b0, megane-kun and augustus672 like this.
prostar doesn't like this.
deepdive
in reply to Ratz • • •Ratz likes this.
auv_guy
in reply to deepdive • • •like this
dartanjinn, wildbus8979 and Matt like this.
deepdive
in reply to auv_guy • • •nyan
in reply to deepdive • • •If you have root permissions, no amount of security setup can completely keep you from shooting yourself in the foot with things like this. In the end, you'll need to do the reading and learning.
If you're admin'ing a multiuser machine, best practice is to use sudo with a carefully curated /etc/sudoers, to ensure that no one has more permissions than they absolutely need.
For cases where you're the sole human user and also the admin, sudo vs. su is pretty much a wash securitywise (because something always comes up where you need full root permissions, so you can't give yourself less). It should be sufficient to add your user to groups, never issue a command not related to package management with sudo or an su'd shell without trying it as a user first, and if it doesn't work as a user, stopping and thinking about why not and what you were trying to do in the first place.
like this
deepdive and pipe01 like this.
deepdive
in reply to nyan • • •Thank you ! Because I was always using the root user for everything I also fucked-up my home directories, which really didn't looked great ! I fixed everything right now (New user, new directory/file system, everything to the correct owner...) and will only add my specific user to the needed groups. I like that workflow, because having to sudo to everything with the root user really give me security concerns ! π
nyan
in reply to deepdive • • •jsveiga
in reply to deepdive • • •In my home pc, I don't use sudo because my wife is the main user, and in the ultra rare occasion I need to be root in the command line (for example, if she didn't update packages from the GUI for long, I'll update but I like aptitude better), then I use su. It's a LTS 18.04 Kubuntu btw. Real users don't need root. Distro hoppers and tinkerers (nothing wrong with it) do.
On servers, I also use su. I ssh as a normal user (root ssh is usually disabled), then often immediately su, as if I'm logging into the server, it's for root work. I sometimes su - down to some specific "service" user to do that user's tasks (such as git on a gitlab server, or ndbadm on a HANA DB server).
I only tinker with sudo if I want to create users that will have one single purpose, which needs root permissions, such as restarting a service. In this case that user will be in the sudoers file, with permission for a single script or command, and often that command will be its default shell in /etc/passwd, and someone can ssh (pre shared key) to trigger it if necessary.
PS: It happened sometime
... show moreIn my home pc, I don't use sudo because my wife is the main user, and in the ultra rare occasion I need to be root in the command line (for example, if she didn't update packages from the GUI for long, I'll update but I like aptitude better), then I use su. It's a LTS 18.04 Kubuntu btw. Real users don't need root. Distro hoppers and tinkerers (nothing wrong with it) do.
On servers, I also use su. I ssh as a normal user (root ssh is usually disabled), then often immediately su, as if I'm logging into the server, it's for root work. I sometimes su - down to some specific "service" user to do that user's tasks (such as git on a gitlab server, or ndbadm on a HANA DB server).
I only tinker with sudo if I want to create users that will have one single purpose, which needs root permissions, such as restarting a service. In this case that user will be in the sudoers file, with permission for a single script or command, and often that command will be its default shell in /etc/passwd, and someone can ssh (pre shared key) to trigger it if necessary.
PS: It happened sometimes that I was given a user with full sudo permissions to do root work in someone else's server, but no root password. Then the first thing I do after logging in is "sudo su -"
ABeeinSpace likes this.
eshep
in reply to deepdive • •like this
Kristof12 and Kelo like this.
Linux reshared this.