UNIT 1

Introduction to System Services

J. Álvarez M.
Instituto Profesional DUOC UC
Semestre 1 - 2011
 Objetivos
• Comprender como son administrados los
servicios.
• Aprender acerca de los rasgos distintivos
comunes entre servicios.
• Introducir los métodos de análisis de fallas de
servicios.
 Agenda
• Conceptos de administración de servicios.
• Administración de servicios System V.
• Servicios administrados por xinetd.
• Los archivos /etc/sysconfig.
• Análisis de fallas.
 Administración de Servicios
• Los servicios son administrados de varias
maneras:
 por init
 por scripts System V
 por comandos directos
 Por xinetd
 Servicios administrados por init
• Típicamente servicios no-TCP/IP, por ejemplo,
dial-in modems.
• Servicios que involucran dial-in modems o
puertos seriales (por ejemplo, terminales
tontos) están bajo control de init.
• Provee capacidades de respawn – init puede
automáticamente respawn un programa que
termina.
 Servicios administrados por init
• La administración del sistema X Window en
run level 5 es un ejemplo de este tipo de
servicio.
• Configurados en /etc/inittab.
Administración de servicios System V
• Los procesos son “wrapped” (envueltos) por
los scripts de inicialización System V.
• Mas que un script, a menudo son usados
varios archivos de configuración, por servicio.
• Algunos servicios tiene mas de un demonio
(daemon) administrado por el script service.
• El nombre del script y el nombre del demonio
que lo inicia a menudo son similares, pero no
siempre es así.
Administración de servicios System V
• La invocación del script del servicio puede ser
realizada directamente, o bien a través del uso
del comando service, por ejemplo:
/etc/init.d/cups start o bien service cups
start.
• El comando service es un “wrapper of
wrappers”.
 chkconfig
• Administra de definición de servicios a nivel
de runlevels.
• Por ejemplo, para iniciar el servicio cups en el
booteo: chkconfig cups on.
• chkconfig no modifica el estado de ejecución
actual de los servicios System V.
• Se pueden listar las definiciones de los
runlevels con: chkconfig --list.
 chkconfig
• Usando chkconfig una definición de servicio
persiste a través de los reboots.
• chkconfig también administra servicios xinetd.
#chkconfig cups --list
cups 0:off 1:off 2:off 3:on 4:off 5:on …
• El comando chkconfig <service> on habilita
por defecto el servicio en los runlevels 2, 3, 4
y 5.
 chkconfig
• El comando chkconfig <service> off
deshabilita el servicio en los runlevels 2, 3, 4 y
5.
• El comando chkconfig <service> --add asegura
que un enlace simbólico kill o start es definido
para cada runlevel.
• El comando chkconfig <service> --del
remueve un servicio desde la administración
de chkconfig.
 chkconfig
• Por ejemplo, para “parar” el servicio nscd en
los runlevels 3, 4 y 5, se utilizaría el siguiente
comando:
#chkconfig --level 345 nscd off
Servicios administrados por xinetd
• Los servicios son iniciados por xinetd en
respuesta a requerimientos entrantes.
• xinetd es también administrado por un script
System V. El monitorea los puertos usados por
todos los servicios bajo su cuidado, y inicia
servicios en respuesta a conexiones entrantes.
• chkconfig activa/desactiva servicios xinetd
instalados: chkconfig cups-lpd on.
• Archivos en el directorio /etc/xinetd.d/.
 El demonio xinetd
• Administra recursos específicos de red y
autenticación: servicios necesitados menos
frecuentemente, autenticación basada en
hosts, servicios estadísticos y de logging,
servicios de redirección de IP.
• Reemplaza a inetd.
• Linkeado con libwrap.so.
• Archivos de configuración: /etc/xinetd.conf,
/etc/xinetd.d/service.
 El demonio xinetd
• La configuración instalada por defecto de
xinetd es provista por el archivo de
configuración de alto nivel /etc/xinetd.conf y
archivos para servicios específicos bajo el
árbol de directorio /etc/xinetd.d/.
• Los servicios que son necesitados menos
frecuentemente, o que requieren
administración de recursos adicionales, son
típicamente controlados por xinetd.
 El demonio xinetd
• xinetd en RHEL (Red Hat Enterprise Linux) es
compilado con soporte libwrap, esto causa
que xinetd chequee por los nombres de todos
los servicios soportados en host.allow y
host.deny.
• Más información puede ser encontrada en
http://www.xinetd.org.
 xinetd default controls
• Archivo de configuración de alto nivel:
/etc/xinetd.conf.
• El archivo de configuración /etc/xinetd.conf
define las opciones de configuración globales
compartidas por todos los servicios
administrados por xinetd.
• También provee el path a configuraciones de
servicios específicos.
 xinetd default controls
• Un ejemplo de configuración por defecto de
/etc/xinetd.conf se muestra a continuación:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
 xinetd service controls
• Configuración de servicios específicos:
/etc/xinetd.d/<service>.
 Archivos /etc/sysconfig
