How can root start a process that only root can kill?

Question

It is easy to start a process at background or make it as systemd service.

However, if I want to start a process that monitors activities on the Linux machine, it fells to the target of attacks. If any user want to do something bad it will first kill this process, even if they are only sudoers or wheel users, by simply executing kill or systemctl stop.

Is there a way to enforce a process that only root can kill?

Guys, just to think that even rsyslog service can be killed, you should acknowledge how vulnerable Linux really is. It is like a pilot can turn off black-box. Does any airline allow this to happen? Or does any give the pilot an allow-list to hinder them from doing anything they can to save the plane? Of course the pilot Can crash the plane but black box will Record it.

My proposal on a ban-list is legitimate from security perspective, even though it may freak you out. So don't try to blame the guy who raised the question, all right?

Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/129511/discussion-on-question-by-george-y-how-can-root-start-a-process-that-only-root-c). — Ward - Reinstate Monica, Sep 12 '21 at 04:26

score 31 · Answer 1 · answered Sep 07 '21 at 12:23

31

Having unrestricted sudo/wheel privileges anybody will be able to undo anything you done. Even if you manage to achieve this by removing the possibility to kill process directly, e.g. with sudo kill, either this could still be circumvented using other sudoed commands, or you also lock yourself out of administration.

Ask yourself, why untrusted users have unrestricted sudo privilege at all in the first place? They shouldn't. Only give such privigeges to those who you trust completely. If there are some privileged commands that still need to be executed, enable sudo only for those commands:

+netmgr /usr/sbin/ifup, /usr/sbin/ifdown

(use visudo -f /etc/sudoers.d/netmgr to put this into sudoers add-on file).

This way you may permit a user to only run sudo /usr/sbin/ifup and sudo /usr/sbin/ifdown, but no other sudo commands. A plenty of other examples, instructions and security considerations are in man sudoers. Read it!

Auditing is done usually other way. In particular, you set up another machine, configure its syslog to accept logs from remote stations. On the machine in question you set up logging so it'll send all logs into logging machine, in addition to storing locally. Even if somebody disables this log sending, the action of disabling itself will be logged, so at least you'll know who is the culprit.

answered Sep 07 '21 at 12:23

Nikita Kipriyanov

8,033
1
21
39

Unfortunately, I have to allow them to use `kill` or `systemctl stop` because there some applications that do need these priviledges to do their job. I just need a certain monitor program denying their stop-signal. – George Y Sep 07 '21 at 12:46
Another example is that I add a trigger in the setting `/etc/bashrc` - I do want it protected, but I cannot ban running editor like `vim` or `nano`. – George Y Sep 07 '21 at 13:05
10

@GeorgeY If someone can get root access then they can kill your process. If someone is _actually_ doing this and will not stop, then the solution is not technical: You need to get management involved. – Michael Hampton Sep 07 '21 at 14:12
4

@GeorgeY, you can't make a process unkillable by root. Root is god, you can't disable it doing something. And sudo makes you root effectively. The only viable solutions as I see that is to not to give root privileges. What I suggested is to use sudo's built-in capabilities; if it's not sufficient, you have to invent your own sudo. Write a proxy application for kill or systemctl stop, which will filter out things that are forbidden to kill, or better, which only allow certain things to be killed, and so on. You have to wrap *all* things you want to be callable by non-root users. – Nikita Kipriyanov Sep 07 '21 at 19:00
6

If you've got root, you could go one step worse and replace the said process with one that reports everything is fine yet allows you to continue on your nefarious activities. – Matthew Ife Sep 07 '21 at 21:07
@Nikita Kipriyanov Of course I will not give them `root` access, actually I give them `wheel` privileges, yet still they can kill any process indifferently. What I want is that they cannot kill a certain type of processes, say, initiated by root user or a file in `/root`. – George Y Sep 08 '21 at 04:02
9

"root" and "wheel" are exactly same god-like privilege. Bear with it. If you don't want to give them root, don't give wheel. Period. – Nikita Kipriyanov Sep 08 '21 at 06:15
6

@GeorgeY so what stops them just running `sudo bash` and then being root? – user253751 Sep 08 '21 at 08:49
@GeorgeY If you want user **who is effectively root** to be able to kill any process except a particular one, or edit any file except a particular one, you have to design your own kernel that has such capabilities :). Linux just doesn't work this way, period. – raj Sep 09 '21 at 13:24
@raj So this is how Linux paved the way to internal crimes like data leaks? :) – George Y Sep 10 '21 at 13:55
2

@GeorgeY that's trolling: the same privilege issue exists in Windows, with slightly different details among ADMINISTRATOR/LOCALSYSTEM and the domain admin, and data leaks are often done without privilege escalation at all by compromising the webapp which has access to the data. – pjc50 Sep 10 '21 at 15:07
(having domain admin is even more fun because you can run any program on any computer in the organization!) – pjc50 Sep 10 '21 at 15:07
1

