0

The main point is that I only want one user to have sudo access - really only for use in set up and emergencies. I don't even trust myself with sudo access all the time. Are there best practices around doing that? Examples:

Give a user/group access to a particular port (and not others) without giving sudo access (some answers are net_bind, iptables, and authbind) Install services like apache in a way where users can use it without sudo Install systems like node.js in a way that allows Give a user or group broad permissions to install programs that other users can use, again without giving them sudo or root access If I want to give someone as broad permissions as possible without them having any permissions to do anything that will clobber the machine (clobber sudoers, clobber /etc/passwd [which literally just happened to me], clobber anything that would prevent logging in via ssh on root, etc), how would I do it?

The main point is that I only want one user to have sudo access - really only for use in set up and emergencies. I don't even trust myself with sudo access all the time. Are there best practices around doing that?

B T
  • 199
  • 4
  • I suggest a different approach: give this guy full access through `sudo`, and make `syslogd` send `sudo` logs to a remote host. Tell the guy about the logs, too. And think of `sudo` as an audit mechanism, rather than a security one. This is better than your solution for two reasons: first, as @Anthon points out, being able to install things == root, and second, a solution that can fail in 200 interesting ways is a bad solution, regardless of how clever it might look in theory. – lcd047 May 31 '15 at 11:42
  • You know, `sudo` is just a *package* - you can uninstall it. It is not necessary - and, in many cases, it's more than a little dangerous. The primary benefit `sudo` offers is that it allows lazy admins to to avoid properly configuring hierarchical group-based permissions, and that said admins can do so without having to share a password. So just uninstall it, and go out and learn how to setup a system with a real root account properly - particularly look at such things `chgrp` *(which is useful for interactive shells to lower/higher permissions as needed)* and group perms in general. – mikeserv May 31 '15 at 15:58
  • @mikeserv I'd love to learn about the "hierarchical group-based permissions" you're talking about - it sounds potentially exactly like what i'm looking for. Mind creating a full answer around that? – B T May 31 '15 at 21:43
  • They closed the question, dude. But it's all fs-based. Just pay close attention to the way you setup your fs-tree based on group-ownership. Learn how to properly use set[gu]id file flags, and learn the different meanings of *UID*, *EUID*, *GID* and *EGID*. You already have [`chgrp`](http://pubs.opengroup.org/onlinepubs/9699919799//utilities/chgrp.html). By the way though, `ksh93` can be built to handle *profile* shells which can enable you to switch E[GU]IDs mid-session safely - but you'd have to make its executable file `setuid` - just like `sudo` in that case. – mikeserv May 31 '15 at 21:51
  • God damnit, wtf is wrong with these admins? No comment from them, just a unilateral block. Most of these admins that do this put 0 effort into trying to help a user improve their question - like these idiots – B T May 31 '15 at 21:53
  • @mikeserv thanks I'll look into that stuff – B T May 31 '15 at 21:54

1 Answers1

1

I don't know about "best" practises, but if you feel more comfortable with more restricted sudo than comes out of the box, you should IMO do the following:

  1. make a normal user "install" user that requires explicit login to, with a clearly different prompt and which, via /etc/sudoers is allowed to run your installer program(s) (apt-get, yum, etc.) with root priveliges.

  2. set up another named user with full root priviliges via /etc/sudoers

The first you can repeat for any other specific tasks requiring root priviliges.

Instead of point two, you can explicitly login as root. The advantages of having one or more special accounts is that you could, with some work, generate passwords for these accounts, that are not accessible without you noticing or some extra persons effort (e.g. printed out and put in an envelop, split in two parts known each only by one person). Combined with remote logging facilities (as root can change the logs on the machines itself). You can keep track of who has been gaining access and verify why and whether that was really necessary.

Over the past 30 years I have added one or the other of these "controls" in one form or another on Unix & Linux systems. Maybe not fool-proof but enough of a deterrent to limit damage, and in one occasion to bring theft of software to light.

Anthon
  • 78,313
  • 42
  • 165
  • 222
  • So for case 1, what kind of permissions might that give someone? Could you maybe give an example there? – B T May 31 '15 at 11:02
  • That gives permission to execute a command. Extensive xamples of that can be found using `man sudoers` with concrete examples for `apt-get` in [this](http://unix.stackexchange.com/q/39572/33055) post + answers (including an alternative using apt daemon). **If you can install something as root, you can easily get full control over the system, unless you are not allowed to create (root) SUID programs** – Anthon May 31 '15 at 11:12