Gestión de usuarios - Laboratorio SS.OO.
Transcripción
Gestión de usuarios - Laboratorio SS.OO.
Gestión de usuarios Administración de sistemas informáticos Fernando Pérez Costoya – Septiembre de 2012 Objetivos del tema ● Presentar aspectos generales de gest. usuarios ● Independientes del S.O. ● Mínimo común múltiplo de diversos SS.OO. – ● Básicamente familia UNIX/Linux y Windows ● Para sistemas autónomos (workgroups en Windows) ● Y para sistemas integrados (con AD: Active Directory) Prerrequisitos: ● SS.OO.: UID|GID, rwx, ACL, setuid,... ● SS.DD.: Servicios de directorio, LDAP, ... Índice ● Usuarios ● Autenticación ● Grupos ● Cuentas ● Control de acceso ● Gestión de usuarios en sistemas integrados Usuarios ● Personas que usan el sistema ● Nuestros “clientes” (y nosotros mismos) – ● Opinión: adm. debería ser usuario habitual del sistema Organizados de forma natural en grupos – ● Profesores, alumnos, administradores, miembros proy. X,... Que pueden tener carácter jerárquico – – – – Usuarios y grupos miembros de un grupo Yo → profesor → PDI → miembro facultad Tú → alumno → miembro facultad Él → gestor backups → administrador → miembro facultad Identificadores de usuario ● [Nombre usuario (NU) | ID numérico (ID)] ● ● En UNIX almacenado en /etc/passwd NU: usado por aplicaciones y usuarios ● Restricciones específicas (long. m|M, car. válidos,...) ● Definidos por administrador – ● Convención sistemática con resolución de conflictos ID: usado internamente por S.O. ● Generación automática (SID de Windows) ● Por administrador (UID de UNIX) – Convención sistemática que evite colisiones Más sobre nombres de usuario ● NU generados de forma sistemática ● pero mejor si no fácilmente deducibles desde exterior ● P.e. ≠ usuarios de correo ● Recomendable no reciclar ID ● Mejor relación unívoca NU|ID ● Aunque algunos permiten múltiples NU mismo ID – ● Casa con más puertas más difícil de guardar Renombrar NU no afecta a la cuenta Usuarios predefinidos ● Habitual en todos los SS.OO. ● Superusuario (SU): Administrador|root ● Algunos SSOO recomiendan renombrar (Windows) ● En otros (UNIX) podría causar problemas ● Invitado: poco recomendable → inhabilitar ● Otros: nobody en UNIX, … ● Pseudo-usuarios: cuenta sin login ● Puede usarse para asignar un usuario a un servicio ● Mejor si evitamos que servicios ejecuten como SU Autenticación ● Determinar que usuario es quien dice ser ● Requerido en login pero también en otras aplic. – ● Diversos mecanismos: ● Contraseña, biomédicos, tarjetas, Kerberos, … – ● Conviene encapsular en módulo único O una combinación de varios Flexibilidad para cambiar minimizando impacto ● UNIX/Linux: Pluggable Authentication Modules (PAM) – – Front-end del sistema de autenticación Permite configurar “pila” de métodos de autenticación (DLL) Contraseñas ● Cifrada y en sitio inaccesible (UNIX /etc/shadow) ● ● Administrador debería poder configurar alg. cifrado Administrador debe poder definir aspectos como: ● Calidad (long. mínima, caracteres usados, …) ● Fecha de caducidad – ● Muchos otros aspectos: – ● Cuánto antes avisa y cuánto después inhabilita cuenta Nº reintentos, tiempo entre ellos, contraseña inmutable, ... Contraseña administrador más calidad y control ● ● Sólo login en consola o mejor nunca Nunca administrador como SU para labor cotidiana Grupos ● [N. grupo (NG) | ID num. (ID)] (UNIX /etc/group) ● Aplicable casi todo lo comentado para n. usuario: – ● Usuario miembro de varios grupos ● ● UNIX: principal (passwd) y secundarios (group) Login: credenciales → ID usuario + IDs grupos – – ● Sobre la generación de NG e ID, existencia de grupos predefinidos (Windows: Administradores, Todos, …), contraseña (UNIX /etc/gshadow), … UNIX: IDs todos los grupos en control de acceso UNIX: ID grupo principal sed asocia a recursos creados Pueden permitir anidamiento (Windows con AD) Política de asignación de grupos ● Tendencia maximalista ● Pocos grupos con muchos usuarios – ● ● ● Profesores, alumnos, … Pueden compartirse recursos inadvertidamente Tendencia minimalista ● Pocos grupos con muchos usuarios ● Dificulta la gestión Esquema recomendado actualmente en UNIX: ● 1 grupo principal para cada usuario ● Grupos secundarios “pequeños” para compartir Cuenta de usuario ● Todos los datos de un usuario ● Nombre + ID ● Descripción: – ● Contraseña cifrada ● Grupos a los que pertenece ● Información del entorno: – ● ● Nombre completo, teléfonos, dirección postal, pág. web, … shell, directorio de trabajo, variables de entorno, configuración del escritorio, límites uso de recursos, … Otros: restricciones en uso horario de la cuenta, … Gestión de cuentas tiene implicaciones legales Ciclo de vida de una cuenta ● Creación además de incluir toda la info. de cuenta ● Crear recursos: directorio base, buzón de correo, … ● ¿Qué contraseña inicial poner? No dejar sin ella. ● Uso de mandatos (useradd), GUI, “a mano”, … ● Creación masiva: script o mandato (newusers) ● Modificación ● Inhabilitación ● Destrucción: más “delicada” que creación ● Dificultad para encontrar todos los recursos asociados Control de acceso ● ¿Qué recursos|ops. puede utilizar un usuario? ● Específico de cada S.O. ● UNIX: diferente para ficheros y resto de recursos ● Ficheros permisos mediante ACLs (como en Windows) – – ● Para otorgar a U acceso a F → insertar U en ACL de F SU (root) acceso a todos Otros recursos: ops. Privilegiadas (sólo SU) – – Cambiar reloj, configurar interfaz de red, apagar el sistema, bind de puertos privilegiados, aumentar prio. proceso, … ¿Usuario normal necesita|puede ejecutar ops. privilegiadas? Ejemplo de ACLs de Linux $ touch f $ getfacl f # file: f # owner: fperez # group: gpmimd user::rwgroup::--other::--$ setfacl -m user:ssoo:r f $ getfacl f # file: f # owner: fperez # group: gpmimd user::rwuser:ssoo:r-group::--mask::r-other::--- Necesidad uso de ops. privilegiadas ● Escenarios de ejemplo (UNIX): 1.Clásico: mandato passwd debe modificar /etc/passwd – Irresoluble mediante ACLs 2.Servicio requiere usar puerto privilegiado (web → 80) 3.Admin. quiere delegar labores de administración – – Gestión de redes, de backups, … Si administración delegada no requiere ops. privilegiadas ● Basta con ACLs: crear grupo con delegados e incluirlo en ACLs ● ¿Cómo ejecuta usuario normal ops. privilegiadas ● Distintas alternativas... Usuario ejecutando como SU ● ● Usuario se convierte temporalmente en SU ● Explícitamente (su UNIX; sesión secundaria Windows) ● Implícitamente (SETUID|SETGID de UNIX) En los escenarios planteados 1. passwd con SETUID de root 2.Servicio ejecuta asociado a usuario root 3.Delegados usan su para hacerse root – ● Malo: deben conocer contraseña SU Esta solución rompe principio de mínimo privilegio Principio de mínimo privilegio ● Proceso debe ejecutar sólo con privilegio requerido para realizar su labor ● ● Privilegios adicionales → Menor seguridad Ejecutar como SU → privilegio total ● Programa manipulado toma control total del sistema – ● Si servidor sólo requiere bind de puerto privilegiado – ● Mayoría de los ataques se basan en esto Sólo otorgarle esa potestad Soluciones alternativas... Roles ● En Solaris (roleadd) y HP-UX pero no en Linux ● Rol representa algún tipo de labor ● Puede conllevar permiso para ops. Privilegiadas ● Facilitan delegación de administración ● Usuario puede tener asignados varios roles ● Rol asignado a varios usuarios ● Permiten anidamiento ● Símil con algunos grupos predefinidos Windows ● Operadores de red, impresión, copia de seguridad,... Capabilities en Linux ● Otorga permiso para usar cierta op. Privilegiada ● ● Aumentar prio, puertos privilegiados, ... Pueden asignarse a procesos y a ejecutables ● SETUID mejorado ● Implementación Linux inmadura ● Ejemplo: $ sudo setcap cap_net_bind_service+ep ./ejemplo $ getcap ejemplo ejemplo = cap_net_bind_service+ep sudo ● Solución pragmática en mundo UNIX/Linux ● Usuario puede ejecutar cierto mandato ● ● Con la identidad de otro usuario pero su contraseña Si otro usuario SU, facilita delegación de admin. ● Delegados no conocen contraseña root – ● Aunque peligro si contraseña de delegado descubierta No evita romper principio mínimo privilegio – – Mandato ejecuta como root Si malintencionado, toma control total del sistema G. usuarios en sistemas integrados ● ● Red de sistemas autónomos ● Duplicar cuentas en todos los sistemas ● No sólo info. usuarios y grupos → equipos, dispo.,... ● Esquema poco flexible, seguro y escalable Solución: Servicio de directorio ● Repositorio global de entidades del sistema – Distribuido y replicado ● Primeros productos: NIS ● Soluciones actuales basadas en protocolo LDAP – OpenLDAP en UNIX/Linux; Active Directory en Windows Consulta de cuenta a LDAP de FI ldapsearch -x -W -H ldaps://info.fi.upm.es -D 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es‘ -b 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es' dn: uid=fperez,ou=personal,dc=fi,dc=upm,dc=es objectClass: inetOrgPerson ← estructural (top→person→organizationalPerson→inetOrgPerson) objectClass: posixAccount ← auxiliar (top→ posixAccount) objectClass: fiEmployee ← auxiliar (top → irisPerson → fiPerson → fiEmployee) objectClass: sambaSamAccount cn: Fernando Perez Costoya cn: F. P. Costoya sn: Perez Costoya telephoneNumber: 913367377 mail: [email protected] uid: fperez uidnumber: .... gidNumber: .... irisUserStatus: Activo fiRelationShip: pdi fiTeaching: ...... sambaSID: ..... ← auxiliar (top → sambaSamAccount ) person organizationalPerson inetOrgPerson posixAccount irisPerson fiPerson sambaSamAccount fiEmployee