.. possibly the solution you want is in the other direction? If you want to enable a user to kill only certain processes, identify those processes and make *them* run as not-root? Or run them in a container or VM? – pjc50 Sep 10 '21 at 15:10
1

@pjc50 funny thing here is that the author of the question stubbornly refuses to do this way, despite the fact this is what everyone advises him. Instead of following the Linux way to do things in Linux, he thinks this is Linux's fault that is doesn't work the way he supposed it has to work. – Nikita Kipriyanov Sep 11 '21 at 15:42

score 18 · Answer 2 · answered Sep 07 '21 at 20:02

18

You can't give someone a power and then prevent them from using it. You have to narrowly focus the power you give them to only include what you want them to have.

In a comment, you said:

I have to allow them to use kill or systemctl stop because there some applications that do need these priviledges to do their job

That doesn't mean those users need access to those commands, only those applications. The user has limited permissions to run sudo ./someprogram and once that program is running as root, it can use kill, etc as needed. The user doesn't have direct access to those internal commands, though.

Fundamentally speaking, users don't need access to commands, they need access to functionality. If kill is too risky, block access to it and provide some other, safer way to achieve the same result. Perhaps you create a small utility safekill that acts like kill but refuses requests to kill certain processes. Give your users sudo access to safekill but not the real kill. If users are always using these commands to do the same thing, encapsulate that whole process in a small program and have them use that instead of doing it manually (e.g., they'd run sudo restart_webservers instead of killing and restarting all the various server processes individually). Your users still have access to the functionality they need, but they can't wield the dangerous weapons directly.

There's another, more extreme enforcement mechanism that might be available depending on your particular setup. Some processors have watchdog timers available. Modify your activity monitoring program to start the watchdog and reset it every couple of seconds. Should someone manage to kill your monitor, the watchdog timer would expire and the system would reboot itself, relaunching the monitor program at startup. This wouldn't strictly prevent the monitor from being disabled, but it would prohibit anyone from doing anything meaningful after disabling it. This will also create nice big red flags in your system logs. Most systems with watchdogs will report when a specific reboot was triggered by the watchdog. A watchdog-triggered reboot that occurs while a user was logged into the shell should be seen as very suspicious.

answered Sep 07 '21 at 20:02

bta

536
2
8

I think your suggestion is to define a "White List" on what users other than `root` CAN do, rather than my original need what they CANNOT do. This is indeed a walk-around, but would ease their duty too much. – George Y Sep 08 '21 at 08:00
1

`You can't give someone a power and then prevent them from using it` - sounds like the British royal family. The Queen has the power to order executions of anyone she doesn't like, but if she actually use that power, she'd probably be deposed before any actual execution would take place – hanshenrik Sep 08 '21 at 10:38
1

