El Usuario Root y el Control de Privilegios en Linux: Sudo, Su y PolicyKit

Muy buenas lector. Retomando un poco el artículo sobre el funcionamiento de la arquitectura de permisos en Linux, hoy quiero hacer una tercera parte para profundizar un poco más sobre el usuario root, y la gestión de los privilegios de superusuario.

En este post, pues, te contaré más sobre el usuario root, sobre las herramientas de control y de privilegios, principalmente sudo, su y PolicyKit, y sobre los distintos enfoques que duelen adoptar las diferentes distribuciones entorno a la gestión y elevación de privilegios.

Tabla de contenidos:

1. El usuario Root o Superusuario
2. Las herramientas de control de privilegios
   1. Sudo
   2. Su
   3. PolicyKit
3. Como gestionan Root las diferentes distribuciones
   1. Root deshabilitado. Uso de Sudo y Policykit
   2. Root habilitado. Uso de Su y Policykit
4. Despedida y Cierre

El Usuario Root o Superusuario

Como cuento en el post anterior que acabo de enlazar, el usuario root en Linux es el usuario que posee mayor nivel de privilegios. De hecho, es el único que tiene privilegios sobre todo el sistema en su globalidad, así como el responsable de las tareas administrativas.

De este modo, cuando tu, o cualquier programa, quiera llevar a cabo una acción que requiera permisos de superusuario, de alguna manera se les tendrá que conceder o denegar estos privilegios.

Y aquí es donde viene lo interesante, ya que no todas las distribuciones hacen el mismo uso de la cuenta de superusuario, como verás un poco más adelante. Antes, por eso, si me permites un pequeño paréntesis introductorio, creo que es importante que conozcas las principales herramientas de control de privilegios que entran en juego en esta ecuación.

Mecanismos de Control de Privilegios: Sudo, Su y PolicyKit

Cualquier plataforma o sistema operativo que se precie, llámese GNU/Linux, Windows o macOS, funciona separando muy claramente los privilegios entre distintos usuarios.

Así, existe generalmente un usuario administrador o superusuario, que es el que posee el nivel más elevado de privilegios (el Administrador de Windows, y root en Linux y macOS), y el resto de usuarios, con un nivel de permisos mucho más restringido.

A partir de ahí, para evitar tener que iniciar sesión con un usuario u otro, dependiendo de si queremos administrar el sistema o no (eso es lo que teníamos que hacer en Windows XP, por ejemplo), existen los mecanismos o herramientas de control de privilegios. El objetivo es facilitar toda esa gestión de elevación o adquisición de permisos.

Windows, por ejemplo, hace uso de su famoso Control de Cuentas de Usuario o UAC. Sobre el, te cuento en detalle como funciona en este post, y como puedes configurarlo, en este otro post.

Para elevar privilegios en Linux también podemos hacer uso de mecanismos similares. En este caso, las herramientas más utilizadas son sudo, su, y PolicyKit, que funcionan de manera parecida, pero tienen sus propias particularidades. Mientras sudo lo que te pide son las credenciales del usuario actual, su requiere que le des, en su configuración estándar, las credenciales de la cuenta de root.

Sudo

Sudo es, en su esencia, una programa que permite al usuario actual, ejecutar aplicaciones o procesos bajo los privilegios de otro usuario distinto (el que sea).

Esta es, digamos, la definición más formal. A partir de ahí, el uso más general que se le suele dar es el de la elevación de privilegios (permitir ejecutar procesos bajo los permisos de root). De hecho, esta es la idea inicial con la que nace. Su nombre viene justamente de «supersuer do».

Esta configuración, la de ejecutar aplicaciones o procesos bajo los privilegios de superusuario, es en la que se basan muchas distribuciones que optan por deshabilitar el uso de root por parte de los usuarios regulares.

Sudo es una herramienta que se usa específicamente desde la línea de comandos. Se utiliza acompañada de comandos que requieran permisos elevados.

