PDA

View Full Version : Way to prevent SIGKILL




J::2
Mar 25, 2009, 01:21 PM
I want to make a Client-Server Application in which once a client Application is connected to Server, user at client side should not be able to terminate it unless permission is given by server.
Client side User should not be able to terminate Client Application by kill -9 <pid> or Force Quit from Activity monitor

I have trapped all other signals but not able to find a way to prevent SIGKILL to my Application ?

Any help would be really great Thanks



lee1210
Mar 25, 2009, 01:48 PM
You are going to have a very hard time telling someone they can't kill something on their own machine. The best bet would be to have it run under init (or launchd, i think that's the more Appley way to do things) as root on startup. That way regular users can't just kill it (unless they sudo kill it, but again, if the user has root on the machine, you're not going to stop them from killing anything).

-Lee

J::2
Mar 25, 2009, 01:53 PM
Hi Lee

Thanks for Reply

I cant launch that Client at startUp , it should be started just like any other application by double click

notjustjay
Mar 25, 2009, 02:17 PM
It is not possible to ignore a SIGKILL (unless you are the init process). That is part of the definition of SIGKILL:

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.


If there is something you need to prevent the user from being able to interrupt, I suggest you need to rethink how your program is designed and come up with some fail-safe algorithms, including the possibility of a separate monitor process that monitors the health of the "unkillable" process and creates a new one to replace it and resume its operation if killed.

And remember that any "uninterruptable" process can still be shut down by powering off the box...

Otherwise, you're looking at modifying the kernel.

Cromulent
Mar 25, 2009, 03:00 PM
One of the definitions of malware is that it hijacks a computer and stops a user from quitting it. I'm not suggesting that is what you are trying to do, but users will equate a program that does that to malware whether it is or is not actually malware.

autorelease
Mar 25, 2009, 05:09 PM
You can't. Period.

There are certain conditions in which a process might not terminate when sent SIGKILL; for example, if it's a zombie or if it's blocked waiting for a neverending I/O operation. However, a process can't do anything in these states, so it's not possible to have a process performing computation and not responding to signal 9.

Rethink your architecture.

iSee
Mar 25, 2009, 05:38 PM
What are you trying to accomplish?
Perhaps we can help you adjust the design of your app so you don't need to block SIGKILL.

J::2
Mar 26, 2009, 12:22 AM
I want to create an Application that is once connected to some Remote Application using TCP Port then Users at Local Machine should not be able to terminate it in any way(includes SIGKILL and Force Quit...) unless it is allowed from Remote Machine.

notjustjay
Mar 26, 2009, 12:36 AM
You haven't explained WHY you require this behaviour. Will something bad happen if the client quits before the server is ready to let it go? Remember that the internet connection could drop, there could be a power outage, the user could trip on the cord and unplug the computer, the computer could crash, there are still any number of scenarios in which the connection between the client and server could be disconnected even if you were able to ignore a Force Quit or SIGKILL.

Since there's no way you can prevent it from happening, the next best thing is to make sure your architecture is such that there will be no damage, data loss, or ill effects from this occurring.

What does your client/server application do, anyway?

J::2
Mar 26, 2009, 12:54 AM
Remember that the internet connection could drop, there could be a power outage, the user could trip on the cord and unplug the computer, the computer could crash, there are still any number of scenarios in which the connection between the client and server could be disconnected even if you were able to ignore a Force Quit or SIGKILL.


Yes that is considered,it is fine if any of the above mentioned scenarios takes place.Client side user can kill Application in these cases.

But if everything works fine and client is connected to server, then Client side user should not be able to terminate Application by any way

gnasher729
Mar 26, 2009, 04:34 AM
I want to create an Application that is once connected to some Remote Application using TCP Port then Users at Local Machine should not be able to terminate it in any way(includes SIGKILL and Force Quit...) unless it is allowed from Remote Machine.

That is ridiculous. If it is a desktop machine, I unplug the power cable. If it is a laptop, I take it 50 meters away from my wireless router. So what is your server going to do about that?

As soon as a customer figures out they can't quit an application, you have one very, very angry ex-customer. Talk to a lawyer whether preventing a user from controlling their own computer in this way might be considered a crime, it might quite well fit several anti-hacking laws.

