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

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?

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.

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.

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.

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.

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:

1. Automatically censors certain commands from being executed. Like stop & rsyslog combined.

2. bans commands to escape this shell and use another even the original bash

3. bans commands to prevent the user from gaining the role root like what @user253751 mentioned above.

4. 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.

related questions are:

How can I log users' bash commands?

How can I make bash to log shell commands to syslog?

Login without running bash_profile or bashrc