Cuentas de seguridad de Servicios

Tradicionalmente los servicios en los sistemas operativos Windows anteriores a XP/2000 han tenido la opción de elegir ejecutarse o bajo el contexto de seguridad de LocalSystem o bajo cualquier cuenta de usuario arbitraria. La creación de cuentas de usuario para cada servicio se hace engorroso, especialmente por la administración de contraseñas de dichas cuentas. Debido a esto, casi todos los servicios locales se han configurado para ejecutarse como LocalSystem. El problema de esto es que LocalSystem es una cuenta con privilegios altos y rompiendo el servicio es frecuentemente un camino para conseguir un ataque de elevación de privilegios.

Muchos servicios no necesitan de un nivel elevado de privilegios, de ahí la necesidad de un contexto de seguridad de bajo nivel disponible en todos los equipos.

En Windows 2003 y XP los servicios se pueden ejecutar bajo los contextos siguientes:

  • Cuenta LocalSystem
  • Cuenta NetworkService (NT AUTHORITYNetworkService)
  • Cuenta LocalService (NT AUTHORITYLocalService)
  • Cuenta de usuario del dominio
  • Cuenta de usuario Local

El contexto de seguridad bajo el que un servicio se ejecuta afecta a los derechos de acceso que el servicio tiene en el equipo y en la red. El contexto de seguridad de un servicio es una consideración importante para los desarrolladores de servicios y los administradores del sistema ya que ello dictamina los recursos a los que el proceso puede acceder. A menos que el instalador de un servicio o un administrador especifiquen lo contrario, los servicios se ejecutan bajo el contexto de seguridad de la cuenta de LocalSystem (mostrado algunas veces como SYSTEM y otras como LocalSystem), que tiene características especiales.

Nota: Cambiar la cuenta bajo la que un servicio se ejecuta puede impedirle funcionar correctamente. Los administradores deben ser cuidadosos al cambiar la configuración de cuenta para un servicio. Muchos servicios están configurados para ejecutarse bajo la cuenta correcta y no funcionarán adecuadamente si se reconfigura. Algunos servicios necesitan una configuración de cuenta manual y de acuerdo con las recomendaciones de su desarrollador.

Manejadores de SCM

Service Control Manager es compatible con manejadores o puntos de entrada que permiten el acceso a:

  • La base de datos de servicios instalados.
  • Un servicio.
  • La base de datos de bloqueo.

La base de datos de servicios instalados está representada por un objeto contenedor interno que mantiene objetos servicio. Este manejador o punto de entrada se utiliza cuando se instalan, eliminan, abren y enumeran servicios y cuando se bloquea la base de servicios.

Un servicio instalado está representado por un objeto servicio. La solicitud de acceso se da o niega dependiendo del token de acceso del proceso de llamada y del descriptor asociado con el servicio u objeto interno. Este nivel de acceso se asocia entonces con todas las llamadas subsecuentes que usan este manejador. Si una de ellas necesita un nivel de acceso que no fue originalmente solicitado para el manejador, la llamada fallará, a pesar de si el usuario actual pudiera haber solicitado un manejador que permita dicho nivel de acceso. Una practica adecuada para clientes de las APIs de SCM es solicitar sólo el nivel de acceso que será necesario.

La base de datos de bloqueo está representada por un objeto bloqueado que se crea durante la inicialización de SCM para serializar el acceso a la base de datos de servicios. SCM adquiere el bloqueo antes del inicio de un servicio o controlador. De esta manera si un instalador ha adquirido un bloqueo, un inicio-por-demanda no podrá continuar hasta que el bloqueo se libere. Es importante para instaladores liberar el bloqueo tan pronto como puedan. Cualquier instalador que seguidamente intente adquirir el bloqueo recibirá un error ERROR_SERVICE_DATABASE_LOCKED, y lo reintentará al cabo de un tiempo corto de espera.

 

Registrando un servicio con SCM

Un programa que registra un servicio mediante la API CreateService realiza lo siguiente:

  1. El instalador del programa envía un mensaje al SCM en el equipo donde el servicio residirá.
  2. SCM crea una clave de registro para el servicio bajo HKLMSYSTEMCurrentControlSetServices. Las claves individuales para cada servicio definen la ruta de la imagen ejecutable que contiene el servicio, además de opciones de configuración y parámetros.
  3. Después SCM crea la clave del registro para el servicio, una instalación o administrador de aplicación puede iniciar el sevicio mediante la función StartService. Ya que algunos servicios basados en aplicaciones deben iniciarse durante el proceso de arranque para funcionar, no es usual que un programa de instalación registre un servicio como auto-start, la instalación se completará al reiniciar el equipo y dejar que SCM inicie el servicio del equipo reiniciado.

Los servicios auto-start tienen un impacto significante en el tiempo de arranque.