[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]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