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. Sep 12, 2021 at 4:26
  • Linux is not vulnerable. It's you just refusing the proper way of doing things. The idea is legitimate, and it's pretty possible to accomplish that in Linux, if you do things as it's supposed to be done in Linux. In particular, don't run services as root and implement white lists are both the proper way of doing things, and by refusing to do it this way you are making your system vulnerable. May 7 at 9:16

5 Answers 5


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.

  • 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. Sep 7, 2021 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. Sep 7, 2021 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. Sep 7, 2021 at 21:07
  • 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. Sep 8, 2021 at 6:15
  • 6
    @GeorgeY so what stops them just running sudo bash and then being root? Sep 8, 2021 at 8:49

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.

  • 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 8, 2021 at 10:38
  • 2
    @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 9, 2021 at 0:19
  • 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, 2021 at 11:01
  • 1
    @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, 2021 at 15:14
  • 1
    @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, 2021 at 19:14

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.

  • 4
    The program can get the original user information. getuid() still returns the original user, apparently. The setuid user is geteuid() ("effective UID") Sep 8, 2021 at 9:02
  • 4
    Actually, this is the usual way to go. This is the way how sudo itself works. Sep 8, 2021 at 10:29
  • 1
    "or scripts" -- Setuid doesn't work on scripts. They need to be binary executables.
    – JoL
    Sep 9, 2021 at 21:39

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.

  • 1
    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. Sep 10, 2021 at 5:24
  • Exactly, the pid loops within 0 ~ 2^16-1=65535.
    – George Y
    Sep 10, 2021 at 8:34
  • PID_MAX is 32767 by default, but it can be adjusted up to 2²²-1, see web.archive.org/web/20111209081734/http://research.cs.wisc.edu/… . Default is so small for not to break old software. Sep 10, 2021 at 9:27

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

  • 2
    The censor script is a good idea; you can also do this through sudo, so the users have normal bash when they're unprivileged, but run "sudo censorscript" to run it. The problem is making sure you've caught absolutely all the ways people can sneak through it. For example, you can't let them run emacs or vi because those can start shells. Hence it's easier to whitelist.
    – pjc50
    Sep 10, 2021 at 11:03
  • The only viable censor executable running as root would be a menu like whitelist of actions. Press 1 to stop service A, press 2 to stop service B. Any other approach would always offer ways to sneak out. And even then it would have to be statically compiled and take all kinds of precautions to isolate with respect to the environment it is started in. Better not reinvent the wheel and use utilities like sudo that have a lot of experience under their belt in this line of action.
    – Gerrit
    Sep 10, 2021 at 11:32
  • You have to watch out many things like shell escapes and so on. And, "censor script" couldn't be a script actually. Linux allows setting setuid/setgid only for binaries, not for scripts, so your script could not be started privileged by unprivileged user. And, I'd rephrase @Gerrit, better build a list of allowed complete commands (without placeholders) and that'll be your safeguard, because it will be impossible to circumvent. Sep 10, 2021 at 11:49
  • 1
    Also notice, what you end up with is the ad-hoc version of sudo. So better read sudo manual and adjust its configuration than to invent your own sudo. Sep 10, 2021 at 11:52
  • 1
    Just be aware that this method falls apart as soon as you allow any kind of writing to arbitrary files as root (even just input redirection is enough). The user can just rewrite an arbitrary executable file and run whatever they please. (anything but a whitelist of commands will have similar problems)
    – JensV
    Sep 27, 2021 at 20:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .