Está en la página 1de 31

Gestin de usuarios

Administracin de sistemas informticos


Fernando Prez Costoya Septiembre de 2013

Objetivos del tema

Presentar aspectos generales de gest. usuarios

Independientes del S.O.

Mnimo comn mltiplo de diversos SS.OO.

Principalmente para sistemas autnomos

(workgroups en terminologa Windows)

Para sistemas integrados (Active Directory o LDAP)

Bsicamente familia UNIX/Linux y Windows

Se estudiar en detalle en el mdulo de adm. Windows

Prerrequisitos:

SS.OO.: UID|GID, rwx, ACL, setuid,...

SS.DD.: Servicios de directorio, LDAP, ...

ndice

Usuarios

Autenticacin

Grupos

Cuentas

Control de acceso

Gestin de usuarios en sistemas integrados

Polticas sobre el uso de cuentas

Deontologa del administrador

Atencin a los usuarios

Usuarios

Personas que usan el sistema

Nuestros clientes (y nosotros mismos)

Opinin: adm. debera ser usuario habitual de su sistema

Organizados de forma natural en grupos

Profesores, alumnos, administradores, miembros proy. X,...

Que pueden tener carcter jerrquico

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 numrico (ID)]

P.e. En UNIX almacenado en /etc/passwd o LDAP

NU: usado por aplicaciones y usuarios

Restricciones especficas (long. m|M, car. vlidos,...)

Definidos por administrador

Convencin sistemtica con resolucin de conflictos

ID: usado internamente por S.O.

Generacin automtica (SID de Windows)

Por administrador (UID de UNIX)

Convencin sistemtica que evite colisiones

Ms sobre nombres de usuario

NU generados de forma sistemtica

pero mejor si no fcilmente deducibles desde exterior

P.e. usuarios de correo

Recomendable no reciclar ID

Mejor relacin unvoca NU|ID

Aunque algunos permiten mltiples NU mismo ID

Casa con ms puertas ms difcil 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) podra 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

Autenticacin

Determinar que usuario es quien dice ser

Requerido en login pero tambin en otras aplic.

Distintos sist./apps. pueden requerirla

Single Sign-on: comodidad vs. seguridad

Diversos mecanismos (no excluyentes):

Conviene encapsular en mdulo nico

Contrasea, biomdicos, tarjetas, Kerberos,

Flexibilidad para cambiar minimizando impacto

UNIX/Linux: Pluggable Authentication Modules (PAM)

Front-end del sistema de autenticacin


Permite configurar pila de mtodos de autenticacin (DLL)

Contraseas

Cifrada y en sitio inaccesible (UNIX /etc/shadow)

Administrador debera poder configurar alg. cifrado

Administrador debe poder definir aspectos como:

Calidad (long. mnima, caracteres usados, )

Fecha de caducidad

Muchos otros aspectos:

Cunto antes avisa y cunto despus inhabilita cuenta


N reintentos, tiempo entre ellos, contrasea inmutable, ...

Contrasea administrador ms calidad y control

Slo 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

Sobre la generacin de NG e ID, sobre existencia de


nombres predefinidos (Windows: Administradores, Todos,
), sobre contrasea (UNIX /etc/gshadow),

UNIX: principal (passwd) y secundarios (group)

Login: credenciales ID usuario + IDs grupos

UNIX: IDs todos los grupos en control de acceso


UNIX: ID grupo principal se asocia a recursos creados

Poltica de asignacin de grupos

Tendencia maximalista

Pocos grupos con muchos usuarios

Profesores, alumnos,

Pueden compartirse recursos inadvertidamente

Tendencia minimalista

Pocos grupos con muchos usuarios

Dificulta la gestin

Esquema recomendado actualmente en UNIX:

1 grupo principal para cada usuario

Grupos secundarios pequeos para compartir

Cuenta de usuario

Locales o de red

Todos los datos de un usuario

Nombre + ID

Descripcin:

Nombre completo, telfonos, direccin postal, pg. web,

Contrasea cifrada

Grupos a los que pertenece

Informacin del entorno:

shell, directorio de trabajo, variables de entorno,


configuracin del escritorio, lmites uso de recursos,

Otros: restricciones en uso horario de la cuenta,

Ciclo de vida de una cuenta

Creacin adems de incluir toda la info. de cuenta

Crear recursos: directorio base, buzn de correo,

Qu contrasea inicial poner? No dejar sin ella.

Uso de mandatos (useradd), GUI, a mano,

Creacin masiva: script o mandato (newusers)

Modificacin

Inhabilitacin

Destruccin: ms delicada que creacin

Dificultad para encontrar todos los recursos asociados

Control de acceso

UsuX puede hacer OpY sobre ObjZ? (proteccin)

3 modelos formales principales (no excluyentes):

Discretionary Access Control (DAC)

Mandatory Access Control (MAC)

Ms usado en SO de propsito general (el clsico)


Familia UNIX, Windows, ...
Usado principalmente en entornos militares
SELinux

Role-based Access Control (RBAC)

Solaris, HP-UX, ...

Principio de mnimo privilegio

Proceso debe ejecutar slo con privilegio


requerido para realizar su labor

Privilegios adicionales Menor seguridad

Ejecutar como SU privilegio total

Programa manipulado toma control total del sistema

Mayora de los ataques se basan en esto

Si servidor slo requiere bind de puerto privilegiado

Slo otorgarle esa potestad

DAC

Dueo de Obj otorga a Usu acceso a discrecin

Matriz de proteccin (dispersa): usuarios x objetos

Celda operaciones permitidas para ese Usu y Obj

Implementacin habitual: por columnas

