Gestión de usuarios - Laboratorio SS.OO.

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