Re: [P] SetUID, SetGID [LARGO]

[Ernesto Hernandez-Novich <emhn@xxxxxxxxxxxxx>]

On Fri, 31 Mar 2000, José Luis Zabalza wrote:
>> La respuesta está en el setuid bit. El programa /bin/passwd tiene como
>> propietario a root y además tiene activado el setuid bit; esto quiere decir que
>> al momento de _ejecutar_ el programa, el proceso tendrá como usuario real a
>> cualquiera que lo ejecute (usuario regular) pero como usuario _efectivo_ áquel
>> que sea dueño del programa (en este caso, root). Esto se traduce en que a
>> efectos de acceso a archivos el proceso tiene los privilegios del dueño del
>> programa (el usuario efectivo, en este caso root) y a efectos de contabilidad de
>> procesos tendrá los privilegios del ejecutor del programa (el usuario real, en
>> este caso tu usuario regular). Como el programa passwd es utilizado
>> _exclusivamente_ para cambiar passwords, pues no tendrás inconveniente en abrir
>> el archivo y _cambiarlo_, puesto que lo estás haciendo "como si fueras" root.
>> Se habla de "usuario real" y "usuario efectivo" para referirse a "¿quién
>> ejecuta?" y "¿como quién lo ejecuta?"...
>
>Pregunta inmediata. Un usuario puede activar el SetUID en uno de sus
>programas. Supongo que si lo hace, dicho programa solo podrá 
>modificar ficheros que el propio usuario haya creado y, de normal, 
>solo tenga permiso de escritura el propio usuario. Esto me recuerda, 
>hablando de programación orientada a objetos, al mecanismo de 
>proteccion de los datos privados del objeto que solo pueden ser 
>modificados por funciones propias del objeto. De esta manera, el 
>objeto sabe que, otro objeto puede modificar ese dato solamente 
>atraves de la función de acceso. ¿Es correcto?

Un usuario regular A puede conferirle el setuid bit a un ejecutable propio, lo
cual implica que cualquier otro usuario B que tenga la posibilidad de ejecutar
dicho programa recibirá temporalmente la identidad del usuario A, y con está
tener acceso "como si lo fuera", siendo capaz de acceder a cualquier objeto al
cual tenga acceso el usuario A. Tu analogía con OOP es similiar en efecto aunque
no exacta en términos semánticos; si te sirve para explicar el funcionamiento,
úsala, pero nunca pienses que "es igual".

Por cierto, el _privilegio_ de asignar el setuid a un archivo _también_ puede
ser removido (particularmente en sistemas con seguridad superior a C2). Esto
es, el sistema solamente permite a root (en el caso Unix) o a los
"administradores binarios" (sistemas operativos similares a Unix, pero con
seguridad por encima de C2 tienen este _rol_) usar el setuid.

>> 
>> El setgid bit es análogo pero en lugar de cambiar la identidad a un _usuario_
>> lo hace a un grupo. La aplicación natural de setgid bit es delegar tareas
>> administrativas (aquellas generalmente atendidas por root) a _grupos_ de
>> personas (que realmente, en lugar de llamarse "grupos" deberían llamarse
>> "roles", pero ese es un problema de nomenclatura). En HP/UX solamente puede
>> accederse a la memoria del sistema usando /dev/mem y /dev/kmem; estos archivos
>> tienen propiedad root:sys:640... para poder usar top para monitorear el
>> sistema, debe ser instalado como root:sys y con el setgid bit activado (si
>> pongo top como setuid root, entonces los usuarios andan matando procesos que no
>> les pertenecen :-).
>
>	Pero... A ver que me aclare. Un usuario pertenece a uno o más 
>grupos. Un fichero o directorio pertenece a un usuario. El usuario 
>puede otorgar derechos sobre sus ficheros y estos derechos son, 
>lectura, escritura y ejecución. ¿A quien? a si mismo, a los usuarios 
>de sus grupos y/o a todos los usuarios en el mundo. ¿Voy bien?

En general esa es la idea. Un objeto pertenece a un usuario _exclusivamente_;
dicho usuario decide que privilegios otorgarse a sí mismo, a _un_ grupo
específico y al _resto_ del mundo. Aunque un usuario puede pertenecer a
_varios_ grupos, debe decidir en otorgar privilegios solamente a _un_ grupo (el
usuario necesita ser miembro de dicho grupo).

>Si tenemos un fichero que tiene los derechos de lectura y 
>escritura del grupo activos, cualquier usuario del grupo puede leer y 
>escribir dicho fichero. 

Esto es correcto.

> Los usuarios que no pertenezcan a algún grupo de los que pertenece
> el usuario **no** pueden modificar el fichero.

El hecho que un usuario no pertenezca a los grupos del dueño no tiene ninguna
importancia. Si el archivo permite que "el resto" tenga acceso, pues el usuario
podrá. Si el usuario pertenece a otro grupo común al dueño, pero este grupo
_no_ es el que goza de privilegios de acceso, NO podrá.