Listas de control de acceso (ACL)

rwx de UNIX ACL compacto

Por filas (menos frecuentes): capabilities

Cada (proceso de) usuario Lista de Objs accesibles

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::---

Capabilities en Linux

Aplicables slo a ciertas op. privilegiada (no a fich)

Otorga permiso para usar cierta op. privilegiada

Aumentar prio, puertos privilegiados, ...

Pueden asignarse a procesos y a ejecutables

SETUID mejorado

Implementacin Linux inmadura

Ejemplo:

$ sudo setcap cap_net_bind_service+ep ./ejemplo


$ getcap ejemplo
ejemplo = cap_net_bind_service+ep

MAC

Autoridad nica asigna niveles de seguridad a

Objetos y usuarios/procesos

Reglas (modelo Bell-La Padula, 1973):

Propiedad simple (read-down)

Propiedad * (write-up)

Proc. nivel k slo puede leer Objs <= nivel


Proc. nivel k slo puede escribir Objs >= nivel

Propiedad * es contra-intuitiva

Evita filtraciones de informacin (p.e. caballo de troya)

RBAC

Autoridad nica define roles

Asocindoles poder hacer Ops. sobre Objs.

Mdico prescribe medicina; enfermero la administra


Ej. de Solaris: rol Operator solaris.system.shutdown

Pueden anidarse

Rol mdico y enfermero incluidos en rol personal sanitario

Cada usuario tiene asignados uno o varios roles

Facilita delegacin de administracin y

Cumplimiento de principio de mnimo privilegio

Control de acceso en SO real: UNIX

Modelo habitual en UNIX: DAC para ficheros

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 (slo SU)

Cambiar reloj, configurar interfaz de red, apagar el sistema,


bind de puertos privilegiados, aumentar prio. proceso,
Usuario normal necesita|puede ejecutar ops. privilegiadas?

Necesidad uso de ops. privilegiadas

Escenarios de ejemplo (UNIX):


1.Clsico: mandato passwd debe modificar /etc/passwd

Irresoluble mediante ACLs

2.Servicio requiere usar puerto privilegiado (web 80)


3.Admin. quiere delegar labores de administracin

Gestin de redes, de backups,


Si administracin delegada no requiere ops. privilegiadas

Basta con ACLs: crear grupo con delegados e incluirlo en ACLs

Cmo ejecuta usuario normal ops. privilegiadas?

Distintas alternativas...

Usuario ejecutando como SU

Usuario se convierte temporalmente en SU

Explcitamente (su UNIX; sesin secundaria Windows)

Implcitamente (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 contrasea SU

Esta solucin rompe principio de mnimo privilegio

sudo

Solucin pragmtica en mundo UNIX/Linux

Usuario puede ejecutar cierto mandato

Con la identidad de otro usuario pero su contrasea

Si otro usuario SU, facilita delegacin de admin.

Delegados no conocen contrasea root

Aunque peligro si contrasea de delegado descubierta

No evita romper principio mnimo privilegio

Mandato ejecuta como root


Si malintencionado, toma control total del sistema

Otras alternativas

Usar UNIX con RBAC

Solaris, HP-UX,...

Definicin de roles que facilite delegacin y

mnimo privilegio

Usar capabilities de Linux

G. usuarios en sistemas integrados

Red de sistemas autnomos

Duplicar cuentas en todos los sistemas

No slo info. usuarios y grupos equipos, dispo.,...

Esquema poco flexible, seguro y escalable

Solucin: Servicio de directorio

Repositorio global de entidades del sistema

Primeros productos: NIS

Soluciones actuales basadas en protocolo LDAP

Distribuido y replicado

OpenLDAP en UNIX/Linux; Active Directory en Windows

Asignatura estudia en detalle el caso de 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 (toppersonorganizationalPersoninetOrgPerson)

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: fperez@fi.upm.es
uid: fperez
uidnumber: ....
gidNumber: ....
irisUserStatus: Activo
fiRelationShip: pdi
fiTeaching: ......
sambaSID: .....

auxiliar (top sambaSamAccount )

person

organizationalPerson
inetOrgPerson

posixAccount
irisPerson
fiPerson
sambaSamAccount

fiEmployee

Polticas sobre uso de cuentas

Derechos y deberes de los usuarios

Disponer de una cuenta implica responsabilidad

Debe estar escrita poltica sobre uso de cuentas

Reglas simples

Qu puede y no puede hacer un usuario

Consecuencias de no cumplir las reglas

Reglas que encajen en mbito cultural local e Internet

Administrador debe supervisar su cumplimiento

Deontologa del administrador

Tiene poder absoluto sobre el sistema

Debe tener comportamiento tico con usuarios

Pero tambin con el resto de Internet

Cdigo tico (SAGE/LISA):

Profesionalismo, integridad personal, privacidad, leyes


y polticas, comunicacin, integridad del sistema,
educacin, responsabilidad con la comunidad
informtica, responsabilidad social y responsabilidad
tica.

Atencin a los usuarios

Tratamiento amigable reflejando cultura de la ca.

Helpdesk (real o virtual)

Especificar tipo de ayuda y acotar responsabilidad

Ofrecer seguimiento de las peticiones de usuarios

Resolucin de problemas, cursos,


Uso de software para Trouble-Tracking

Limoncelli plantea 9 pasos (organizados en 4


fases) en resolucin de peticiones de usuarios:

Atencin a los usuarios


Greeting
1. Greeting How may I help you?
Problem identification
2. Identify problem
3. Refine and express the problem
4. Verify the problem
Correction
5. Propose solutions
6. Select solution
7. Execution
Verification
8. Self-check
9. User-check