UNIT 1 Introduction to System Services

1. UNIT 1IntroductiontoSystemServices J. Valenzuela A. Instituto Profesional DUOC UC Semestre 1 - 2014

2. 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.

3. Agenda • Conceptos de administración de servicios. • Servicios administrados por init. • Administración de servicios System V. • Servicios administrados por xinetd. • Los archivos /etc/sysconfig. • Análisis de fallas. • Security Enhanced Linux, SELinux

4. Administración de Servicios • Los servicios son administrados de varias maneras: • por init • por scripts System V • por comandos directos • Por xinetd

5. 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 volver a ejecutar (respawn) un programa que termina.

6. Servicios administrados por init • La administración del sistema X Windowen runlevel 5 es un ejemplo de este tipo de servicio. • Configurados en /etc/inittab. • Archivos de servicios en el directorio /etc/init.d.

8. 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í.

9. 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”.

10. chkconfig • Administra la 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 runlevelscon: chkconfig --list.

11. chkconfig [root@localhost~]# chkconfig --list [root@localhost~]# chkconfigxfs --list [root@localhost~]# chkconfig --list ¦ grep xfs

12. chkconfig • Usando chkconfig una definición de servicio persiste a través de los reboots. • chkconfig también administra servicios xinetd. [root@localhost~]# chkconfig cups --list cups 0:off 1:off 2:off 3:on 4:off 5:on … • El comando chkconfig <service> onhabilita por defecto el servicio en los runlevels 2, 3, 4 y 5.

13. chkconfig • El comando chkconfig <service> offdeshabilita el servicio en los runlevels2, 3, 4 y 5. • El comando chkconfig <service> --addasegura que un enlace simbólico kill o start es definido para cada runlevel. • El comando chkconfig <service> --delremueve un servicio desde la administración de chkconfig.

14. chkconfig • Por ejemplo, para “parar” el servicio httpd en los runlevels 3, 4 y 5, se utilizaría el siguiente comando: #chkconfig --levels 345 httpd off

15. 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-lpdon. • Archivos en el directorio /etc/xinetd.d/.

16. El demonio xinetd • 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. • xinetd reemplaza a inetd. • xinetd es linkeado con libwrap.so. • Archivos de configuración: /etc/xinetd.conf, /etc/xinetd.d/service.

17. El demonio xinetd • La configuración por defecto de xinetd se provee en 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.

18. El demonio xinetd • xinetd en RHEL es compilado con soporte libwrap, esto causa que xinetd chequee por los nombres de todos los servicios soportados en host.allow y host.deny.

19. xinetd default controls • Archivo de configuración de alto nivel: /etc/xinetd.conf. • El archivo de configuración /etc/xinetd.confdefine 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.

20. 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

21. xinetdservicecontrols • Configuración de servicios específicos: /etc/xinetd.d/<service>.

22. Archivos /etc/sysconfig • Muchos archivos bajo /etc/sysconfigdescriben la configuración del hardware de la máquina; 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.

23. FaultAnalysis • 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.

24. FaultAnalysis • 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 mismo tiempo, sin embargo, un sector malo en el 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.

25. FaultAnalysis • Inspeccionar los archivos de logs antes que los archivos de configuración. • Usar opciones de comandos para depurar (debugging). • Documentar la investigación.

26. 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.

27. Security-Enhanced LINUX • El LINUX tradicional deja el control de acceso al usuario. El usuario decide quien puede accesar sus archivos, basados 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.

28. Security-Enhanced LINUX • SELinux proporciona un sistema flexible de Control de Acceso Obligatorio (Mandatory Access Control, MAC) incorporado en el kernel. • Al ejecutar un kernelSELinux MAC se protege al sistema de aplicaciones maliciosas o dañinas que pueden perjudicar o destruir el sistema.

29. Security-Enhanced LINUX • SELinux permite definir el acceso y los derechos de transición de cada usuario, aplicación, proceso y archivos 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”.

30. Security-Enhanced LINUX • El Control de Acceso Obligatorio de SELinuxse encuentra bajo el control del Administrador de Seguridad. • El control de acceso tradicional está bajo el control del usuario. • Cada proceso u objeto (tal como un archivo, directorio o socket de red) en el sistema tiene un contexto de seguridad SELinux.

31. Security-Enhanced LINUX • Este contexto consiste de un identificador de usuario SELinux, un rol, y un dominio (para procesos) o un tipo (para objetos archivos): Identity:role:domain/type • La política SELinux controla que identidad SELinux es asignada a un proceso cuando se inicia. La identidad determina que roles son accesibles para el proceso, y los roles son usados para determinar a que dominios el proceso puede conmutar.

32. Security-Enhanced LINUX • Una vez se está ejecutando en un dominio particular, la política también determina que acceso un proceso tendrá a los objetos de tipos particulares de SELinux. • La política también determina el tipo por defecto para un objeto nuevo cuando es creado.

33. 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.

34. El Proceso de Toma de Decisión de SELinux • El permiso es entonces concedido o denegado a continuación, con un avc: deniedmessage 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.

35. El Proceso de Toma de Decisión de SELinux

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.

41. 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.

42. 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.

43. 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.

45. Opciones de instalación de SELinux • Durante la instalación, SELinux es activado automáticamente. Existen tres opciones que se pueden elegir: • Disabled • Warn (permisivo) • Active (enforcing) - es la opción por defecto.

46. Opciones de instalación de SELinux • Cuando la opción –Active es elegida, solo algunos demonios estarán bajo el control de SELinux, la opción “strict” afectará a todos los demonios. • Cambiar entre los modos enforcing y pasivo, se puede realizar en tiempo de booteo, en tiempo de ejecución o bien hacerlo permanente.

47. Opciones de instalación de SELinux • Para hacerlo permanente editar el archivo /boot/grub/grub.conf. • Se edita dicho archivo y agregar “enforcing=1” a la línea del kernel para activarlo, “enforcing=0” para desactivarlo. • También se puede utilizar la documentación asociada al archivo /etc/sysconfig/selinuxpara elegir la opción adecuada.

48. Opciones de instalación de SELinux • Por último, para fijar las opciones de seguridad podemos utilizar también system-config-securitylevel.

49. Control de SELinux • Las políticas SELinux pueden ser ajustadas o deshabilitadas a través de algunas utilidades: • system-config-securitylevel • setenforce y setsebool • /etc/sysconfig/selinux • enforcing=0 • /selinuxvirtual filesystem

50. Control de SELinux