• Muchos archivos bajo /etc/sysconfig
describen configuración de hardware; sin
embargo, algunos de estos archivos
configuran parámetros de servicios run-time.
• Algunos servicios son configurados por como
ellos corren: named, sendmail, dhcpd, samba,
init, syslog.
 Fault Analysis
• Determinar la severidad de la falla: Cuando se
está analizando una falla de servicio (o del
sistema), se debe considerar su severidad.
Mirar y leer los mensajes de error desplegados
cuando se presenten.
• Estos mensajes pueden ser incluidos en un
archivo de log, y a menudo describen el tipo
de falla encontrado.
 Fault Analysis
• Los sistemas operativos pueden fallar, o el
hardware del sistema. También es posible,
pero raro, que una combinación de estas
causas potenciales pueda ocurrir al ismo
tiempo, sin embargo, un sector malo en disco
(hardware) puede resultar en malos datos
(alguna parte de un archivo de configuración),
que puede resultar en una falla de programa
al iniciar.
 Fault Analysis
• Inspeccionar los archivos de logs antes que los
archivos de configuración.
• Usar opciones de comandos para depurar
(debugging).
• Documentar la investigación.
 Security-Enhanced LINUX
• Security-Enhanced Linux (SELinux), es una
característica de seguridad de LINUX que provee
una variedad de políticas de seguridad, a través
del uso de los módulos de seguridad LINUX
(LSM) incluidos en el kernel LINUX.
• SELinux fue desarrollado por NSA (National
Security Agency), como un proyecto de
investigación. LINUX fue elegido debido a que es
open source, y por lo tanto es más fácil probar la
tecnología.
 Security-Enhanced LINUX
• El LINUX tradicional deja el control de acceso
al usuario. El usuario decide quien puede
accesar sus archivos, basado en membrecía de
grupos. Con la opción ACL activada en el
filesystem, los usuarios pueden afinar de gran
manera este control. Sin embargo, si un
atacante toma el control de la cuenta, puede
cambiar estas opciones.
 Security-Enhanced LINUX
• SELinux proporciona un sistema flexible de
Control de Acceso Obligatorio (Mandatory
Access Control, MAC) incorporado en el
kernel.
• Al ejecutar un kernel SELinux MAC se protege
al sistema de aplicaciones maliciosas o
dañinas que pueden perjudicar o destruir el
sistema.
 Security-Enhanced LINUX
• SELinux permite definir el acceso y los
derechos de transición de cada usuario,
aplicación, proceso y archivo en el sistema por
medio de MAC.
• Con MAC, dejamos que el administrador de
seguridad decida “quién puede hacer qué
sobre cuáles archivos”.
 El Proceso de Toma de Decisión de
SELinux
• Cuando un sujeto (por ejemplo, una
aplicación), intenta acceder a un objeto (por
ejemplo, un archivo), el servidor de la
aplicación de políticas en el kernel chequea un
vector de acceso en caché (AVC). Si una
decisión no se puede hacer basada en los
datos en el AVC, la petición continúa hacia el
servidor de seguridad, el cual mira el contexto
de seguridad de la aplicación y el archivo en
una matriz.
 El Proceso de Toma de Decisión de
SELinux
• El permiso es entonces concedido o denegado
a continuación, con un avc: denied message
detallado en /var/log/messages si el permiso
es denegado. El contexto de seguridad de
sujetos y objetos es aplicado desde la política
instalada, que también proporciona la
información para poblar la matriz del servidor
de seguridad.
El Proceso de Toma de Decisión de
SELinux
 Terminología usada en SELinux
• Los siguientes términos aparecen
frecuentemente nombrados, y constituyen los
términos fundamentales de SELinux: Identidad,
dominio, tipo, rol, contexto de seguridad,
transición y política.
• Identidad – Una identidad bajo SELinux NO es lo
mismo que el tradicional UID. Las Identidades
bajo SELinux forman parte de un contexto de
seguridad que afectará los dominios que pueden
ser accesados, es decir, afectará lo que se puede
realizar.
 Terminología usada en SELinux
• Dominio – Cada proceso se ejecuta en un
dominio. Un dominio directamente determina
el acceso que un proceso tiene. Un dominio es
básicamente una lista de lo que pueden hacer
los procesos, o que acciones un proceso
puede realizar sobre tipos diferentes.
 Terminología usada en SELinux
• Tipo - Un tipo se asigna a un objeto y
determina quién puede acceder a ese objeto.
La definición de dominio es prácticamente la
misma, excepto que un dominio se aplica a los
procesos y un tipo se aplica a objetos tales
como directorios, archivos, sockets, etc.
 Terminología usada en SELinux
• Rol - Un rol determina qué dominios se
pueden utilizar. Los dominios que un rol de
usuario puede tener acceso están
predefinidos en los archivos de configuración
de la política. Si un rol no está autorizado a
entrar en un dominio (en la base de datos de
políticas), entonces se puede denegar.
 Terminología usada en SELinux