Su uso consiste únicamente en ser introducido delante del comando en cuestión, para indicar que ese comando se va a ejecutar bajo los permisos de otra cuenta (por defecto, sino de indica ninguna, se entenderá que es la de root).

sudo <comando>

Solo hay que utilizar sudo acompañado de aquellos comandos que requieran elevación. De lo contrario, estaremos ejecutando un comando normal con un nivel de privilegios de root sin realmente necesitarlo, con el riesgo que ello conlleva.

When you run sudo with a normal command 😀🐧#linux #linuxmeme pic.twitter.com/7KLTUOUXza

— It's FOSS – Linux Blog (@itsfoss2) January 18, 2019

Aunque es una herramienta de la terminal, también tiene contrapartidas gráficas, Gksudo y Kdesudo. Lo que hacen estas es emular el mismo comportamiento, pero en la sesión gráfica.

De este modo, cuando se intentan realizar acciones que requieren elevación (por ejemplo, instalar una aplicación desde la tienda de software) se encargan de desplegar un promp, para que el usuario se acredite como tal.

Aún así, dentro de la sesión gráfica la tendencia actual es a utilizar PolicyKit, en substitución de Gksudo o Kdesudo.

Su

Su es una herramienta similar a sudo, que permite hacer un salto de usuario, para ejecutar acciones a nombre de este otro usuario. De hecho, su nombre viene de «switch user» o «substitute user».

Así, mientras que sudo permite ejecutar procesos con los privilegios de otro usuario (pero sin hacer un cambio de usuario), su si que realiza un salto de usuario.

De hecho, si lo utilizas, verás que mientras que sudo requiere únicamente las credenciales del propio usuario con el que estás logueado (tu usuario estándar), para utilizar su debes conocer las credenciales del nuevo usuario al que quieres apuntar.

Como sudo, es una herramientas para utilizarse mediante la línea de comandos. Se utiliza, seguido del nombre de usuario a nombre del que se quiere actuar (por omisión, root). En caso de saltar a root, el cambio de forma del promp es un claro indicativo para identificarlo.

$ su
#

Es muy común utilizarlo en aquellas distribuciones que prefieren mantener abierta la cuenta de root para que cualquier usuario que conozca las credenciales de superusuario (entendiéndose que conozca la contraseña) pueda hacer un salto de sesión y ejecutar comandos desde ahí.

Asimismo, al igual que ocurre con sudo, también tiene sus contrapartidas gráficas, Gksu y Kdesu, que emulan el mismo comportamiento.

Policykit

https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html

En breve…

Como Gestionan Root los Diferentes Distribuciones

Como he empezado diciendo al principio, no todas las distribuciones optan por la misma concepción a la hora de operar con la cuenta de superusuario. Estás son las dos concepciones que se suelen dar:

Root Deshabilitado. Uso de Sudo y/o PolicyKit

Hay muchas distribuciones (Ubuntu o Linux Mint entre otras) que optan, directamente, por venir, por defecto, con el la cuenta de Root deshabilitada. Realmente, lo que significa eso es que se impiden que tu, o cualquier otro usuario, puedan iniciar una sesión con él, ni desde la sesión gráfica, ni desde la terminal.

En estos casos, las tareas administrativas se hacen desde el propio usuario estándar, a través de sudo (o su contrapartida gráfica), y PolicyKit.

Cuando esto es así, generalmente sudo está configurado de tal modo que el usuario estándar que has creado durante la instalación del sistema, pueda hacer uso de los privilegios de Root, acreditándose previamente.

1. Uso permanente como usuario estándar. El sistema funciona permanentemente bajo la cuenta de tu usuario estándar, y por tanto, todos las aplicaciones y procesos asociados se ejecutan con un nivel de privilegio reducido.

2. Acreditación para tarea que requiere privilegios. En este punto, cuándo el usuario requiere realizar una tarea administrativa, si es mediante la sesión gráfica, el sistema le pedirá sus credenciales (probablemente a través de Policykit, antiguamente con Gksudo). Si es desde la terminal, deberá realizar la acción a través de sudo, e introduciendo nuevamente sus credenciales.