>Si el fichero no los tiene los derechos de grupo activados ni los 
>usuarios del grupo ni otros usuarios pueden leerlo ni 
>escribirlo. 

Incorrecto. Depende de los privilegios para el "resto" de los usuarios.

> Pero si tenemos un programa con el SetGID activo cualquier usuario
> **del grupo** que lo ejecute adquiere el rol del propietario y 
> entonces **si** puede modificar el fichero. Un 
>usuario que no pertenezca a algún grupo del propietario puede 
>ejecutar el programa pero dicho programa **no** puede modificar el 
>fichero. ¿Correcto?

Incorrecto. Para ejecutar el programa setuid/setgid _primero_ se necesitan
privilegios de ejecución sobre él; dichos privilegios se comportan
_exactamente_ igual que sobre un archivo, i.e. o eres el dueño, o perteneces al
grupo que el dueño a asignado al archivo o el dueño permite que "el resto" lo
ejecute. Es _irrelevante_ si el usuario intentando ejecutar pertenezca o no a
_otro_ grupo común con el dueño.

La segunda aseveración también es incorrecta; un usuario que no tenga grupos en
común con el dueño _puede_ ejecutar un programa setuig/setgid si dicho programa
tiene privilegios para ser ejecutado por "el resto". Tan pronto como el
programa se ejecuta, el usuario adquiere los privilegios del dueño/grupo del
programa, y con tales privilegios puede modificar el objecto.

Creo que tienes que leer de nuevo...

>> La mayor parte de los ataques de seguridad a sistemas Unix se basan en
>> encontrar programas setuid con malas prácticas de programación (en el 95% de
>> los casos, programadores que usan gets() para leer cadenas), de manera que con
>> un ataque a la pila de ejecución puedan obtener un shell de root. 
>
>	8-?????? ¿Podrias explicar un poco más esto, por favor?

Supongo que te refieres al ataque sobre la pila de ejecución. Hace algún tiempo
escribí una explicación detallada al respecto que puedes ubicarla en el
buscador de la lista. Muy concisamente; sabiendo como se organiza un programa
ejecutable en memoria y como utiliza la pila para manejar las variables locales
y parámetros de funciones en lenguajes de alto nivel es posible atacar un
programa en el cual se ha "confiado" en el usuario. No tiene ningún interés
atacar programas regulares, sino atacar programas setuid/setgid para obtener
mejores privilegios (después de todo, ya crackeé el usuario regular :-). El
principio es muy simple: examinando los fuentes me doy cuenta que un
programador ignorante^H^H^H^H^H^H^H^H^Hinexperto utilizó gets() para leer una
variable string en su programa y que la pasa _directa_ a una función; además el
programa es setuid/setgid... es relativamente simple generar una cadena que
tenga el _código de máquina_ para ejecutar un "shell" y suministrarlo a dicho
programa de manera tal que llene la variable, la _exceda_ en longitud,
sobreescriba la pila de ejecución y cuando la función "retorne" caiga en mi
código y me abra un shell con los privilegios setuid/setgid. Esta es una
explicación muy _abreviada_. Lo que los "script kiddies" y "hacker wannabes"
conocen como "exploits" (y por supuesto no tienen ni idea de lo que hacen,
simplemente los usan :-) son ataques a la pila de programas que tienen uso
estúpido^H^H^H^H^H^H^H^Hsin validación de gets() (y otras especies de
programación floja).

Cualquier texto introductorio a la implementación de lenguajes de programación
tiene al menos un capítulo en el cual se discute la organización en memoria
(pila de ejecución, pasaje de parámetros, etc.); refiérete a alguno de ellos
para apreciar lo que ocurre.

>> Finalmente, si un "problema" de administración parece ser resuelto escribiendo
>> un programa setuid o setgid, es _mucho_ mejor y _más_ seguro utilizar sudo para
>> delegar la labor administrativa.
>> 
>
>	8-????  ¿sudo? ¿Te importaria iluminarme?

sudo es un utilitario que permite delegar privilegios adiministrativos a
usuarios regulares _sin_ entregarles el password de root, _sin_ escribir
programas setuid/setgid y con habilidades _extensas_ de otorgar privilegios
discrecionales, restricciones de uso y logging.
--
Ernesto Hernández-Novich - Running Linux 2.2.14 - Unix: Live free or die!
One thing is to be the best, and another is to be the most popular. 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d+(-) s+: a C+++$ UBLAVHIOSC++++$ P++++$ L+++$ E- W+ N++ ?o ?K w--- O- M- V
PS+ PE Y+ PGP>++ t+ 5 X+ R* tv+ b++ DI+++$ D++ G>++ e++ h+ r+ y++
-----END GEEK CODE BLOCK-----

----------------------------------------------------------------------------
Para retirarte de la lista debes enviar un mensaje a majordomo@linux.org.ve
y en el cuerpo del mensaje colocar UNSUBscribe l-linux
----------------------------------------------------------------------------