• Example:
• In order to allow a user from the user_t
domain (the unprivileged user domain) to
execute the passwd command, the following
is specified in the relevant config file:
• role user_r types user_passwd_t It shows that
a user in the user role (user_r) is allowed to
enter the user_passwd_t domain i.e. they can
run the passwd command.
 Terminología usada en SELinux
• Contexto de seguridad – Un contexto de
seguridad tiene todos los atributos que se
asocian con cosas como archivos, directorios,
sockets TCP, etc. Un contexto de seguridad
está formado por la identidad, el rol y el
dominio o el tipo. Es posible revisar su propio
contexto de seguridad actual mediante la
ejecución del comando id bajo SELinux.
 Terminología usada en SELinux
• Transición – Una decisión de transición, también
conocida como una decisión de etiquetado,
determina qué contexto de seguridad será
asignado a una operación solicitada. Hay dos
tipos principales de transiciones: En primer lugar,
hay una transición de dominios de proceso
utilizado cuando se ejecuta un proceso de un tipo
especificado. En segundo lugar, hay una
transición de tipo de archivo utilizada cuando se
crea un archivo bajo un directorio en particular.
 Terminología usada en SELinux
• Políticas – Las políticas son un conjunto de
normas que regulan aspectos como los roles
que un usuario tiene acceso a, qué roles
pueden entrar en que dominios y qué
dominios pueden acceder a que tipos.
Archivos relacionados con SELinux
• El pseudo-sistema de archivos /selinux/
contiene los comandos que son más
comúnmente utilizados por el subsistema del
kernel.
• /selinux/ es similar al también pseudo-
sistema de archivos /proc/.
• Administradores y usuarios normalmente NO
necesitan manipular estos componentes.
Archivos relacionados con SELinux
• El siguiente ejemplo muestra el contenido del
directorio /selinux/:
Archivos relacionados con SELinux
• Existen dos maneras de configurar SELinux
bajo RHEL: usando la Security Level
Configuration Tool (system-config-selinux), o
manualmente, editando el archivo de
configuración /etc/sysconfig/selinux.
• El archivo /etc/sysconfig/selinux es el archivo
de configuración primaria para habilitar o
deshabilitar SELinux.
Archivos relacionados con SELinux
• Debemos notar que el archivo
/etc/sysconfig/selinux contiene un enlace
simbólico al actual archivo de configuración
/etc/selinux/config.
• Las siguientes son las opciones disponibles
para configuración:
 SELINUX=enforcing | permissive | disabled
 SELINUXTYPE=targeted | strict
Archivos relacionados con SELinux
 SETLOCALDEFS=0 | 1
• El directorio /etc/selinux es la localización
primaria para todos los archivos de políticas
así como el archivo de configuración principal.
• El siguiente ejemplo muestra el contenido del
directorio /etc/selinux/:
Archivos relacionados con SELinux
• Los dos subdirectorios , strict/ y targeted/,
son los directorios específicos donde los
archivos de políticas del mismo nombre (esto
es, strict y targeted) están contenidas.
 Administración de SELinux
• Además de las tareas a menudo realizadas por
usuarios, los administradores SELinux
deberían ser capaces de realizar una cierta
cantidad de tareas adicionales.
• Estas tareas típicamente requieren acceso
como root al sistema.
• El comando sestatus provee una vista
configurable acerca del estado de SELinux.
 Administración de SELinux
[root@localhost ~]# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
 Administración de SELinux
• La opción –v incluye información acerca de los
contextos de seguridad de una serie de
archivos que son especificados en
/etc/sestatus.conf.
[root@localhost ~]# sestatus -v
• La opción –b despliega el estado actual de
algunas variables booleanas.
[root@host2a ~]# sestatus -b ¦ grep httpd ¦
grep on$
 Administración de SELinux
• Podemos habilitar/deshabilitar SELinux
enforcement en tiempo de ejecución o
configurarlo para que inicie en el modo
correcto en tiempo de booteo, usando el
comando setenforce.
• SELinux puede operar en uno de tres modos
posibles: disabled, permissive o enforcing.
• Disabled indica que no está habilitado en el
kernel.
 Administración de SELinux
• Permissive indica que SELinux está corriendo
y logeando pero no está controlando los
permisos.
• Enforcing indica que SELinux está corriendo y
haciendo cumplir las políticas.
• El comando setenforce permite cambiar entre
los modos permissive y enforcing en tiempo
de ejecución.
 Administración de SELinux
• Se usa setenforce 0 para entrar a modo
permissive y setenforce 1 para entrar a modo
enforcing.
• El comando setstatus despliega el modo
actual y el modo referenciado desde el archivo
de configuración durante el booteo:
[root@localhost ~]# setstatus ¦ grep –i mode
Current mode: permissive
Mode from config file: permissive
 Administración de SELinux
• Notar que cambiando el enforcement en
tiempo de ejecución no afecta la configuración
en tiempo de booteo:
[root@localhost ~]# setenforce 1
[root@localhost ~]# setstatus ¦ grep –i mode
Current mode: enforcing
Mode from config file: permissive