[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]Miguel Ibarra wrote: > 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. > Bueno, yo me quiero imaginar que todo este desmadre de los setuids se originó a partir de una persona que leyó las instrucciones que están en la página de la ASC de la DGSCA porque ahí dice que hay que correr el script que te muestra todos los archivos con esa bandera y quitársela a los que no la necesitan. En este caso es conveniente que alguien que conozca a la persona que hizo esa página le mande los comentarios de por qué no se les debe quitar esa bandera a que archivos. Si no se corrige esa página se va a volver a repetir este caso de personas que interpretan mal las instrucciones y se confunden..... Pero por otro lado, la búsqueda de puertas traseras debe ser proactiva y para eso se inventaron herramientas como el tripwire, el aide y el viperdb que se usan para detectar cuando alguien ha modificado algún archivo importante o cuando alguien instaló algo que no debió haber instalado como por ejemplo puertas traseras o root kits. -- Sandino Araico Sánchez >drop table internet; OK, 135454265363565609860398636678346496 rows affected. "oh fuck" --fluxrad _______________________________________________ Ayuda mailing list Ayuda en linux org mx