13

I want to give non-sudo access to a non-root user on my machine, there is a user dns-manager, his only role is to run all the BIND commands(rndc, dnssec-keygen) etc.

Now everytime he has to run a command, he types,

sudo rndc reload

Is there a way I can get rid of this sudo, but only on a particular set of commands(and only for dns-manager)?

Anss
  • 313
  • 1
  • 4
  • 11
  • 5
    Discretionary access control like this is pretty much what `sudo` is for. What are your business objections to his using `sudo` for this? – MadHatter Mar 18 '15 at 07:53
  • @MadHatter I think he wants to partially delegate sysadm privileges, thus he wants to follow with his OS-level permission sysem the organizational hierarchy. – peterh Mar 18 '15 at 07:55
  • He wants to use a software utility to manage the DNS, this utility will have the ssh access of the machine. Now the API he is using for ssh does not support sudo commands(as in sudo prompts for password and there is no way on injecting password through that API). – Anss Mar 18 '15 at 07:57
  • 1
    @peterh I repeat my question: discretionary access control (ie, partial sysadm delegation) is the role of `sudo`. What are the objections? – MadHatter Mar 18 '15 at 07:57
  • 3
    How about passwordless `sudo`, then? Or passworded sudo *to run the DNS management tool*, which can then operate with `named` group or user privilege, or root privilege, as needed. – MadHatter Mar 18 '15 at 07:57
  • @MadHatter From his question seems, probably he wants to delegate dns management tasks to a subordinate. The objection would be probably to optimize the distribution of the sysadm tasks in a system administration department. – peterh Mar 18 '15 at 08:00
  • 4
    @peterh "a good reason to do it this way" would be the missing bit. Usually questions like this turn out to be [XY problems](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) in disguise, and I find that understanding the underlying issue is key to answering them fully and professionally. – MadHatter Mar 18 '15 at 08:01
  • @MadHatter Yes, but it is his responsibility already. Maybe there is a better solution for that, maybe there isn't - if he can't ask good questions, he won't get good answers. If he needs a solution to a wider problem, he should formulate a wider question. – peterh Mar 18 '15 at 08:03
  • @MadHatter But I think this question could be attacked by its triviality (-> which could result a migration to SU or unix SE). – peterh Mar 18 '15 at 08:04
  • 2
    @peterh I think we're agreeing with each other. I, too, want to see the OP improve his question; drilling down into it works well for me as a way to help the author think outside the box he's built around himself. He may well have a good reason for wanting to avoid `sudo`. In trying to express it to us, he may either clear up our confusion, or his own - or both! – MadHatter Mar 18 '15 at 08:05
  • @MadHatter I think we both have the internal wish to solve his problem. This can be more as just answering his question. But we don't see his problems, his objectives. Maybe he is simply not allowed to use anything out of the command line. If we want to solve his problems, this can easily go into a direction where we force our will and conceptions to him. But it is not okay, this leads to slaves and insurgents. He is going his way, if it leads to a bad direction, we could advice him (f.e. "maybe you could use the a web-based dns management tool"), but forcing him to our direction is imho bad. – peterh Mar 18 '15 at 08:14
  • I don't really know how to 'improve' this question. What I have established from googling is that there is no way of doing what I intend to do. Passwordless sudo is my best bet. One positive thing here is that the tool our dns-manager is using is written by his own self, so he can configure the code if necessary. – Anss Mar 18 '15 at 08:35
  • In the specific case of `rndc` it's sufficient to give him read access to `/etc/bind/rndc.key` or wherever you've stored the key file that rndc uses to authenticate itself to the `named` process. – Shadur Mar 19 '15 at 05:36

4 Answers4

31

If I understand your comments correctly, the issue here is that the command will be issued through a connection that does not have any ability to enter the password that sudo defaults to requesting. Also, in many OS distributions, sudo will default to requiring a TTY - which this program may not have.

However, sudo is able to have a very fine-grained permissions structure, making it possible to allow one or more users to issue one particular command without password and TTY. Below, I'll show three ways to configure this for your needs. Whichever one you choose, the user will now be able to issue the command sudo rndc reload without having to enter a password.

