[Ayuda] setguid

[Miguel Ibarra]

On Mon, 2002-03-11 at 09:54, Gunnar Wolf wrote:
> Ahora, tal vez no para el traceroute (concuerdo en que es una herramienta
> muy útil), pero sí en ch*, r*, su, sudo, crontab, Xwrapper...

Uta, la mayor parte de los comandos que mencionas son explicitamente
para usuarios finales o para evitar problemas de seguridad...

ch*  sirven para que el usuario manejen su entrada del /etc/passwd, que
hueva usar una m'aquina donde el administrador no me deja cambiar mi
shell. Quiero cambiar mi shell; en lugar de correr un comando y tardarme
1/2 minuto en hacerlo si tuviera chsh, ahora tengo que pedirle de
favorcito al administrador que cuando tenga un tiempito por favor me
cambie el shell, pasan dias y mi shell por default sigue igual. Un
administrador ching'on se quita de encima todo el trabajo rutinario que
pude, sobre todo si se bloquea el trabajo de los usuarios esperando a
que un administrador haga algo. En lugar de tener a un usuario
correteadome para que le cambie su shell, en 30 segundos le digo; "usa
chsh; checa man chsh".

En lugar de partirle el queso al sudo, puedes usarlo para quitarte pedos
de seguridad, gracias!. Ejemplo; hacer respaldos es trabajo de hueva; le
pido a la secre que se los eche ella todos los viernes. Sin sudo; le
tienes que dar el password de root, no duermes tranquilo sabiendo que tu
m'aquina esta en peligro constante y latente. Con sudo; le das a la
secre poderes de root solo para los comandos que necesita para los
respaldos, o mejor a'un solo para el script de respaldo que previamente
preparaste,  vuelves a dormir tranquilo.

Quitaleselo al Xwrapper y ya ning'un usuario mortal puede correr X,
gracias. Simp'atico que quieras quitarle el setuid al Xwrapper te
platico la historia; X necesita permisos de superusuario para hacer
entre otras cosas el switcheo del modo gr'afico, etc... Originalmente X
ten'ia el setuid encendido, el pex; X es un programa ENORME, imposible
asegurar que no tiene broncas de seguridad, solucion; un programita
peque&o Xwrapper f'acil de auditar que solo hace lo que X necesita hacer
como root. Le quitas el setuid a X se lo pones a Xwrapper y ya puedes
dormir m'as tranquilo. De echo no deber'ias recomendar quitarle setuid a
Xwrapper eso descompone el X para usuarios normales.

Quitarle setuid a crontab es otra cosa que no deber'ias estar
recomendando, si se lo quitas, primero no ganas "mas seguridad",
segundo, los usuarios mortales ya no pueden usar ni cron ni at, ambos
comandos harto 'utiles. Ejemplos; a mi me gusta tener mi home bien
ordenadito, tengo un directorio SOURCES/ en todos mis homes donde guardo
todos los *.tgz, *.rpm, *tar.bz2, etc... que bajo de la red. Pero soy un
marrano, y cuando bajo paquetes NUNCA  me acuerdo de ponerlos donde
deben ir, soluci'on: escrib'i un scriptcito que busca en todo mi home
los mencionados archivos y los mueve a SOURCES/, de hecho el scriptcito
hace m'as cosas 'utiles como borrar todos los core viejos, y los
directorios creados por los *tgz que tengan m'as de una semana, etc....
Una entradita en mi crontab, corre el scripcito un par de veces a la
semana, y yo tengo fel'iz un home ordenadito sin esfuerzo. 

Ejemplo para el at; Me gusta ir a comer con los cuates de la oficina, lo
normal es que derrepente a alguien se le ocurre que ya tiene hambre y
quiere irse YA, los dem'as le hacen caso, y tienes a una bola de gueyes
enfrente de tu escritorio esperando a ver a que hora se te ocurre
levantarte para ir a comer. Algunas veces necesito correr un comand'in,
justo despu'es de que termine un proceso largo que estoy corriendo en
ese momento y que le falta poco para terminar, Que opciones tengo?

