El sistema GNU/Linux, al igual que su inspiración Minix, y la raíz de estos sistemas, Unix, se basan en ficheros. Todo es un fichero. Por ello, la seguridad de acceso a este tipo de información es muy importante.

Usuarios y Grupos

Los sistemas *nix, se basan en una estructura basada en grupos y usuarios. Un usuario puede ser una persona que tiene acceso al sistema mediante una contraseña y usa una consola, o puede ser un programa, un sistema servidor o un concepto abstracto (por ejemplo cdrom) en el que se agrupan una serie de ficheros, ejecución de servicios o servidores, etc.

Los grupos son como los usuarios, es decir, pueden tener propiedad sobre un fichero. Esto se hace para limitar o facilitar el acceso a los ficheros a un grupo de usuarios. Cada usuario puede estar en uno o varios grupos, así como cada grupo puede tener uno o varios usuarios.

… ¿y como se enlaza todo esto?

Los permisos en los sistemas *nix se basan en tres partes. Cada fichero y directorio tiene permisos específicos para: usuario, grupo y otros. Esto quiere decir que, si el fichero pertenece a un usuario y a un grupo determinado, podemos limitar los permisos para este usuario en particular, para ese grupo y para los demás.

Al realizar ls -lh en la consola es cuando se ve esta información en consola:

-rwxr-xr-x     1 bombadil  users      2K 12 nov  2009 marubio.jpg
-rw-r--r--     1 bombadil  users     50B  2 nov  2009 marubio.txt
-rwxr-xr-x     1 bombadil  users      5K 12 nov  2009 marubio2.jpg

Como se puede ver, la primera columna de la izquierda, hay un guión inicial que indica si es directorio (d) o fichero (-), después, se indican tres letras por tipo de permisos, en este caso sería:

• rwx, para el usuario, se dan los permisos de lectura (r), escritura (w) y ejecución (x).
• r-x, para los usuarios que no sean bombadil y pertenezcan al grupo users, se dan los permisos de lectura (r) y ejecución (x).
• r-x, y para los usuarios que no sean bombadil, ni pertenezcan al grupo users, se le dan los permisos de lectura (r) y ejecución (x).

¿Qué es eso de ejecución?

Básicamente, los permisos varían si se trata de un fichero o de un directorio, ya que la lectura (r) indica que se pueda leer el fichero o ver los ficheros que hay dentro de un directorio, así la escritura (w) indica que se pueda cambiar un fichero o crear ficheros en un directorio.