And you keep answering the wrong question. Why do you want to do this nonsense?

J::2
Mar 26, 2009, 07:46 AM
It is allowed to kill that Application using sudo Kill command but should not be killed by kill -9

I am assuming user should not be knowing the root password.

Is there any way to do so?

Cromulent
Mar 26, 2009, 08:01 AM
It is allowed to kill that Application using sudo Kill command but should not be killed by kill -9

I am assuming user should not be knowing the root password.

Is there any way to do so?

Yes, have the application run as root (probably as a daemon started by launchd).

J::2
Mar 26, 2009, 08:10 AM
But the application is not required to launch at StartUp but as usual application by double click

So in this case, I can have my application to be launched by double click as root

Is there any way to do so? It should not require Root Password when launched

janil
Mar 26, 2009, 08:21 AM
Is there any way to do so? It should not require Root Password when launched

That's a security violation.. the same thing viruses and other malware apps want to do. If you could do what you wish, without a password, then any random application could do the same.

Why do you want to introduce dangerous behavior that would open up OS X to exploits?

notjustjay
Mar 26, 2009, 08:27 AM
Well folks, I'm done here. The poster signed up an account on MacRumors just to ask these questions, has no previous posting history, and is being evasive about why they want to write an unstoppable app which could potentially be a virus or other malware.

Until we get more details on what exactly is going on, I'm not offering any more help.

Cromulent
Mar 26, 2009, 08:31 AM
Well folks, I'm done here. The poster signed up an account on MacRumors just to ask these questions, has no previous posting history, and is being evasive about why they want to write an unstoppable app which could potentially be a virus or other malware.

Until we get more details on what exactly is going on, I'm not offering any more help.

I think you are most likely right. It sounds a lot like he is trying to write a Trojan or other such application.

lee1210
Mar 26, 2009, 08:34 AM
Is there any way to do so? It should not require Root Password when launched

Authorization services require the user's password, not the root password. Is this acceptable? If so, even though i think it's a very bad idea, you could have a wrapper run, use Authorization Services to escalate permissions, then run another process as root which would be safe from the user killing it. Again, i don't think this is a good approach, but would be possible.

As others have said, i think this design doesn't make sense, and you have not explained at all why you need this behavior. If a user starts an application they damn well better be able to stop it. If it is a system service, this is not the case, which is why i suggested it originally.

There may be ways to achieve what you want with setuid, but understand that this is designed to empower a user to run something with higher permissions, not keep them from stopping it.

The real moral here is what you want to do, even if possible, is the wrong decision. There have been many requests for you to explain what specifically you're needing to do, and why you think preventing the user from killing the program is the right way to achieve it. If you do, we may be able to help more.

-Lee

J::2
Mar 26, 2009, 09:02 AM
It is a Process inspector Application in which a Server wants to log processes running on client machines. Once client is connected to Server, Client Application should not be closed by user at client side to that it can hide its processes from logging at Server.

I think now it will become clear.

Sorry for all trouble.

Please help.:)

lazydog
Mar 26, 2009, 09:06 AM
Well you could get the server to ssh into your client and run it's process monitor program itself. You would need to create a user account for the server on the client and set up ssh keys etc.

b e n

Cromulent
Mar 26, 2009, 09:10 AM
It is a Process inspector Application in which a Server wants to log processes running on client machines. Once client is connected to Server, Client Application should not be closed by user at client side to that it can hide its processes from logging at Server.

I think now it will become clear.

Sorry for all trouble.

Please help.:)

That sounds almost exactly the kind of thing a daemon is best suited too if you ask me.

Just have it send out reports say once an hour or something or less.

savar
Mar 26, 2009, 09:58 AM
But the application is not required to launch at StartUp but as usual application by double click

So in this case, I can have my application to be launched by double click as root

Is there any way to do so? It should not require Root Password when launched

Whatever you're trying to do, you're not going to be able to do it.

1) You're trying to do something either illegal, or at the very least extremely annoying to your "users".
2) You clearly do not possess a good technical understanding of application programming anyway.

