Non-modular kernel

There is kill and then there is kill -9. For the latter CAP_KILL is needed, which can be avoided if the other users only need normal "kills".

Processes started by root are killable only by root. But root means every process that is running with UID 0. The only thing that really matters for the OS is the UID, so there is no easy way to distinguish the user who has logged in as literal root (btw. this is discouraged and many OSes block login to root by default) from someone who gained root privileges (that is, UID==0) by eg. sudo.

"Only sudoers"?

@Vikki no, he want to create a process which root can kill, but unrestricted sudoers can't. Impossible, indeed, but also he doesn't want to understand this and develop more viable ideas from suggestions down there.

Why is your company paying people who want to do bad things? If your users are knowingly doing, or trying to do, bad things, they shouldn't be your users.

I'll repeat this comment under the question because it's important: what do you think stops the person from running sudo bash and then being actual root as opposed to "someone who's using sudo"?

@Gerrit, there's no difference between the permissions required to send SIGTERM vs. SIGKILL. The only exceptions the man page mentions are SIGCONT and the init process.

What does "only sudoers or wheel users" mean? You are aware that sudo just changes the UID of the process it launches, to one different from the original caller? (Giving it all capabilities at the same time, when launching a process as root, at least I can't find anything in the sudo/sudoers man pages that would hint at the possibility of giving restricted capabilities.) At that point, the process is running as root, fair and square.

@ikkkachu not quite, mandatory access control systems like selinux really allow some deeper security segregation, like permit something to one binary and reject to another, despite the fact they both run with same UID. But the problem as stated in the question still couldn't be solved even with this heavy artillery.

@ilkkachu You are right with the permissions. CAP_KILL is the same for all signals. The difference is that programs can sort of ignore the other signals, but not SIGKILL. In respect to sudo is just changing uid, that is oversimplified because of PAM. setpriv behaves more like a simple change of uid.

If your attacker has unrestricted sudo access, they can just load a kernel module and bypass absolutely everything you hope to enforce. I think you need to restructure your threat model.

@user253751 That is a very good point! Perhaps setting permissions on /bin/bash could prevent them from using root role?

@GeorgeY then they can run sudo sh or sudo zsh or sudo tcsh or sudo ./my_program_i_just_wrote_that_does_bad_things

@user253751 There seems to be a setting to enforce using only bash? In that case the loop holes you mentioned would be nil.

@GeorgeY sudo ./my_program_i_just_wrote_that_does_bad_things. Anyway, if the user can only do sudo bash, and it doesn't work because of file permissions, they can't do the things you wanted them to do in the first place! may as well just not give them wheel

@user253751 I got what you mean. But Linux seem to lack a mechanism to grant a user rights Except for some certain actions. It is either you give them a very limited whitelist, which do not require them to solve problems creatively, or give them the biggest right as root. Your demonstrations are how to do side-attacks to gain root privilege, which highlight the issue.

@GeorgeY If you give them the ability to solve problems creatively, they will have the ability to run lots of different commands, and chances are, one of those commands gives them root access accidentally. That's why you have to use a whitelist if you don't want them to have full root access.

@GeorgeY For example: You want them to be able to run ssh as root? Then they can "creatively" use something like cp /bin/bash ~/my_bash; sudo ssh -oProxyCommand="chown root:root /home/username/my_bash; chmod u+s /home/username/my_bash; #" foo@bar. Very creative! And now they can run bash as root.

@user253751 It seems a censorship in bash or in other related functionality is needed. SELinux seems not doing this job at all, to provide a "Root-Minus" role that can Never mock as root and kill certain sensitive services such as rsyslog.

@GeorgeY Well that's usually called not giving them the ability to run commands in the first place, except for the commands you want them to run. Any necessary creativity can be put in the user's own shell script that isn't running as root.

"you should acknowledge how vulnerable Linux really is" is like saying "I left the key in my ignition and Ford should acknowledge how vulnerable their cars really are". If you give people permissions, they can do things. Do not allow people "sudo bash" or wheel access if you don't want them to have complete control.

@GeorgeY no, Linux doesn't lack user privilege separation and granting mechanism. You just misunderstand and misuse them. You think sudo is the only mechanism, while it is actually a last resort mechanism, and also in many cases it is used only by tradition, not by requirement; there are plenty of ancient howtos, which don't account relatively modern features of Linux, which is rapildy evolving. For example, you can still easily find manuals who suggest ifconfig and route tools, which lack features and were deprecated around 20 years ago.

@user253751 Did you mean that a user can simply download a bash and then execute it to bypass it? Then disable chmod could help.

@GeorgeY by disabling chmod you are preventing creative problem solving!

@user253751 No. They can still run any script by simply sh [A Script]. It will not prevent them from running Python scripts either. It only prevents them from installing any new software or Trojan.

@GeorgeY well they can put the evil bad commands in their script then. Whatever you don't want them to do, they can just put it in their script and run the script as root. They could write a version of sh in shell script, and run it, now they are running sh as root. That would be quite creative.

@user253751 As long as the monitor program logs every command they entered, and the log is unchangeable by them - Every malicious doing would be route to jail!

they can just delete the monitor program and then reboot the computer

@user253751 See, you have come to my thinking - to avoid that scenario - Deprive their access to monitor program, make monitor program as enabled service, deprive their right to become root and kill that monitor program or edit the directory of monitor program and delete it.

@GeorgeY We have all been telling you that yes, you should deprive their right to become root. By definition root can do anything, including killing their monitor program. You only allow them to do certain things as root by only allowing them to run certain commands as root.

@user253751 You are going stubborn. What is wrong to demand a "Root-Minus" privilege if you hire someone to do the job, but at least keep the record on what they did? Why Do You Keep Defending the status-quo of Linux? Is it because you have the entire power as root but I am trying to deprive your chance to do something bad to your company?