3. Ejecución de la tarea. Si en el archivo sudoers el usuario actual está acreditado (si hay un único usuario y root está deshabilitado, por defecto debería ser así), se ejecutará la acción con los permisos de root. En la captura se ve claramente el proceso asociado ejecutándose como root.

4. Finaliza la acción. Al finalizar la acción, se sigue estando, por lo tanto, en la misma sesión de usuario estándar. La elevación solo se ha dado en el proceso implicado, durante su ejecución. Cualquier otra acción que requiera privilegios de superusuario, requerirá de nuevo el uso de sudo.

Las ventajas de esta concepción son varias, pero principalmente, las más destacables podríamos decir que son estas:

• Por un lado, te evitas tener que memorizar dos contraseñas (la tuya y la de root). La tuya te sirve tanto para entrar, como para realizar ciertas tareas administrativas, mediante sudo.
• Todas las aplicaciones y procesos a nivel de usuario, funcionan con un nivel de privilegios reducido. Al invocar una acción a través de sudo, únicamente se elevará el proceso asociado, y de forma temporal.

En esta guía de la wiki de Ubuntu se explican todas las ventajas de adoptar esta concepción, y utilizar sudo como método de elevación para acciones que requieres privilegios.

Root Habilitado. Uso de Su y/o PolicyKit

Hay otras distribuciones, como Debian, Fedora u openSUSE, que en el proceso de instalación te permiten asignar una contraseña a root, para que puedas hacer uso de él.

Cuando esto es así, delante de una acción que requiera permisos de superusuario, el sistema requerirá las credenciales de éste ultimo, para que pueda llevarse a cabo.

1. Uso permanente como usuario estándar (recomendable). Si estás en la sesión de usuario normal, el sistema funciona permanentemente bajo la cuenta de tu usuario estándar, y por tanto, todos las aplicaciones y procesos asociados se ejecutan con un nivel de privilegio reducido.

2. Acreditación para tarea que requiere privilegios. En este punto, cuándo el usuario requiere realizar una tarea administrativa, si es mediante la sesión gráfica, el sistema le pedirá las credenciales de root. Si es desde la terminal, deberá realizar la acción a través de su, e introduciendo nuevamente sus credenciales.

3. Ejecución de la tarea. Si la contraseña es correcta, se lleva a cabo la tarea. Mediante sesión gráfica, PolicyKit permitirá la ejecución de los procesos como Root, solo temporalmente hasta finalizar la ejecución de la acción requerida.

4. Finaliza tarea. Al finalizar la tarea, al haberla hecho mediante su, sigues teniendo una sesión abierta con posibilidad de realizar acciones como root. Por lo tanto, se requiere cerrar la sesión con un exit.

Dicho esto, hay que tener en cuenta una serie de consideraciones relativas a este modo de operar:

• Queda totalmente desaconsejado iniciar sesión con Root. Esto supondría que todos las aplicaciones y procesos de usuario estarían corriendo con el máximo nivel de privilegio, exponiendo gravemente el sistema ante cualquier bug que pueda haber en una aplicación. Esto por no hablar del daño que podría hacer cualquier virus o malware ejecutándose con permisos de administrador.
• Para realizar tareas administrativas desde la sesión de usuario estándar, en sesión gráfica el sistema ya se encargara de pedir las credenciales. En la terminal de puede hacer uso de su.

En el Próximo Post

Y con esto llegamos al final de este post. Espero que esta explicación te haya ayudado a conocer mejor el usuario root y a comprender mejor el funcionamiento de los diferentes sistemas de control de privilegios.

En esta primera parte era básicamente de divulgación. Si tienes ganas de trastear con el sistema, en esta segunda parte que te enlazo verás como habilitar o deshabilitar el uso de root, además de revisar la configuración de sudo, por experimentar tu mismo con las diferentes concepciones que has visto.

Si te ha gustado el post, siéntete libre de compartirlo por Twitter o Facebook. Y si tienes cualquier duda, tienes la sección de comments debajo. Hasta la próxima!