And yet, like a car wreck, here I am... rubbernecking through the rest of the thread.

lee1210
Mar 26, 2009, 10:15 AM
If this is legitimate, there are a lot of other ways to handle this. If you don't trust your users not to kill something, why trust them to run it in the first place?

The suggestion of running the command with ssh -c from a remote system and reaping the results on some interval seems like a pretty good one. You could also schedule a task in the root processes cron to do the monitoring, etc. If you need to absolutely know in real time when a process goes down, you'd have to run this as a root-owned background process that starts with the system. What will monitor this process, though? Are you sure you will write something bullet-proof that can run for years without dying?

-Lee

antibact1
Mar 26, 2009, 10:15 AM
Probably some crazy parent trying to monitor what their teen with a little bit of computer knowhow is doing.

GorillaPaws
Mar 26, 2009, 10:29 AM
Probably some crazy parent trying to monitor what their teen with a little bit of computer knowhow is doing.

Or could it be an app that companies can install to make sure their employees are doing what they're supposed to?

antibact1
Mar 26, 2009, 10:31 AM
Or could it be an app that companies can install to make sure their employees are doing what they're supposed to?

In either case, instead invest in a firewall with a content filtering proxy.

notjustjay
Mar 26, 2009, 10:32 AM
Probably some crazy parent trying to monitor what their teen with a little bit of computer knowhow is doing.

Or could it be an app that companies can install to make sure their employees are doing what they're supposed to?

In this case, the deliberate killing of the monitor thread provides just as much information to the monitor... e.g. "this guy's hiding something, better scrutinize further!"

lazydog
Mar 26, 2009, 10:32 AM
Or could it be an app that companies can install to make sure their employees are doing what they're supposed to?

Yes, I've seen this before. A friend did some contract work from home for a large company. As part of his contract they lent him a laptop which he had to use to connect to their server and systems. All the time he was logged on a background task logged everything he did.

b e n

J::2
Mar 26, 2009, 11:05 AM
Or could it be an app that companies can install to make sure their employees are doing what they're supposed to?

Finally someone got it,

The only thing I dont want it to be launched at start up and want it to be launched like any other application

Cromulent
Mar 26, 2009, 11:22 AM
Finally someone got it

You were not exactly helpful though.

notjustjay
Mar 26, 2009, 11:26 AM
Finally someone got it,

The only thing I dont want it to be launched at start up and want it to be launched like any other application

Then launch it at startup and have it set to do nothing, until activated by a program the user can launch.

Seriously, what's up with the cloak and dagger?

GorillaPaws
Mar 26, 2009, 12:17 PM
In this case, the deliberate killing of the monitor thread provides just as much information to the monitor... e.g. "this guy's hiding something, better scrutinize further!"

If this guy is being truthful (I'm still very suspicious), then your strategy is the way to to go about doing this. If I have a security camera in my store because I'm worried my employees are stealing from the drawer, catching her stealing on camera is just as good as catching her putting a sticker over the camera lens (she's fired either way in other words).

The OP should focus his efforts less on circumventing important system functions and more on logging efforts to circumvent his application's monitoring processes.

iSee
Mar 26, 2009, 12:47 PM
Finally someone got it,

The only thing I dont want it to be launched at start up and want it to be launched like any other application

It took so long because you've been making us guess.

Anyway, as many people have suggested, you *do* want a launchd deamon (aka a service), running in the background, reporting the user's process activity. And, do not provide administrator accounts to the users.

J::2
Mar 27, 2009, 02:07 AM
It took so long because you've been making us guess.

Anyway, as many people have suggested, you *do* want a launchd deamon (aka a service), running in the background, reporting the user's process activity. And, do not provide administrator accounts to the users.

But Daemon show no UI and I want to make it GUI so that I can chat with the subordinates at same time

Also can I launch a process from a any User account that can be killed only by sudo kill ( that requires root password )?

I don't want it to be start up Process

Cromulent
Mar 27, 2009, 05:35 AM
But Daemon show no UI and I want to make it GUI so that I can chat with the subordinates at same time

Then make a GUI application as well. You don't have to do everything in one application, you can split tasks between them.