How do I prevent users from terminating a service?

A customer asked (via their customer liaison), "We wrote in-house Windows service that is set to auto-start when the user logs in. How can we prevent the user from terminating it in Task Manager, or at least have the service auto-restart if it is terminated?"

Services have access control lists. If you don't want a service to let users terminate it, then set the access control on the service so that users don't have the permissions you don't like, and have the service run under an account that users don't have access to. You can change the access control list the command line way or the fancy GUI way. I'm sure there are corresponding commands and GUI dialogs for changing the account the service runs under; I'll leave you to find them.

From a technical side, a service can prevent itself from being stopped by simply ignoring the Stop notification, although a service that did that is basically making itself harder to be managed. And as for restarting after termination, there are a variety of options available on the Recovery tab in the Services MMC snap-in.

But we were rather baffled by this question, however, because the default security settings for services do not let unprivileged users start and stop them, and they run under accounts that normal users do not have access to. Normally, the only users who can stop or terminate services are administrators. And you can't defend yourself from administrators because they are already on the other side of the airtight hatchway: Any setting you set to thwart the adminitrator, the administrator can simply reset.

The customer liaison clarified that the customer wanted to prevent both normal users and administrative users from terminating the service. If administrators cannot be blocked, they will inform the customer of that.

So let's say it again: You can't stop administrators from doing things to the local computer, because they are administrators. As I noted, administrators are already on the other side of the airtight hatchway.

If you are interested only in preventing standard users from stopping or terminating a service, then the usual service permissions should do the trick.

Comments (19)
  1. Damien says:

    I once encountered a clever attempt to stop administrators from stopping a service – a set of 5 (IIRC) services that were implementing a mutual anti-suicide pact. They were monitoring each other in a ring and as soon as one disappeared, the next/previous in line would start it the missing one again.

    As you say, ultimately the administrator can win – we actually wanted these services so didn’t just remove all of them during the next startup – so got very used to having to pause all of the services before killing any of them.

    1. Karellen says:

      That reminds me of Robin Hood and Friar Tuck –

  2. Martin Ba. _ says:

    I’m not sure whether I find this post “willfully ignorant” :-)

    Sure, given (local?) Admin Rights, I can do pretty much anything, *given enough time and Google Search Foo*.

    On the other hand, it does seems my AV solution manages just fine to prevent me to kill it, even though I *am* local admin. (Because you can’t use a dev box with some tools +10yrs old without local admin rights.)

    So it seems reasonable enough for me to look for a modest garden fence, even against local admins. (Against normal users, the default concrete wall works anyway.)

    1. AV software tends to defend its processes fairly rigorously since they’re often targeted by the viruses that they’re supposed to protect you from. :-) That said, as an administrator you could uninstall the program, change the ACLs on the executable to prevent it from running, suspend the executable, or break in with a debugger and force it to terminate. Or tell the AV service to stop, since most AV software runs as a service anyway.

      1. Dmitry says:

        Modern viruses are using fairly advanced social engineering to trick users to accept UAC and gain home admin privileges. Enterprise solutions have to deal with users that already have local admin privileges and google at hand. So, AV software must protect itself from elevated “net stop avservice”, and they are going really far to use most advanced rootkit technologies available.

        1. skSdnW says:

          There are several UAC bypass tricks that work when UAC is in the default mode, as long as Windows thinks it is a Windows action there is no dialog to deal with…

    2. Ken Hagan says:

      Once upon a time, we had some AV software that had made some effort to stop local administrators from stopping it. (I didn’t look too hard because it was company policy to leave it running and presumably even if I could stop it I wouldn’t be able to hide the fact that it wasn’t running anymore.) However, the rest of the package was so badly written that if you tried to scan a file using their nifty shell extension, the background service would crash. *That* stops a service, no matter what. :)

  3. The MAZZTer says:

    > How do I prevent users from terminating a service?

    My first thought was this was going to be about users who call in to customer support to cancel their service only to be given the runaround.

    1. Brian_EE says:

      [Big Cable Company] who wasn’t allowed to merge with [Other Big Cable Company] a few years back has a monopoly on preventing users from terminating service. Lot’s of [big online video site] videos you can watch/listen to.

  4. Ben Voigt (Visual Studio and Development Technologies MVP with C++ focus) says:

    I interpreted it as the customer misusing the term “service”, based on “set to auto-start when the user logs in”. Real services running in service accounts don’t care about mundane problems like how many users are logged in, and definitely should not be assuming a singular user. So it seemed like the customer is actually talking about a GUI process running within each user login session for the duration of that session, possibly communicating with a true service to perform privileged operations, possibly just acting inside the account. Those processes typically are subject to manipulation by the user whose account is logged in.

  5. Seva says:

    Could be a case of domain admins restricting local ones. There’s another airtight hatchway there, on the domain level.

    1. warrens says:

      In terms of working with Active Directory schema, contents, etc., sure….. but Domain Admins don’t have a higher privilege level on desktops / member servers than an a user in the local Administrators group. Anything a Domain Admin does, a local Administrator can undo, up to and including leaving the domain.

      1. Joshua says:

        Ah good somebody has learned that “Domain Admin >> Local Admin” isn’t really true for the box that has local admin. GPO-knockout tools probably will get classified as hacktools if they weren’t so rare. [They] classified netcat as a hacktool.

        1. Dmitry says:

          There is no point to leave domain. You will loose access to domain resources, but gain nothing compared to safe boot mode.

      2. Alex Cohn says:

        Except if the local admin stops the service that the domain admin considers critical, the latter can get a notice from the monitoring service and send an administrative (in the pre-computer sense) order to restart the service promptly.

  6. tiraniddo says:

    Of course there’s things like Protected Process Light which _should_ stop an admin from stopping the service (although you need an ELAM cert which most companies probably can’t get). Of course while in theory stopping a PPL service will fail as an admin from user mode it’s really a total lie and it’s trivial for an admin to stop a PPL service even without resorting to a kernel driver. You wonder why go to the effort of building it if it really has so little benefit (other than being user hostile, although perhaps that was the point)?

    1. Joshua says:

      Is there a way to turn this boneheaded behavior off? We’ve had too many cases of Windows Defender process going runaway.

  7. Generally true, except that most AV services cannot be stopped, even by a local administrator. Not that the admin can’t do other things equally damaging, like uninstalling the service… but clearly some sort of middle ground was discovered… my guess (since I never had to investigate further, since I could just uninstall), was exactly as you said – the ACLs were modified for that service, to only include SYSTEM or something similar… but for the sake of this article it’d be interesting to identify.

    1. skSdnW says:

      I would imagine AV software to be more evil than that, they are probably block/modifying access rights in kernel mode when apps call OpenProcess and the service API.

Comments are closed.

Skip to main content