(Also, this may be unnecessary, but... please remember to make a backup copy of your sudoers file before editing it, to keep a shell where you're root open in case you need to revert to the backup, and to edit it using visudo instead of sudo vi /etc/sudoers. Hopefully these precautions will be unnecessary, but... better to have them and not need them than the reverse!)

1. If you don't want to require a TTY for any requests

The easiest way to get rid of the TTY requirements (if one exists) is to make sure that the line beginning with Defaults in /etc/sudoers does not contain the word requiretty - instead, it should contain !requiretty. However, if you do this, it means that no sudo command will require a tty!

You will also need to add the line

rndcuser ALL = (root) NOPASSWD: /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program

2. If you want to require a TTY for all users except this one

This can be done by setting a default for this one user, like this:

Defaults:rndcuser        !requiretty
rndcuser ALL = (root) NOPASSWD: /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program

3. If you want to requre a TTY for all commands except this one command by this one user

This is a bit more complex, due to the syntax of the sudoers file. You'd need to create a command alias for the command, and then set a default for that command alias, like so:

Cmnd_Alias RNDC_CMD = /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program
Defaults!RNDC_CMD !requiretty
rndcuser ALL = (root) NOPASSWD: RNDC_CMD
Jenny D
  • 27,358
  • 21
  • 74
  • 110
  • Of course, this can be combined with a wrapper script that calls the command using sudo, if for some reason you can't use sudo directly even when it's passwordless. – Jenny D Mar 18 '15 at 10:22
4

Yes. sudo can be configured very flexibly. Even so, I must mention: these types of solutions shouldn't be considered very secure, and they should only be used in a cooperative environment where other controls are on place (thus, you can give these enhanced privileges to your loyal subordinate, but shouldn't do so for a customer you know only from the net).

The sudo config is in /etc/sudoers in most systems. You can find out its syntax by Googling or by a man sudo command.

You shouldn't edit this file directly; doing so can lead to security race conditions. Instead, use the visudo command (which is a wrapper around your $EDITOR environment variable).

After you configure sudo, you can easily wrap this around the visible commands. It is very simple:

  1. Create a directory for a list of your sudo wrapper scripts (f.e. /usr/local/dnsadmin/bin)

  2. Create a wrapper script for the commands you want them to make usable without sudo. It will be a very simple command, for example, /usr/local/dnsadmin/bin/rndc will be:

    #!/bin/bash exec /usr/bin/sudo /usr/sbin/rndc "$@"

  3. Get this directory into their PATH environment variable (e.g. by a system-wide or their local .profile).

Snowbody
  • 135
  • 1
  • 1
  • 4
peterh
  • 4,914
  • 13
  • 29
  • 44
  • Out of curiosity - why would you use `exec` in the shell script instead of just calling the command directly? (I'm not saying that it's wrong, I just like to know why you'd do it so I can maybe learn something) – Jenny D Mar 18 '15 at 08:36
  • 2
    I am done with the passwordless sudo bit, the wrapper scripts idea is great. – Anss Mar 18 '15 at 08:37
  • 2
    @JennyD :-) Because of stability and performance. In case of `exec`, the called command will substituted in the place of the shell. The shell will go away. Without an exec, the shell will start that command, and then waits its termination, and then exits. This second, exec-less means multiple cooperating processes, which is unneeded. But there is no big difference, without exec would this work just so well as with that. – peterh Mar 18 '15 at 08:42
  • @JennyD My plea :-) – peterh Mar 18 '15 at 08:58
  • @Snowbody Thank you very much the lectoring! It is a very big honor. – peterh Mar 19 '15 at 14:44
2

While this isn't a general solution in the specific case of rndc you don't need sudo at all.

rndc can communicate with any named process either via a local socket or a remote port, using a secret key to authenticate itself. By default (or at least, for debian, which is the distro I use) this file can be found in /etc/bind/rndc.key and is normally readable only to user bind and group bind.

Anyone who has read access to that key file (or an identical copy of it) can use rndc to control the BIND server, so the easiest solution in this particular case would be to add the user to the bind group.

A surprising number of common daemons have something similar set up (I'm personally still figuring out the possibilities of powerdns in that regard, but it's looking promising so far). If you don't want to do sudo you'll have to check whether what you want to accomplish is possible on a case by case basis.

Shadur
  • 1,297
  • 1
  • 10
  • 20
0

You don't want to use sudo to grant root for some commands. Instead you could chmod 4750 a specific program [that can wrap the command], to elevate the rights of a normal user to execute that as root.

bbaassssiiee
  • 142
  • 6