Usuarios y Grupos en Sistemas GNU/Linuxhot!

Usuarios y Grupos en Sistemas GNU/Linuxhot!

Usuarios y Grupos en sistemas
GNU/Linux
La información del usuario cómo es
almacenada en el sistema
/etc/passwd
En la mayoría de las distribuciones Linux (así como en los *nixes comerciales),
la información del usuario es almacenada en /etc/passwd, un archivo de texto
que contiene el nombre de inicio de sesión de cada usuario, su contraseña
cifrada, un identificador único numérico (llamado uid), un identificador
numérico de grupo (llamado gid), un campo opcional para comentarios
(comúnmente contiene ítemes tales como nombre real, número telefónico,
etc.), su directorio hogar, y su intérprete de comandos por omisión. Una
entrada típica en /etc/passwd deberia ser:
pete:K3xcO1Qnx8LFN:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
Como puedes ver, es bastante directo. Cada entrada contiene los seis campos
que descritos en el párrafo anterior, con cada campo separado por dos puntos.
Contraseñas ocultas
Observe su archivo /etc/passwd, muy probablemente le resultará similar:
pete:x:1000:1000:Peter Hernberg,,,1-800-FOOBAR:/home/pete:/bin/bash
¿Y donde está la contraseña cifrada? Antes de decirle donde está, se requiere
una pequeña explicación.
El archivo /etc/passwd, el cual contiene información de todos los usuarios,
incluye su contraseña cifrada, es visible por todos los usuarios, permitiendo
tanto como sea posible que cualquier usuario obtenga la contraseña cifrada
cuando sea requerida por el sistema. Aunque las contraseñas estén cifradas,
los programas que determinan contraseñas están ampliamente disponibles.
Para combatir esta amenaza cada vez mayor de la seguridad, las contraseñas
ocultas (shadow N. del T.) fueron desarrolladas.
Cuando un sistema habilita las contraseñas ocultas, el campo de la contraseña
en /etc/passwd es reemplazado por una "x", la contraseña cifrada es grabada
en /etc/shadow.
Ya que /etc/shadow es legible solamente por el usuario administrador,
usuarios maliciosos no pueden obtener la contraseña de sus compañeros.
Cada entrada en /etc/shadow contiene el nombre de inicio de sesión del
usuario (login N. del T.), su contraseña cifrada, y un número de campos
relativos a la vigencia de la contraseña. Una entrada típica es como la
siguiente:
pete:/3GJllg1o4152:11009:0:99999:7:::
/etc/group y /etc/gshadow
La información de los grupos es almacenada en /etc/group. El formato es
similar al de /etc/passwd, con las entradas conteniendo campos para el
nombre del grupo, contraseña, identificador numérico (gid), y una lista
separada por comas de los miembros del grupo. Una entrada en /etc/group
es como ésta:
pasta:x:103:spagetti,fettucini,linguine,vermicelli
Como se puede observar existe una “x” en el campo de la contraseña, las
contraseñas de grupo se pueden ocultar también. Aunque los grupos casi
nunca tienen contraseñas asignadas, vale la pena observar que la contraseña
cifrada del grupo se almacena en /etc/gshadow.
Contraseñas cifradas MD5
Tradicionalmente, las contraseñas en los sistemas unix son cifradas con la
función estándar crypt(). (Para más información de la función crypt(), vea la
página del manual crypt(3)). Como las computadoras personales crecieron
rápidamente, las contraseñas cifradas con ésta función se han hecho muy
fáciles de violentar. Mientras Internet creció, la distribución de herramientas
para violentar contraseñas a través de los equipos conectados en al red se
volvió una tarea común. Muchas de las distribuciones (las más nuevas)
permiten cifrar contraseñas con el algoritmo generador de claves más fuerte
MD5 para representar de manera unívoca un documento (hash N. del T).
(Para más información sobre el algoritmo hash MD5, consultar RFC 1321.)
Mientras que las contraseñas cifradas con MD5 no eliminarán la amenaza de
violentar las contraseñas, harán que el proceso de descifrar tus contraseñas
sea mucho más difícil.
Cómo suceden las cosas
Como puede observar, existen varias formas de almacenar la información de
autentificación del usuario en el sistema (contraseñas ocultas sin el algoritmo
de cifrado MD5, /etc/passwd contraseñas con algoritmo de cifrado MD5,
etc.). ¿De que forma los programas establecen una conexión entre tu inicio de
conexión para verificar tu contraseña? Peor aún, ¿que si estás buscando
cambiar la forma en que las contraseñas son almacenadas en el sistema?
¿Cómo hacen los programas para obtener tu contraseña conocida para
almacenar una distinta? PAM es la respuesta.
Cuentas de usuarios
A fin de lograr una organización coherente entre todas las máquinas, en mi
sistema las primeras cuentas son siempre las mismas.
Siempre creo una primer cuenta de usuario con un nombre como "admin"
(uid=1000). Reenvío todos los mensajes del superusuario a ella. Esta cuenta
pertenece al grupo adm, al que puede darse una buena cantidad de privilegios
de superusuario mediante el comando su usando PAM o con sudo.
Sugiero crear una cuenta especial para las tareas de entrenamiento, para
efectos prácticos la llamaremos penguin y será añadida al grupo adm para
permitirle el acceso de lectura a los diversos archivos de registros situados en
/var/log/. Véase passwd(5), group(5), shadow(5), group(5), vipw(8) y
vigr(8). Para el significado oficial de usuarios y grupos, vea la lista a
continuación:
Usuarios y Grupos en el Sistema
Debian
El paquete base passwd de Debian contiene las versiones principales de
/etc/passwd y de /etc/group. La herramienta update-passwd mantiene las
entradas estos archivos principales en sincronización de todos los sistemas
Debian. Abarcan solamente las identificaciones “estáticos globales”: es decir,
aquellos cuales están reservados globalmente para el beneficio de paquetes
que incluya archivos de esos usuarios o grupos, o necesitan los identificadores
compiladas en dentro de los binarios. Puesto que esta reservación es una
restricción seria, estos identificadores deben ser asignados de forma ordenada
por el mantenedor de solicitudes de base-passwd. En general, los paquetes
deben evitar solicitudes de tales identificadores en lo posible y en lugar de
ello, asignar usuarios o grupos del sistema dinámicamente. Véase la política
de Debian para otros detalles.
El Manual de la política de Debian reserva rangos para éstos usuarios y
grupos estáticos globales, pero no hace ningún intento en asignar números
individuales o de definir sus propósitos. Este documento llena ese vacío
describiendo los propósitos de las entradas individuales en estos archivos
principales.
Esto es un trabajo en progreso. Los ítemes requieren que el diálogo de
retorno sea marcado con la etiqueta "HELP". Por favor envíe sus correos a
<[email protected]> o un archivo de errores al Debian bug
tracking system si tienes mayor información.
Lista de usuarios y grupos en el
sistema Debian
Muchos usuarios tiene correspondencia en un grupo, y estos pares serán
tratados juntos.
root
Root es (típicamente) el superusuario.
daemon
Algunos demonios sin privilegios requieren ser habilitados para escribir
algunos archivos en el disco cuando son ejecutados como
daemon.daemon (portmap, atd, jabberd, lambdamoo, mon, y otros).
Demonios que no necesitan sus propios archivos, en algunas ocasiones se
ejecutan como nobody.nogroup en lugar de otros; es generalmente mejor
práctica utilizar un usuario dedicado, demonios más complejos y/o
conscientes de la seguridad realmente hacen eso. El usuario daemon
probablemente también es manipulado por demonios instalados
localmente.
LSB 1.3 enumera a los demonios de forma hereditaria, y dice: “El
'demonio' UID/GID será usado como un UID/GID no privilegiado para que
los demonios se ejecuten con acceso limitado al sistema. Los demonios
ahora deben ejecutarse generalmente debajo de UID/GIDs individuales
para repartir funciones uno a partir de los otros.”
bin
NOTA: Ningún archivo en mi sistema pertenece al usuario o grupo bin.
¿Qué tan bueno es? ¿Históricamente ellos fueron probablemente los
dueños de los binarios en /bin? No se menciona en el FHS, la política de
Debian, o los registros de cambios de la base-passwd o de base-files.
LSB 1.3 lista bin como herencia, y dice: “El UID/GID de 'bin' es incluido
para compatibilidad con aplicaciones heredadas. Las nuevas
aplicaciones no deben utilizar más UID/GID de 'bin'.”
sys
NOTA: Como bin, con la excepción que no se para que fue bueno
históricamente.
I'm told that /var/spool/cups is owned by group sys, dunno why.
sync
El intérprete del usuario sync es /bin/sync. Así, si establece su
contraseña algo fácil adivinar (por ejemplo ""), cualquiera puede hacer
uso de sync en el sistema a través de una consola aunque no tenga
ninguna cuenta en el sistema.
games
Muchos juegos hacen sgid a juegos de tal forma que puedan escribir en
sus archivos de mejores jugadas. Esto es explicado en Debian Policy.
man
El programa man (algunas veces) se ejecuta con el usuario man, lo cual
le permite escribir páginas en /var/cache/man y actualizar bases de
datos.
lp
En los dispositivos lp* se puede escribir con este grupo de modo que los
usuarios en éste grupo podrán tener acceso al puerto paralelo
directamente. Tradicionalmente éste trabajo es tomado por un demonio
de impresión en lugar de otro que necesite ejecutarse en éste grupo.
El sistema lpr mantiene sus directorios spool bajo el dominio lp/lp. Estos
demonios y herramientas finales para el usuario (a través de setuid) se
ejecutan como superusuario.
NOTA: ¿que hacen otros sistemas de impresión(rlpr, cupsys, lprng, ...)?
mail
Contenedores de correo en /var/mail pertenecen y el grupo mail puede
escribir en el, tal como es explicado en el Debian Policy. El usuario y
grupo es usado para otros propósitos como lo son varios MTAs y MUAs.
news
Varios servidores de noticias y otros programas asociados (por ejemplo
suck) utiliza el usuario y grupo news de varias formas. Los archivos en
el spool de news a menudo son propiedad del usuario y grupo news.
Programas como inews que necesitan ser utilizados por post news
típicamente hacen sgid a news.
uucp
El usuario y grupo uucp es utilizado por el subsistema UUCP. Estos son
propietarios de spool y archivos de configuración. Usuarios en el grupo
uucp pueden ejecutar uucico.
proxy
Como demonio, éste usuario y grupo es utilizado por algunos demonios
(especificamente, demonios proxy) que no tienen identificador de
usuario dedicado y que necesita ser dueño de los archivos. Por ejemplo,
el grupo proxy es utilizado pdnsd, así como squid se ejecuta como un
usuario proxy.
majordom
Mayordomo el tiene asignado un uid estáticamente en los sistemas de
Debian por razones históricas. No está instalado en nuevos sistemas.
postgres
Las bases de datos Postgresql son propiedad de éste usuario y grupo.
www-data
Algunos servidores web se ejecutan como www-data. El contenido del
Web no debe ser propiedad de éste usuario, ya que si el servidor web está
comprometido podría reescribir todo el sitio web. Los datos escritos fuera
del web, incluyendo registros, serán propiedad de www-data.
backup
¿Probablemente las responsabilidades de realizar respaldos y
restaurarlos pueden ser delegadas localmente a alguien sin los permisos
completos del administrador?
NOTA: ¿Eso es correcto? ¿Amanda reporta éste uso, detalles?
operator
Históricamente, la cuenta del usuario operador ha sido usada por
operadores del sistema con privilegios bajos para vaciar respaldos de
sistemas de archivo a una cinta, y eran miembros del grupo root para
poder realizar dicha tarea. En Debian, el uso de una utilidad como sudo
para obtener privilegios es preferido ante cuentas tales como:
propósitos altamente especiales, y el usuario operador no fue creado
más por omisión. Este tenía uid 37.
El grupo operator es usado por
dump -n para informar a los
operadores que hallan iniciado sesión vía wall cuando éstos requieren
atención operador. Esto es un uso histórico, y las nuevas aplicaciones no
deben tener este comportamiento. (Si no queda de otra, el grupo debe
configurarse.)
list
Archivos de listas de correo y datos son propiedad de éste usuario y
grupo. Algunos programas que manipulan listas de correo pueden
ejecutarse como éste usuario también
irc
Utilizado por demonios IRC. Es requerido asignar un único usuario
estáticamente debido a que un bug en ircd permite asignarse setuid()
a sí mismo para compilarse un identificador de usuario al inicio del
sistema.
gnats
NOTA: Evidentemente usado por gnats. ¿Y éste necesita una asignación
estática? ¿por qué?
nobody, nogroup
Demonios que necesiten no ser dueños de cualquier archivo se ejecutan
como usuario nobody y grupo nogroup, aunque utilizar un usuario
dedicado es lejano a ser preferible. Así, ningún archivo en un sistema
serán propiedad de éste usuario o grupo.
(Técnicamente hablando, ésto no causa ningún daño para que un
archivo sea propiedad del grupo nogroup mientras no tenga la
propiedad de conferir privilegios adicionales, ésto es si el grupo y otros
bits de permiso son iguales. Sin embargo, ésta práctica es descuidada y
se debe evitar.)
Si root-squashing está en uso sobre NFS, el acceso de root desde el
cliente se realiza como usuario nobody en el servidor.
Otros grupos que no están asociados a un
usuario.
adm
El grupo es utilizado para tareas de monitoreo del sistema. Miembros de
éste grupo pueden leer muchos archivos de registro en /var/log, y
pueden usar xconsole.
Históricamente, /var/log fue /usr/adm (y luego /var/adm), de allí el
nombre del grupo.
NOTA: Quizás la política debe indicar el propósito de este grupo así como
los usuarios pueden ser agregados con seguridad a él, ciertamente que
todos ellos estarán habilitados para leer registros. Que tal si alguien
renombra un 'log' por ejemplo...
tty
Dispositivos tty y /dev/vcs* son miembros de éste grupo. Estos son
usados por write y wall para permitir escritura en otros ttys.
disk
Raw access to disks. Mostly equivalent to root access.
HELP: Well, I have some disk devices in /dev owned by the group, but I
can't see the point. On another system, I noticed that some of the files
lilo puts in /boot are also owned by disk. I can imagine local uses for
such a group, like if you want to give some users in the group direct
access to some hard disk. But these uses I've found on my systems seem
to preclude doing that easily; if I put a user in group disk here, they'd
have write access to the root filesystem.
kmem
/dev/kmem and similar files are readable by this group. This is mostly a
BSD relic, but any programs that need direct read access to the system's
memory can thus be made setgid kmem.
dialout
Full and direct access to serial ports. Members of this group can
reconfigure the modem, dial anywhere, etc.
dip
The group's name stands for "Dialup IP". Being in group dip allows you to
use a tool such as ppp or dip to dial up a connection.
fax
Allows members to use fax software to send or receive faxes.
voice
Voicemail, useful for systems that use modems as answering machines.
cdrom
This group can be used locally to give a set of users access to a CD-ROM
drive.
floppy
This group can be used locally to give a set of users access to a floppy
drive.
tape
This group can be used locally to give a set of users access to a tape
drive.
sudo
Members of this group do not need to type their password when using
sudo. See /usr/share/doc/sudo/OPTIONS.
audio
This group can be used locally to give a set of users access to an audio
device.
src
This group owns source code, including files in /usr/src. It can be used
locally to give a user the ability to manage system source code.
HELP: /usr/src is owned by group src and is setgid. This doesn't make
files put there by foo-src packages necessarily be owned by group src
though. If the intent is to make group src be able to manage source code,
perhaps policy should say that foo-src packages make files in /usr/src
owned and writeable by the group (and files in tarballs dropped there
likewise)?
shadow
/etc/shadow is readable by this group. Some programs that need to be
able to access the file are setgid shadow.
utmp
This group can write to /var/run/utmp, /var/log/wtmp,
/var/log/lastlog, and similar files. Programs that need to be able to
write to them (such as X terminal emulators) are setgid utmp.
video
This group can be used locally to give a set of users access to a video
device.
plugdev
Members of this group can mount removable devices in limited ways via
pmount without a matching entry in /etc/fstab. This is useful for local
users who expect to be able to insert and use CDs, USB drives, and so on.
Since pmount always mounts with the nodev and nosuid options and
applies other checks, this group is not intended to be root-equivalent in
the ways that the ability to mount filesystems might ordinarily allow.
Implementors of semantics involving this group should be careful not to
allow root-equivalence.
staff
Allows users to add local modifications to the system (/usr/local, /home)
without needing root privileges. Compare with group 'adm', which is
more related to monitoring/security.
users
While Debian systems use the user-group system by default (each user
has their own group), some prefer to use a more traditional group system.
In that system, each user is a member of the 'users' group.