16

I'm working on a password manager application, and for security reasons I want to launch an unkillable process.

And besides I don't want this program to be a daemon since I need to read from standard input and write to it.

Is there a way to do this?

Improve this question
8
  • 11
    " for security reasons I want to launch an unkillable process." Just a note - if this was allowed, people could easily be exploiting it for nefarious reasons - e.g., launch an unstoppable fork bomb. Commented Sep 4, 2015 at 19:22
  • 34
    This sounds like an XY problem. I suspect that whatever you are really trying to achieve, an unkillable process is not the way to do it. "For security reasons" is very vague. What exactly do you want to prevent the user from doing? What access do they have? Commented Sep 4, 2015 at 19:30
  • 5
    Any process which is unkillable for all intents and purposes is a virus. Commented Sep 4, 2015 at 22:06
  • 3
    @NateEldredge: Rather, have the program ignore the signals. That's the typical way to do it; otherwise, someone could send a SIGINT or SIGTSTP directly to the process, bypassing the terminal. Commented Sep 4, 2015 at 23:26
  • 2
    @NoahSpurrier: I am imagining a situation where you have a user who can type things on the console, but who can't otherwise execute code on the computer (like a kiosk). You set it up so that no key that they can type will have an unexpected effect. If they can execute other code, then ignoring SIGINT and SIGTSTP and SIGQUIT doesn't help; anyone who could send those signals directly to the process could also send SIGKILL or SIGSTOP which you can't ignore. Commented Sep 5, 2015 at 17:10

3 Answers 3

Reset to default
41

Make the password manager run under a separate user and handle/ignore/block terminal-generated signals (SIGINT, SIGQUIT, SIGHUP, SIGTSTP, SIGTTIN, and SIGTTOU).

You can't send signals to (=kill) processes run under a different user (user whose both real uid and saved-set uid is different from your effective uid) unless your effective id is 0 (root).

All processes will still be killable by root.

For closer details, see kill(2).

Improve this answer
15

The only way to make a process unkillable is to implement it as a kernel thread, which is not something trivial.

You can still kill it but that would be an OS shutdown collateral damage.

You might also develop a custom kernel module that would set the SIGNAL_UNKILLABLE flag to your process. This flag is designed to be only set for init (or systemd, whatever initial process the kernel launch) which are the only userland processes protected against an unconditional kill but nothing seems to forbid that flag to be present for a regular process.

Improve this answer
5
  • 1
    it could be the init process Commented Sep 4, 2015 at 22:30
  • @muhmuhten You are right, init is a userland process being protected against an unconditional kill. It is however not designed to be customized while there is definitely an API for kernel modules and threads. Commented Sep 4, 2015 at 22:54
  • To elaborate on my own answer, I am assuming that you don;t have access to a root account (which, incidentally, hints this is either a toy example, a course project or malware). The precludes the idea that you could wire a kernel module for that purpose. Also note that the SIGNAL_UNKILLABLE flag is not available for normal processes and precludes some important normal operations (such as vforking) and so I would regard it as an normally-impractical edge case. Commented Sep 5, 2015 at 2:13
  • @jlliagre indeed, it is not. Commented Sep 5, 2015 at 5:54
  • @dudek An unkillable process is already an normally impractical edge case. Commented Sep 5, 2015 at 8:45
11

Technically, there is no way for a user to make a process unkillable.

Of course, for non-root users they can only kill processes that have the same user ID that they do, so if you can make different accounts you can use a "unique" user ID for the process and then only root could kill it.

A simple, but less robust, solution is to have your process catch as many signals as possible (perhaps ignoring them). This is only suitable for toy examples or non-adversarial environments since there is no way to catch the KILL signal (signal 9), but otherwise you can avoid being killed by them.

Finally, you can arrange to have your process respawn if killed. This is also fragile, but will make it a bit harder to expunge. This can be accomplished using a monitor process of your own, or using inittab. For an adversary who knows what they are doing, this can be circumvented by killing multiple processes at once.

Improve this answer
2
  • 1
    But (other than inittab) it's possible the monitor process could also be killed, no? Commented Sep 4, 2015 at 15:05
  • No, device drivers (kernel modules) can create processes which cannot be killed by root. Commented Sep 4, 2015 at 23:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.