Desarrollo de una Política de Seguridad

Desarrollo de una Política de Seguridad
Has de crear una política simple y genérica para tu sistema, que sus usuarios puedan fácilmente entender y seguir. Debe proteger los datos que estás salvaguardando así como la privacidad de los usuarios. Algunas cosas a considerar para añadir son: quién tiene acceso al sistema (¿puede mi amigo usar mi cuenta?), quién tiene permitido instalar software en el sistema, quién posee qué datos, la recuperación de desastres y el uso apropiado del sistema. Una política de seguridad generalmente aceptada comienza con la frase Lo que no está permitido está prohibido Esto significa que, a menos que tú concedas acceso a un servicio a un usuario, este usuario no podrá usar ese servicio hasta que tú le des acceso. Asgúrate de que las políticas funcionan en tu cuenta regular de usuario. Decir: "Ah, no puedo resolver este problema de permisos, lo haré como root" te puede llevar a agujeros de seguridad que son muy obvios, e incluso a algunos que no han sido explotados todavía. rfc1244 es un documento que describe cómo crear tu política de seguridad en tu propia red. rfc1281 es un documento que muestra un ejemplo de política de seguridad con descripciones detalladas de cada paso. Por último, podrías querer echar un vistazo al archivo de política del COAST en ftp://coast.cs.purdue.edu/pub/doc/policy para ver a qué se parecen algunas políticas de seguridad de la vida Medios de asegurar tu sitio Este documento discutirá diversos medios con los cuales puedes asegurar las cosas por las que has estado trabajando duro: tu equipo local, tus datos, tus usuarios, tu red e incluso tu reputación. ¿Qué le sucedería a tu reputación si un intruso borrara datos de algunos de tus usuarios? ¿O deformara tu sitio web? ¿O publicara el plan de proyecto corporativo para el próximo cuatrimestre de tu empresa? Si estás planificando la instalación de una red, hay muchos factores que debes tomar en cuenta antes de añadir una sola máquina a tu red. Aunque tengas una sola cuenta telefónica PPP, o sólo un pequeño sitio, esto no significa que los intrusos no estén interesados en tus sistemas. Los sitios grandes y de perfil alto no son los únicos objetivos -- muchos intrusos simplemente quieren reventar tantos sitios como les sea posible, sin que importe su tamaño. Además, pueden usar un agujero de seguridad en tu sitio para lograr acceso a otros sitios a los que estás conectado. Los intrusos tienen un montón de tiempo y pueden eludir averiguar cómo has oscurecido tu sistema intentando todas las posibilidades. Hay también otras muchas razones por las que un intruso puede estar interesado en tu sistema, que se discutirán Seguridad del Host Quizás el área de seguridad sobre la cual los administradores se concentran más es la seguridad base del host. Por lo general esto implica estar seguro de que tu propio sistema es seguro, y esperar que cualquier otro de tu red haga lo mismo. Elegir buenas contraseñas, asegurar los servicios de red local del host, mantener buenos registros de las cuentas y mejorar los programas con exploits de seguridad conocidos, están entre las cosas que el administrador de seguridad local tiene la responsabilidad de hacer. Aunque esto es completamente necesario, puede convertirse en una tarea desalentadora desde que tu red sea mayor de unas cuantas máquinas. Seguridad de la red La seguridad de la red es tan necesaria como la seguridad del host local. Con cientos, miles o más computadores en la misma red, no puedes confiar en que cada uno de estos sistemas sea seguro. Asegurarte de que sólo los usuarios autorizados pueden usar tu red, construir cortafuegos, usar encriptación fuerte y asegurarte de que no haya máquinas "rogue" (esto es, inseguras) en tu red, son parte los deberes de un administrador de seguridad de red. Este documento discutirá algunas de las técnicas usadas para asegurar tu sitio y esperamos enseñarte algunas maneras de impedir a un intruso lograr acceso a lo que estás tratando de proteger. Seguridad mediante Oscuridad Un tipo de seguridad que debe ser discutida es la "seguridad mediante oscuridad". Esto quiere decir, por ejemplo, mover un servicio vulnerable en seguridad a un puerto no estándar con la esperanza de que los atacantes no se den cuenta de que está ahí y así no lo exploten. Ten por seguro que pueden determinar que está ahí y lo explotarán. La seguridad mediante oscuridad no es seguridad en absoluto. Simplemente porque tengas un pequeño sitio, o un perfil relativamente bajo, no significa que un intruso no pueda estar interesado en lo que tienes. Discutiremos lo que estás protegiendo en las siguientes secciones. después. Organización de este Documento Este documento se ha dividido en secciones que cubren diversas cuestiones amplias de seguridad. La primera, Seguridad Física, abarca cómo necesitas proteger tu equipo físico de la intromisión. La segunda, Seguridad Local, describe cómo proteger tu sistema de intromisiones de los usuarios locales. La tercera, Seguridad de Ficheros y Sistemas de Ficheros, te enseña a configurar tus sistemas de ficheros y los permisos sobre tus ficheros. La siguiente, Seguridad de Contraseñas y Encriptación, discute cómo usar la encriptación para asegurar mejor tu equipo y tu red. Seguridad del núcleo discute las opciones de núcleo que debes configurar o tener en cuenta para tener un sistema seguro. Seguridad de la red, describe cómo asegurar mejor tu sistema Linux de ataques a la red. Preparación para la Seguridad, discute cómo preparar tu(s) equipo(s) antes de ponerlos en línea. Después, ¿Qué hacer durante y después de una Ruptura, discute qué hacer cuando detectas que está ocurriendo algo que compromete al sistema o detectas que ha ocurrido recientemente. En Recursos de Seguridad, se enumeran algunos recursos básicos de seguridad. La sección P y R Preguntas Frecuentemente Hechas, responde algunas preguntas frecuentemente realizadas y, finalmente, una sección de conclusión en Conclusión. Los dos principales puntos a tener presente cuando se lea este documento son: Sé consciente de tu sistema. Comprueba los logs de sistema tales como /var/log/messages y mantén el ojo sobre tu sistema. Mantén tu sistema puesto al día asegurándote de que has instalado las versiones actuales de software y has mejorado las alertas de seguridad. Sólo con hacer esto ayudarás a que tu sistema sea notablemente más seguro. Seguridad Física El primer escalón de seguridad que se necesita tener en cuenta es la seguridad física de tus sistemas de computadores. ¿Quién tiene acceso físico directo a tu equipo? ¿Debe tenerlo? ¿Puedes proteger tu equipo de su entrometimiento? ¿Debes hacerlo? Cuánta seguridad física necesitas en tu sistema depende mucho de tu situación y/o presupuesto. Si eres un usuario doméstico, probablemente no necesites mucha (aunque podrías necesitar proteger tu equipo de la intromisión de niños o parientes fastidiosos). Si estás en un laboratorio, necesitas considerablemente más, pero los usuarios aún necesitan poder obtener el trabajo hecho con las máquinas. Muchas de las siguientes secciones te ayudarán con esto. Si estás en una oficina, puedes o no necesitar asegurar tu máquina algunas horas o mientras estás fuera. En algunas empresas, dejar tu consola sin asegurar es causa de despido. Los métodos obvios de seguridad física tales como cierres de puertas, cables, cabinas cerradas y vigilancia por vídeo son todas buenas ideas, pero están más allá del alcance de este documento. :) Cierre del Computador Muchas carcasas de los modernos PCs incluyen una opción de "cierre". Normalmente será una cerradura en el frente de la carcasa que te permite girar la llave que trae a una posición abierta o cerrada. El cierre de la carcasa puede ayudar a impedir que alguien te robe tu PC, o que abra la carcasa y manipule/robe directamente tu hardware. A veces también impide que alguien reinicie tu computador con su propio diskette u otro hardware. Estos cierres de carcasa hacen cosas diferentes según el soporte en la placa base y de cómo esté construída la carcasa. En muchos PCs lo hacen de modo que hay que romper la carcasa para abrirla. En otros, lo hacen de modo que no te permite enchufar en ella nuevos teclados y ratones. Comprueba tu placa base o las instrucciones de la carcasa para más información. A veces esta puede ser una característica muy útil, aún cuando los cierres normalmente son de muy baja calidad y pueden ser vencidos fácilmente por atacantes con conocimientos de cerrajería. Algunas carcasas (más notablemente las de SPARC y mac) tienen una mochila por detrás que, si pones un cable alrededor, los atacantes tendrán que cortar el cable o romper la caja para entrar. El mero hecho de poner una cerradura o un cierre de combinación, puede ser un buen elemento disuasorio para alguien que intente robar tu equipo. Seguridad del BIOS El BIOS es el nivel más bajo de software que configura o manipula tu hardware para x86. LILO y otros métodos de inicio de Linux acceden al BIOS para determinar cómo iniciar tu equipo Linux. Otro hardware que se ejecuta en Linux tiene un software similar (OpenFirmware en Macs y los nuevos Suns, el inicio de Sun PROM, etc...). Puedes usar tu BIOS para impedir que los atacantes reinicien tu equipo y manipulen tu sistema Linux. Muchos BIOS de PC permiten poner una contraseña de inicio. Esto no proporciona mucha seguridad (el BIOS se puede reconfigurar, o quitarse, si alguien entra en la caja), pero podría ser un buen elemento disuasorio (esto es, lleva tiempo y deja huellas de la intrusión). De modo similar, en S/Linux (Linux para las máquinas procesadoras SPARC(mr)), tu EEPROM puede configurarse para pedir una contraseña de inicio. Esto podría tumbar a los atacantes torpes. Muchos BIOS de x86 también permiten especificar otras diversas configuraciones de seguridad buenas. Comprueba tu manual de BIOS o míralas la próxima vez que inicies. Por ejemplo, algunos BIOS no permiten iniciar desde unidades de discos floppy y algunos requieren contraseñas para acceder a algunas características del BIOS. Nota: Si tienes un equipo servidor y estableces una contraseña de inicio, tu equipo no se iniciará sin atención. Recuerda que necesitarás venir y entrar la contraseña en el caso de un fallo de energía. ;( Seguridad del cargador de Inicio Los distintos cargadores de inicio de Linux pueden tener también un juego de contraseña de inicio. LILO, por ejemplo, tiene password y restricted; password requiere siempre la contraseña en el momento del inicio, mientras que restricted requiere una contraseña para inicio sólo si se especifican algunas opciones (tales como single) en el indicador de LILO . Ten presente cuando establezcas todas estas contraseñas que necesitarás recordarlas. :) Recuerda también que estas contraseñas meramente retrasarán al atacante resuelto. No impedirán a alguien iniciar desde un floppy y montar tu partición de root. Si vas a usar seguridad junto con el cargador de inicio, podrías también desactivar el inicio desde un floppy en el BIOS de tu computador y proteger el BIOS con contraseña. Si alguien tiene información relacionada con la seguridad desde un cargador de inicio diferente, nos encantaría oirla. (grub, silo, milo, linload, etc). Nota: Si tienes un equipo servidor y estableces una contraseña de inicio, tu equipo no se iniciará sin atención. Recuerda que necesitaras venir y poner la contraseña en el caso de un fallo de corriente. ;( xlock y vlock Si te alejas de tu máquina de vez en cuando, es bueno poder "cerrar" tu consola para que nadie la asalte o mire tu trabajo. Dos programas que hacen esto son: xlock y vlock. xlock es un cierre X de presentación en pantalla. Debe estar incluido en todas las distribuciones de Linux que soporten X. Comprueba la página correspondiente del manual para más opciones, pero en general puedes ejecutar xlock desde cualquier terminal x de tu consola y se cerrará la pantalla, que requerirá tu contraseña para abrirse. vlock es un programita simple que te permite cerrar algunas o todas las consolas virtuales en tu sistema Linux. Puedes cerrar sólo aquella en la que estás trabajando o todas. Si sólo cierras una, otros pueden entrar y usar la consola; no podrán usar tu consola virtual hasta que la abras. vlock viene con Linux Redhat, pero tus resultados pueden ser diferentes. Cerrar la consola impedirá a alguien entrometerse en tu trabajo, pero desde luego no le impedirá reiniciar tu equipo o estropear de otro modo tu trabajo. Tampoco le impedirá acceder a tu equipo desde otra equipo en la red y causar problemas. Más importante, no impide a alguien desconectar completamente el Sistema X Window, ir al indicador de conexión de una consola virtual normal, o al VC desde el cual se arrancó el X11, suspenderlo y así obtener tus privilegios. Por esta razón, deberías considerar usarlo sólo bajo control de xdm. Detectar Compromisos de Seguridad Física La primera cosa a comprobar siempre es cuándo fue reiniciado tu equipo. Dado que Linux es un sistema operativo (SO) robusto y estable, las únicas veces que tu equipo debe reiniciarse es cuando tú lo desmontas para mejoras en el SO, recambios de hardware o cosas así. Si tu equipo ha sido reiniciado sin tú hacerlo, eso puede ser un signo de que un intruso lo ha puesto en peligro. Muchos de los modos en que tu equipo puede verse comprometido requieren que el intruso reinicie o apague el equipo. Comprueba los signos de intrusión en la carcasa y el área del computador. Aunque muchos intrusos limpian las huellas de su presencia de los logs, es una buena idea comprobarlos todos y anotar cualquier discrepancia. También es una buena idea almacenar los datos de log en un lugar seguro, tal como un servidor dedicado a log dentro de tu red bien protegida. Una vez que un equipo ha estado comprometido, los datos de log serán de poca utilidad porque lo más probable es que también hayan sido modificados por el intruso. El demonio syslog puede ser configurado para enviar automáticamente datos de log a un servidor central de syslog, pero normalmente se envían datos en texto plano, permitiendo a un intruso ver los datos cuando están siendo transferidos. Esto puede revelar información sobre tu red que no quieres que sea pública. Hay disponibles demonios syslog que encriptan los datos cuando se están enviando. Sé consciente también de que falsificar mensajes de syslog es fácil - con un programa de exploit que haya sido publicado. Syslog incluso acepta entradas de log de red que dicen venir del host local sin indicar su origen verdadero. Algunas cosas a comprobar en tus logs: Logs cortos o incompletos. Logs que contengan registros de fecha extraños. Logs con permisos o propietarios incorrectos. Registros de reinicios o de recomienzo de servicios. Logs perdidos. Entradas su o logins desde sitios extraños. Discutiremos los datos de log del sistema más adelante en este COMO. Seguridad Local La siguiente cosa a mirar es la seguridad de tu sistema contra los ataques procedentes de usuarios locales. ¿Dijimos usuarios locales? ¡Sí! Una de las primeras cosas que intentan los intrusos de un sistema como vía para explotar la cuenta de root es obtener acceso a una cuenta de usuario local. Con una seguridad local laxa, pueden entonces "mejorar" su acceso de usuario normal a acceso de root usando diversos bugs y servicios locales pobremente configurados. Si te aseguras de que tu seguridad local es adecuada, entonces el intruso tendrá que superar otro obstáculo. Los usuarios locales también pueden ocasionar un montón de estragos en tu sistema, incluso (especialmente) si son realmente quienes dicen que son. Proporcionar cuentas a gente que no conoces o de la que no tienes información de contacto es una idea muy mala. Crear Nuevas Cuentas Asegúrate de que provees cuentas de usuario sólo con los requerimientos minimos para la tarea que necesiten hacer. Si proporcionas a tu hijo (10 años) una cuenta, podrías querer que él sólo tenga acceso a un procesador de textos o un programa de dibujo, pero que le sea imposible borrar datos que no son suyos. Algunas buenas reglas empíricas sobre permitir a otra gente acceso legítimo a tu máquina Linux: Darles la cantidad mínima de privilegios que necesiten. Ser consciente de desde cuándo/dónde se conectan o se deberían estar conectando. Asegúrate de remover las cuentas inactivas. El uso del mismo ID de usuario en todos los computadores y redes es aconsejable para facilitar el mantenimiento del recuento, así como para permitir un análisis más fácil de los datos de log. La creación de ID de usuario de grupo debería estar absolutamente prohibida. Las cuentas de usuario también proporcionan transparencia y esto no es posible con cuentas de grupo. Muchas cuentas de usuario local que se usan en los compromisos de seguridad son las que no han sido usadas durante meses o años. Dado que nadie está usándolas, proporcionan el vehículo ideal de ataque. Seguridad del Root La cuenta más buscada en tu equipo es la cuenta de root (superusuario). Esta cuenta tiene autoridad sobre toda el equipo, lo cual puede incluir también autoridad sobre otros equipos en la red. Recuerda que sólo debes usar la cuenta de root para tareas muy cortas y específicas y que mayormente debes ejecutar programas como un usuario normal. Incluso los pequeños errores que cometas mientras estés conectado como root pueden causar problemas. Mientras menos tiempo estés conectado con privilegios de root, más seguro estarás. Varios trucos para evitar echar a perder como root tu propio equipo: Al realizar algún comando complejo, intenta ejecutarlo primero en modo no destructivo... especialmente los comandos que usen comodines: p.e., si quieres hacer "rm foo*.bak", primero haz "ls foo*.bak" y asegúrate que vas a borrar los archivos que piensas que vas a borrar. Usar echo en lugar de comandos destructivos también funciona a veces. Proporciona a tus usuarios un alias por defecto para que el comando rm les pida confirmación para el borrado de archivos. Conviértete en root sólo para hacer tareas simples y específicas. Si estás intentando planificar cómo hacer algo, vuelve al shell de usuario normal hasta que estés seguro de lo que necesita ser hecho por el root. El comando path es muy importante para el usuario root. El comando path (esto es, la variable de entorno PATH) especifica los directorios en los que el shell busca los programas. Procura limitar el comando path para el usuario root tanto como sea posible y nunca incluyas . (que significa "el directorio actual") en tu PATH. Además, nunca tengas directorios escribibles en tu path de búsqueda, dado que esto puede permitir a los atacantes modificar o poner nuevos binarios en tu path de búqueda, permitiéndoles ejecutar como root la próxima vez que ejecutes ese comando. Nunca uses como root el conjunto de herramientas rlogin/rsh/rexec (las llamadas utilidades-r). Están sujetas a muchos tipos de ataques y es absolutamente peligroso ejecutarlas como root. Nunca crees un archivo .rhosts para el root. El archivo /etc/securetty contiene una lista de terminales desde los que puede conectarse el root. Por defecto (con Linux Red Hat) esto se pone sólo para las consolas virtuales locales (vtys). Ten mucho cuidado al añadir cualquier otra cosa a este archivo. Tendrías que ser capaz de conectar remotamente como tu cuenta de usuario regular y entonces hacer su si lo necesitas (esperemos que sobre ssh u otro canal encriptado), así que no hay necesidad de conectar direcamente como root. Actúa despacio y de forma meditada cuando ejecutes programas como root. Tus acciones podrían afectar a un montón de cosas. ¡Piensa antes de teclear! Si irremediablemente necesitas permitir que alguien (mejor de mucha confianza) tenga acceso como root a tu máquina, hay algunas herramientas que te pueden ayudar. sudo permite a los usuarios usar su contraseña para acceder como root a un conjunto restringido de comandos. Esto te posibilitaría, por ejemplo, permitir que un usuario pueda extraer y montar medios removibles en tu sistema Linux, pero no tener otros privilegios de root. sudo también mantiene un log de todos los intentos sudo exitosos y fracasados, permitiéndote rastrear quién usó qué comando para hacer qué. Por esta razón sudo funciona bien incluso en lugares donde muchas personas tienen acceso de root, porque te ayuda a mantener un registro de los cambios realizados. Aunque sudo puede usarse para dar a usuarios específicos privilegios específicos para tareas específicas, tiene varios defectos. Debe usarse sólo para un conjunto limitado de tareas, como reiniciar un servidor o añadir nuevos usuarios. Cualquier programa que ofrece una salida al shell dará acceso de root a un usuario que lo pida vía sudo. Esto incluye a la mayoría de los editores, por ejemplo. También un programa tan inocuo como /bin/cat puede usarse para sobreescribir archivos, lo que podría permitir que el root fuese explotado. Considera sudo como un medio de contabilidad y no esperes que sustituya al usuario root y que encima sea seguro. Seguridad de ficheros y del sistema de ficheros Algunos minutos de preparación y planificación antes de poner tus sistemas online puede ayudar a protegerlos a ellos y a los datos almacenados en ellos. Nunca debe haber una excusa para que los usuarios ejecuten programas SUID/SGID desde sus directorios home. Usa la opción nosuid en /etc/fstab para particiones que sean escribibles por otros que no sean root. También puedes querer usar nodev y noexec sobre particiones home de usuarios, así como /var, prohibiendo de este modo la ejecución de programas y la creación de dispositivos de carácter o de bloque, que de todos modos nunca serían necesarios. Si estás exportando sistemas de ficheros usando NFS, asegúrate de configurar /etc/exports con el acceso más restrictivo posible. Esto significa no usar comodines, no permitir acceso de escritura de root y exportar ficheros de sólo-lectura siempre que sea posible. Configura tu umask de creación de archivos de usuarios para que sean tan restrictivos como sea posible. Ver configuraciones de umask. Si estás montando sistemas de ficheros usando un sistema de ficheros de red tal como NFS, asegúrate de configurar /etc/exports con restricciones adecuadas. Normalmente, es deseable usar `nodev', `nosuid' y, quizás, `noexec'. Poner límites al sistema de ficheros en vez de dejarlo ilimitado como viene por defecto. Puedes controlar los límites por usuario usando el módulo PAM de límites de recursos y /etc/pam.d/limits.conf. Por ejemplo, los límites para el grupo usuarios podrían parecerse a esto: · @users hard core 0· @users hard nproc 50· @users hard rss 5000 Esto significa prohibir la creación de ficheros core, restringir el número de procesos a 50 y restringir el uso de memoria por usuario a 5M. Los ficheros /var/log/wtmp y /var/run/utmp contienen los registros de conexión de todos los usuarios en tu sistema. Debe mantenerse su integridad porque pueden usarse para determinar cuándo y desde dónde ha entrado un usuario (o un intruso potencial) en tu sistema. Estos ficheros también deben tener permisos 644 sin afectar a la operación normal del sistema. El bit inmutable puede usarse para impedir borrar o sobreescribir accidentalmente un fichero que debe ser protegido. También impide que alguien cree un enlace simbólico al fichero (tales enlaces simbólicos han sido la fuente de ataques incluyendo borrar /etc/passwd o /etc/shadow). Ver la página para chattr(1) del manual para información sobre el bit inmutable. Los ficheros SUID y SGID de tu sistema son un riesgo potencial de seguridad y deben ser manejados cuidadosamente. Dado que estos programas conceden privilegios especiales al usuario que está ejecutándolos, es necesario asegurarse de que no se instalen programas inseguros. Un truco favorito de los crackers es explotar programas SUID de root y dejar un programa SUID como puerta trasera para entrar la próxima vez, incluso si el agujero original es tapado. Encuentra todos los programas SUID/SGID en tu sistema y mantén un registro de lo que son, para que seas consciente de cualesquiera cambios que te podrían indicar que hay un intruso potencial. Usa el comando siguiente para encontrar todos los programas SUID/SGID en tu sistema: root# find / -type f \( -perm -04000 -o -perm -02000 \) La distribución Debian ejecuta cada noche la tarea de determinar qué ficheros SUID existen. Luego compara esto a lo de las noches previas. Puedes verlo en /var/log/suid* para este log. Puedes quitar los permisos SUID o SGID a un programa sospechoso con chmod, después cambialo de nuevo si crees que es absolutamente necesario. Los ficheros escribibles por todo el mundo, particularmente los ficheros de sistema, pueden ser un agujero de seguridad si un cracker logra acceso a tu sistema y los modifica. Además, los directorios escribibles por todos son peligrosos, dado que permiten a un cracker añadir o borrar ficheros a su antojo. Para localizar todos los ficheros escribibles por todos en tu sistema, usa el siguiente comando: · root# find / -perm -2 ! -type l -ls y asegúrate de que sabes por qué esos ficheros son escribibles. En el curso normal de la operación, diversos ficheros serán escribibles por todos, incluyendo algunos desde /dev, y enlaces simbólicos, así el ! -type l que excluye a éstos del comando previo find. · Los ficheros sin propietario también pueden ser un indicio de que un intruso ha accedido a tu sistema. Puedes localizar en tu sistema los ficheros sin propietario, o que no pertenezcan a ningún grupo, con el comando: · root# find / -nouser -o -nogroup -print Encontrar ficheros .rhosts debería ser parte de tus deberes regulares de administración del sistema, puesto que estos ficheros no deben estar permitidos en tu sistema. Recuerda: un cracker sólo necesita una cuenta insegura para, potencialmente, lograr acceso a toda tu red. Puedes localizar todos los ficheros .rhosts en tu sistema con el siguiente comando: · root# find /home -name .rhosts -print · Finalmente, antes de cambiar los permisos sobre cualesquiera ficheros de sistema, asegúrate de que entiendes lo que estás haciendo. Nunca cambies los permisos sobre un fichero porque parezca el modo más fácil de lograr que las cosas funcionen. Determina siempre por qué el fichero tiene ese permiso antes de cambiarlo.