@GeorgeY Most admins use whitelisting, yes. You can also effectively blacklist certain commands. Something like `baduser localhost = (baduser) /bin/kill` would allow the user 'baduser' to only run kill as their own account (not as root). There's a lot more information and advanced options in `man sudoers`. – bta Sep 09 '21 at 00:19
@hanshenrik, does she? Do you have a source on that? – ilkkachu Sep 09 '21 at 11:17
@ilkkachu: Well, when the UK still had capital punishment, technically any execution would be done in her name (as she's always the plaintiff in a criminal case in the UK). But that probably doesn't count. – Kevin Sep 10 '21 at 00:02
@Kevin, yeah, of course the references to King/Queen or Crown exist as formalisms there. But I was under the impression that UK and other commonwealth countries by now had legislation forbidding extrajudicial punishment. (And in the case of England, the concept usually comes with references all the way to Magna Carta, some 800 years ago...) And while they have something like the theoretical power of the Queen to withhold signing bills into law, that's still a bit different from the Queen just walking over laws already approved by King/Queen. (Parliamentary sovereignty and all that.) – ilkkachu Sep 10 '21 at 09:25
@hanshenrik So you mean the soldiers who are in charge of nuclear missiles can fire at their own will? My question is equivalent to - a pilot can do anything on the airplane, except for stopping or hacking the black box. – George Y Sep 10 '21 at 09:31
1

"define a "White List" on what users other than root CAN do, rather than my original need what they CANNOT do" - this is unfortunately mandatory in security, because otherwise people keep finding ways to use the functionality they have to do the things you don't want. As for the UK nukes, yes they're (supposedly) capable of independent launch - and indeed that's what they're intended for, to be launched in the case that all the hierarchy above is already dead. – pjc50 Sep 10 '21 at 11:01
@GeorgeY but most operating systems (not only Linux) are designed so that they don't have any kind of "black box". I would strongly oppose the idea of having some "black box" that I cannot control in a computer I OWN. – raj Sep 10 '21 at 15:14
@raj, maybe most operating systems aren't able to have a black box, but most hardware does these days. Intel and AMD both have a little extra processor and the control you have over it is varied depending on what management features are enabled. – timuzhti Sep 10 '21 at 17:49
@GeorgeY A pilot CAN stop an airplane as much as physics allows for it. This (and your original issue) is more of a social one rather than a technical one. Ask yourself this: why is that while having the technical capability to do something bad, say a pilot virtually never would come to actually do it; how comes your users are different? If they aren't, it's a non-issue, if they are, you have a problem which has little do do with computers and a lot to do with people. Don't give access to things you don't trust users with, especially if suspecting malice. – Lodinn Sep 10 '21 at 19:14
@timuzhti And that's what bothers many people, you can see articles expressing concern abut this all over the Internet, because people definitely don't want this. – raj Sep 10 '21 at 20:06

score 10 · Answer 3 · answered Sep 08 '21 at 07:53

10

Linux noob here. Could you consider writing programs or scripts that do only what these guys are meant to do, then make them root-owner and add them setuid bit? Of course, one big issue is you might not want other people to run these commands. I'm not sure if you can get the original user information. And of course, extra care is always necessary with setuid/setgid.

answered Sep 08 '21 at 07:53

user1532080

201
1
2

4

The program *can* get the original user information. getuid() still returns the original user, apparently. The setuid user is geteuid() ("effective UID") – user253751 Sep 08 '21 at 09:02
4

Actually, *this* is the usual way to go. *This* is the way how `sudo` itself works. – Nikita Kipriyanov Sep 08 '21 at 10:29
1

"or scripts" -- Setuid doesn't work on scripts. They need to be binary executables. – JoL Sep 09 '21 at 21:39

Gerrit · Answer 4 · 2021-09-10T11:21:59.047

If you give a user free reign as root, then the user could kill almost anything. For some in depth discussion and possible workarounds see: unix stack sigkill discussion.

Also the watchdog solution mentioned by @bta is interesting. There is in fact a software watchdog package available, that can be configured to monitor changing of files or execute a user script. However on most standard kernels this watchdog can be stopped by the root user, or you can change its config. But other users would have to be aware of this to avoid it. See: https://linux.die.net/man/8/watchdog

But if you don't have to allow full root access but can manage their access with the sudo mechanism, then you can set some commands with explicit arguments for them to execute and not allow anything else other then their default user rights.

For example, you can put /bin/kill in the /etc/sudoers file, but only allow specific arguments.

bob ALL=(root) /bin/kill -sigTERM [1-9][0-9][0-9][0-9]

This would allow user bob to execute /bin/kill, but only kill processes with a PID between 1000 and 9999. If you execute your monitor early enough it will have a low PID and could not be killed in this way. User bob could still mess with you by killing your own user processes of course...., and what with PID wrapping, this may not be too useful anyway.

It is possible to subtract certain options from a full set. For example, kill all non negative PID, but don't permit signaling a PID containing 1337 and don't allow -1 killing.

bob ALL=(root) /bin/kill -sigTERM *,!/bin/kill *1337*,!bin/kill *-1*

But that would be a little awkward, and you would have be very sure that the program doesn't wrap its ints. Procps kill doesn't as far as I can see, but this example would still allow killing a process with pid 1337 if it was part of a process group of which it was not the leader. So this goes to show how tricky it is to work with negatives or blacklists.

Better option, only allow to kill certain processes by name

bob ALL=(root) /usr/bin/pkill -sigTERM -f namedprocess

Or only restart specific service

bob ALL=(root) /bin/systemctl restart a-service

The user can view available sudo commands with sudo -l

It is important if you allow certain programs to specify them will full path. And also the user must not have unlink or edit rights on that program or it could be replaced with something else.

The pid restriction is useless. The system which is running for long enough will have pids wrapped, so it will both have user processes and system processes with any pids, with no apparent distribution. There will be certainly no way to express a set of pids which must be unkillable. — Nikita Kipriyanov, Sep 10 '21 at 05:24
PID_MAX is 32767 by default, but it can be adjusted up to 2²²-1, see http://web.archive.org/web/20111209081734/http://research.cs.wisc.edu/condor/condorg/linux_scalability.html . Default is so small for not to break old software. — Nikita Kipriyanov, Sep 10 '21 at 09:27

George Y · Answer 5 · 2021-09-17T07:44:50.203

0

I have come up with A Start!

root can set a DEFAULT SHELL on a user like this:

useradd [someuser] -s [a certain executable]

Then if the certain executable = A censor script that:

Automatically censors certain commands from being executed. Like stop & rsyslog combined.
bans commands to escape this shell and use another even the original bash
bans commands to prevent the user from gaining the role root like what @user253751 mentioned above.
Pass the rest of commands to /bin/bash

Then just set it r+x for any user.

Any suggestion is appreciated under this answer. Especially for 2 & 3 there seems various means.

Bash will load the settings in /etc/profile and /etc/bashrc first. I have noticed the latter deals with the PROMPT_COMMAND variable. It is possible to hijack this at the last line of it to add in the censorship script, but an exemption username is needed for some systems since by default no one has root privilege to change it back.

A complete censorship that satisfies the above 4+1 will be marked as legitimate answer.

I will never mark an "you shall give it up" answer as legitimate.

How can root start a process that only root can kill?

5 Answers5