Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've tried

chmod 700 /bin/kill
chown root /bin/kill

but a normal user can still do:

kill blah

... and successfully kill the app 'blah' running under the user's account.

I'm using Ubuntu (8.10). The bash shell apparently has the kill command built-in and so attempting the above will not work.

Using .bashrc the enable command could be used to disable the built-in kill command each time a terminal is launched, but the .bashrc could then simply be edited by the user using a text editor launched via the GUI to re-enable the kill command. Can I somehow disable a built-in bash command permanently without using .bashrc (which is user-editable)?

Anyone any ideas how I can disable the built-in kill?

share|improve this question
2  
The important question here is: why do you want to disable kill? –  Juliano Nov 20 '09 at 20:20

4 Answers 4

up vote 14 down vote accepted

The answer is that short of compiling your own version of bash, you can't. Furthermore, even if you succeeded, if your users can compile programs or move binaries onto the system, they can always bring in a kill binary of their own, and be able to issue kills anyway.

Now, the question is: What do you really want to do? Because disabling the kill command isn't, I suspect, your actual goal. You're trying to prevent the users from doing something (presumably kill something they shouldn't), and there's probably a better way to do what you want.

share|improve this answer
10  
+1 for "give us the real question, not the incorrect solution". –  womble Nov 20 '09 at 17:34

Whatever you use, the kill command, or the shell builtin, it is going to use the kill or related system call. To read about this, see man 2 kill.

Kill isn't just use to kill a process, but it is used to send a signal. Sending signals is a fundamental function of the Unix operating systems, so you don't want to disable it.

The Correct Way:
The correct way to do what ever you are trying to do is probably to manage your privileges correctly. Signals are only allowed under the following conditions:

For a process to have permission to send a signal it must either be privileged (under Linux: have the CAP_KILL capability), or the real or effective user ID of the sending process must equal the real or saved set-user-ID of the target process.

If You Really Want to:
So, if you really really want to have users not be able to send signals to process that they start, I think you would have to setuid root the program, and have it change both the real and effective user id right after it starts to a less privileged user, as only root can change the real user id. An example program that does this is the login command. You have to be extremely careful programing these programs though, or you will create a big security hole.

share|improve this answer

Following on Michael's answer, it would be very, very hard to prevent a user from sending signals (which is what kill does) to a process running in that user's protection domain (i.e. running under that user's id). Likely, you would not really want to, since it would also prevent the user from terminating a runaway program, for example. Also, it could well break some chunk of your existing system.

As Michael said, you probably are trying to prevent a user from sending a signal to one or more specific processes, and the way to do that is to put those processes into a different protection domain, in other words run them under a different user id.

share|improve this answer

If you want to limit and lock down the things people can do with bash, then change them to the rbash (restricted bash) shell. more info

share|improve this answer
    
I don't see what restricted bash can do for limiting kill –  Evan Carroll Jan 21 '10 at 16:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.