for a reason I do not really understand, everyone wants sudo for all and everything. At work we even have as many entries as there are way to read a logfile (head/tail/cat/more, ...).
I think, sudo is defeating here.
I'd rather use a mix of setgid/setuid directories and add ACL here and there but I really need to know what are the best practices before starting up.
Our servers have %admin, %production, %dba, %users -i.e many groups and many users. Each service (mysql, apache, ...) has its own way to install privileges but members of the %production group must be able to consult configuration file or even log files. There is still the solution to add them into the right groups (mysql...) and set the good permission. But I do not want to usermod all users, I do not want to modify standards permissions since it could change after each upgrade.
On the other hand, setting acls and/or mixing setuid/setgid on directories is something I could easily do without "defacing" the standard distribution.
What do you think about this ?
Taking the mysql example, that would look like this:
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
Do you think this is good practise or should I definetely usermod -G mysql and play with standard permissions system ?
Thank you
Best practices: maintain the sudoers file and use sudo.
On my personal machine, I prefer setuid/gid, but I'm the only one on my computer; and I don't do it to anything blatantly dangerous like
rm
.Best practices (and most common) tend toward using
sudo
. Sudo offers you fine-grained control, and the configuration can handle multiple machines all at once.Using ACLs can complement this -
sudo
handles operations as root; ACLs give and take away rights to directories and files to users and groups. I wouldn't count on setgid and setuid to do anything reasonable.I would also implement the wheel group; this will help increase security. Check to see if your
su
program supports the wheel group.One more thing: if you have
view
orless
as a way to read a logfile, then you are at risk: both of these programs offer shell access.It seems to me that the sudoers option is a bit more compact than the setuid/setguid/ACL.
Without grouping users, your ACLS will be very long. And if you do group users, you're back to the same place you started.
The bigger issue is that without some kind of central management of it, access control gets spread throughout the filesystem. Of course you can easily get around that with i.e. macros, templating, config management and so on. But that's a whole other layer which does nothing to reduce complexity.
In my small Drupal shop I use ACLs quite extensively for all working files but sudo for all management access. The configuration management layer I'm using is Ansible and the nice thing about that is that I can easily template users, their roles, and therefore what groups they get, on what machines, and so on. Sudoers is similarly managed. That seems pretty best practice to me because it is most transparent.
Of course, I probably don't have near as many users or groups as you. I could envision putting ACLs in config management as well. But for the life of me, I don't see a straightforward way of managing many machines, many users, and many groups that way.