a) tronar el comando y volverlo a correr como; comando && script; 'pa
que el script se corra cuando el comando termine y largarme a comer.
Esto es feo porque despedicio todo el tiempo que el comando lleva
corriendo;

b) Irme a comer y cuando regrese seguramente el comando ya habr'a
terminado y podr'e correr el script. Esto es feo porque se desperdicia
todo el tiempo entre que el comando termina y yo regreso de comer. Y no
me puedo poner a trabajar en chinga porque todav'ia necesito correr a
mano el script y esperar a que termine.

c) Soluci'on chida, que no podr'ia hacer si el administrador de mi
m'aquina le quita el setuid a crontab. Calculo que m'aximo en media hora
el comando terminara, entonces pico en el teclado: 

echo script | at "now + 45 min"

me largo a comer y cuando regrese el script ya habr'a corrido y puedo
seguir trabajando en chinga.

Otro ejemplo del at; no m'as porque tengo ganas de escribir; en la
oficina me asesinan si ocupo demasiado ancho de banda en horas de
oficina, pero me encanta napster, gnutella et al. Nadie la hace de tos,
si ocupo 100% de ancho de banda en la noche/madrugada. Lo que hago es
antes de irme pongo a bajar lo que quiero, 'che lista de 100+ cosas.
Corro el comando: 

echo "killall gtk-gnutella" | at 08:30

La bronca de los respaldos tambi'en se puede solucionar con crontab,
pero tengan cuidado, los respaldos se tienen que verificar justo depu'es
de hacerlos. !los respaldos autom'aticos son peligrosos a menos que la
verificaci'on tambi'en sea autom'atica!.

Todas esta cosas 'utiles que cualquiera podr'ia hacer, no se pueden si
tu quitas setuids. No ganas seguridad y haces a tus usuarios menos
productivos.


uta!, 'che choro me avent'e, pero todav'ia tengo un poco m'as; 

!NO ADMINISTREN DE OIDAS!, NO ADMINISTREN ADIVINANDO. Tienen siempre que
entender que estan haciendo cuando administran una m'aquina. No quiten
setuid's nom'as porque alguien les dijo o porque "les late" que asi la
m'aquina va a ser m'as segura. Si lo hacen as'i, en el mejor de los
casos s'olo estaran incomodandole la vida a sus usuarios y lo normal es
que le partan el queso a su configuraci'on.

Ejemplo de la vida real; ten'ia un "administrador" a mi cargo que una
vez vio los permisos de /tmp; 

ls -ld /tmp
drwxrwxrwt   72 root     root        12288 Mar 11 12:08 /tmp

"'Orale" --dijo el desdichado "tiene todos los permisos!, me late que
eso es muy inseguro". R'apido y vel'oz hizo su m'aquina "m'as segura"
corrio "chmod 770 /tmp". "As'i ya no hay bronca de seguridad" --pens'o
el pasguato. Evidentemente su m'aquina dej'o de funcionar bien, la mitad
de los demonios tuvieron broncas y se murieron, la resete'o, y casi
ning'un servicio levant'o, la m'aquina quedo INUSABLE, la cura fue
regresarle a /tmp su permisos correctos, y darle un coscorr'on al
"administrador".



Para contestar la pregunta original que fue algo asi como:

"Estos son los archivos que tienen setuid prendido en mi m'aquina, ?A
cuales se los deber'ia quitar?".

La respuesta es;

A ning'uno, esos permisos los puso gente que sab'ia mejor que t'u lo que
estaba haciendo. Mientras no tengas una raz'on espec'ifica para quitar
un setuid no lo hagas. El setuid no es un problema de seguridad por si
mismo. Quitando un setuid no necesariamente logras m'as seguridad".

Hay varias reglas de dedo que necesitan obedecer:

a) Si no esta descompuesto, no lo compongas.
b) Si no necesitas tomar una decis'i'on, entonces, necesitas NO tomar
una decisi'on.

--
Saluditos!
_______________________________________________
Ayuda mailing list
Ayuda en linux.org.mx