El permiso más extraño, el de ejecución (x), en caso de un fichero indica que se pueda ejecutar. Es decir, si se trata de un shell script, un programa compilado, o un script de consola de tipo python, etc., que se pueda ejecutar directamente (sino habría que lanzarlo desde algún intérprete.

En el caso de un directorio, indica si se puede acceder al directorio o no. Es curioso porque es casi como el atributo de lectura, solo que si tienes lectura y no escritura, se permite listar el directorio, pero no acceder con el comando chdir (o cd).

Equivalencia numérica

Hay mucha gente que esto de rwx le sonará un poco a chino y pensará… los permisos de tipo rwxr-xr-x son los 755 de toda la vida

Pues sí, los permisos se pueden dar de forma numérica también, teniendo en cuenta de que son valores octales, se puede dar un valor desde 000 a 777, siendo el primer dígito para el usuario, el segundo para el grupo y el último para los otros. Por tanto:

0 -> ---
1 -> --x
2 -> -w-
3 -> -wx
4 -> r--
5 -> r-x
6 -> rw-
7 -> rwx

Permisos especiales

Además de todo esto, hay dos permisos especiales que tienen unas propiedades bastante curiosas. El primero de ellos es el superuser grant. Este permiso se puede otorgar a programas que se deban de ejecutar como superusuario, pero solo se pueda dar a binarios, los programas de tipo scripting no tienen esta propiedad, ya que, realmente, se ejecutan desde un intérprete que no tendrá este bit de permiso activo.

Como ejemplo, podemos ver el programa passwd. Este programa ejecutado desde consola necesita acceder a ficheros como shadow y passwd para poder cambiar la clave del usuario:

-rwsr-xr-x 1 root root 39K dic  6  2009 /usr/bin/passwd

El segundo permiso especial es el sticky. Este permiso se otorga en especial a los directorios. Cuando un directorio tiene este permiso, quiere decir que cualquier usuario podrá tener acceso al directorio y crear incluso ficheros, pero no podrá modificar y ver nada más que los que sean de su propiedad.

Este atributo es el que se suele usar para el directorio tmp de los sistemas *nix, de servidores multiusuario. Cuando un programa necesita volcar información en este directorio, con este atributo, nos aseguramos que ningún otro usuario puede modificar o ver esta información temporal:

drwxrwxrwt 5 root root 12K ago  5 18:32 /tmp

Conclusiones

Los sistemas *nix tienen sistemas de permisos y usuarios muy simples, comparados con los sistemas de permisos de sistemas con Windows. Esto no quiere decir que sean peores ni mejores, son simples, y por ello flexibles y potentes. Así mismo, en los sistemas GNU/Linux se han implementado unas políticas añadidas de seguridad que no solo permiten el acceso o no a un recurso, sino a nivel de aplicación, el uso de una forma u otra de ese recurso.

No obstante, y sinceramente, el uso llano de estos permisos suele ser suficiente para la mayoría de los casos, no necesitando ninguna capa más que afine el nivel de privilegios, cuyo uso suele ser más complejo.

Entradas relacionadas:

1. Servidor de hora en GNU/Linux
2. Debootstrap: probar sin ensuciar
3. Redes en Linux

El lenguaje Perl me llamó la atención, sobre el resto, porque había sido un lenguaje creado por Larry Wall, un administrador de sistemas… ¡en un mes!, supongo que lo que creó fue la parte más básica del sistema, pero al mismo tiempo la más importante, ya que, como él mismo comenta, Perl fue la simplificación del uso de herramientas como awk, sed, shell script y C.

En la mayoría de trabajos que he tenido, después de eso, cuando un administrador de sistemas desarrollaba algún proyecto, alguna aplicación o decía que programaba, lo hacía en Perl. No en vano, ha sido considerado por muchas distribuciones, empresas y comunidades, como el lenguaje de facto para las actividades típicas de administración de sistemas, entre las que se encuentran tareas tan vitales como: la instalación del sistema, asistentes de configuración, pasarelas intermedias (como amavis)…

Uno de los grandes miedos de la gente que programa en este lenguaje, es la mítica frase de que Perl es un lenguaje write-only, es decir, de los que se usan solo para escribir código que no hace falta mantener (o de usar y tirar), aunque proyectos grandes y la comunidad en sí manteniendo y ampliando el lenguaje, han demostrado que Perl es un gran lenguaje de programación en el que se pueden desarrollar grandes cosas y darles mantenimiento sin problema ni riesgo.

El libro que aconsejo para adentrarse en el mundo de Perl es el que escribió su creador, Larry Wall, aunque a partir de su tercera edición, que está acompañada de mucho más contenido aportado por autores como Tom Christiansen, uno de los primeros que se sumó al mundo y comunidad de Perl; y Jon Orwant, el editor de The Perl Journal, cuya publicación cesó hace ya algunos años.

El libro es algo extenso y asusta al primer vistazo, no en vano son 1070 páginas. Pero una vez se ha abierto y visto el índice, se entiende su extensión y deja de asustar. Realmente, el libro se parte en cinco apartados bien diferenciados:

• Introducción… bueno, esta la podemos leer a modo informativo, o podemos obviarla. Son unas 50 páginas.
• Los detalles desagradables… un título un poco extraño, pero se entiende, porque son los detalles del lenguaje en sí, lo que permite, lo que se puede hacer con él, la sintaxis, los elementos… todo. Es la parte más importante del libro, en mi parecer. Unas 350 páginas, más o menos.
• Perl como Tecnología, nos adentra en lo que hace el intérprete internamente, cómo se puede optimizar su uso, el depurador, los hilos, interfaz con C… sería la parte avanzada del lenguaje. Unas 150 páginas.
• La Cultura de Perl, es el uso de CPAN, el administrador de paquetes, prácticas comunes, seguridad, haciendo Perl portable entre plataformas, documentación, etc. Un poco de Perl en la comunidad y cómo compartir código en la forma en la que lo hacen muchos. Unas 100 páginas.
• Material de Referencia… como no podía faltar, toda la referencia de los paquetes básicos de las librerías que trae consigo Perl. Esta quizás es la parte más extensa del libro, pero la que más se puede emplear en el día a día, realmente.

Una lectura muy recomendable para todos aquellos que quieren adentrarse en la programación de Perl de una forma más íntima, conociendo la comunidad, cómo compartir código, cómo aprovechar el código que ya está disponible para Perl y las mejores prácticas de programación en este lenguaje.

Entradas relacionadas:

1. Ruby para programadores de PHP
2. Lenguajes de Programación

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

No hay entradas relacionadas.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

No hay entradas relacionadas.

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

Entradas relacionadas:

1. ¡Debian Lenny 5.0 ya es estable!
2. SQL Server vía ODBC en Debian Etch
3. Software empaquetado y listo para usar

Aquí os dejo el enlace: PostgreSQL: Instalación, Configuración y Trucos.

Entradas relacionadas:

1. MVCC: Control de Concurrencia para Múltiples Versiones de PostgreSQL
2. Base de Datos Relacionales: SQLite, MySQL y PostgreSQL
3. Asterisk: Configuración de Zapata

En este caso, voy a explicar como instalar y usar SQL Server vía ODBC desde cualquier aplicación en GNU/Linux, como pueden ser programas Java, Perl, PHP, Ruby…

En principio, vamos a tirar de apt-get para instalar algunos programas:

apt-get install tdsodbc unixodbc libct3 libltdl3 odbcinst1debian1

Lo siguiente es crear el fichero /etc/odbcinst.ini, que debe de contener lo siguiente:

[FreeTDS]
Description     = TDS driver (Sybase/MS SQL)
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsS.so
CPTimeout       =
CPReuse         =

Ahora, para cada base de datos a la que queramos conectarnos, habrá que agregar un bloque de este tipo en el fichero /etc/odbc.ini:

[contactos]
Driver      = FreeTDS
Server      = 192.168.1.5
Database    = contactos
TDS_Version = 8.0
Port        = 1433

El nombre de la conexión es el que se situa entre los corchetes, y el que se usará para referenciar a esa conexión.

Para comprobar, podemos ejecutar el comando isql con los siguientes parámetros:

isql contactos usuario clave

Con esto, desde interfaces como DBI (Perl y Ruby), podemos usar DSN del tipo DBI:ODBC:contactos para acceder a esta conexión, siempre pensando que el usuario y la clave debe de insertarse en el comando de conexión.

Entradas relacionadas:

1. ¡Debian Lenny 5.0 ya es estable!

Entradas relacionadas:

1. Redes en Linux
2. Erlang y Asterisk… ErlAst
3. PostgreSQL: configuración de acceso

Los paquetes de GNU/Linux tienen que cumplir la especificación de ordenación de ficheros que establece la distribución en concreto donde se va a instalar la aplicación, así pues, nos encontramos a este respecto con dos grandes variantes: RPM y DEB.

Los RPM, obra de RedHat, son paquetes que se guardan comprimidos y contienen una serie de scripts para la instalación, actualización, eliminación y otras actividades similares. Además de esto, los paquetes contienen información de dependencia, es decir, que antes de instalarse en el sistema, deben de estar instalados otros paquetes para que el binario que contiene el paquete funcione correctamente. Es su garantía de funcionalidad y lo que lo diferencia de los paquetes binarios que se generan para Windows.

Los DEB son paquetes obra de Debian, que tienen las mismas características que los RPM, pero agregando algunas características más como sugerencias y recomendaciones. Las sugerencias son paquetes similares o que pueden trabajar en conjunto con el que se va a instalar. Las recomendaciones son paquetes que añaden funcionalidades al paquete que se está instalando, como por ejemplo la internacionalización, algún plugin, o algo por el estilo.

El uso de los paquetes RPM se lleva a cabo por el programa rpm, el cual es instalable en cualquier distribución (incluso Debian) y permite manipular los paquetes de tipo RPM para su instalación, listado e incluso creación. En los paquetes DEB tenemos dpkg, el cual se usa de forma idéntica a rpm (en concepto).

La facilidad de estos paquetes no es en sí la encapsulación, puesto que agregan muy pocas características en comparación con los famosos InstallShield de Windows y otros similares. La gran ventaja de estos sistemas son los repositorios. Un repositorio es un sitio accesible por HTTP, FTP o similar que permite la descarga de un paquete RPM y/o DEB para su instalación en el sistema.

Cada distribución ha ido creando su herramienta específica y podemos ver, entre otras, para RPM en Fedora yum, en SuSE es yast, en Mandriva es urpmi e incluso en todas las distribuciones basadas en RPM, se puede usar apt; para DEB tan solo tenemos apt. No obstante, hay otras distribuciones como Slackware y Gentoo, que no usan paquetes ni RPM ni DEB, los cuales también tienen herramientas para descarga de sus paquetes específicos desde Internet.

La configuración de APT la podemos ver en detalle en el siguiente enlace.

La configuración de YUM la podemos ver en detalle en el siguiente enlace.

La configuración de URPMI la podemos ver en el siguiente enlace.

Entradas relacionadas:

1. Programación para Administradores de Sistemas
2. Debootstrap: probar sin ensuciar