Linux Sin Humo (Publicaciones sobre explanations)

Plan Táctico y Estratégico de la Memoria en Linux

sebelk — Mon, 01 Dec 2025 05:00:32 GMT

La mitología en torno a la memoria en Linux ha producido una serie de relatos:

En un extremo: Linux puede funcionar con muy poca memoria RAM.
Del otro lado: Linux consume mucha memoria.
Y que una partición SWAP debe tener entre 1 a 2 veces la memoria RAM.

Como vemos algunas historias son más recientes, otros más antiguas, pueden ser parcialmente ciertas y hasta contradictorias entre sí.

Este artículo tiene como propósitos:

Explicar de manera sencilla el funcionamiento de la memoria en Linux, desmitificando también algunos conceptos.
Enumerar y describir tácticas para que el uso de la memoria proporcione la mejor usabilidad y experiencia del usuario.
Ofrecer alternativas para que cada uno elija la mejor opción de acuerdo a sus necesidades.

Definiciones

Vamos a repasar algunos conceptos básicos que de manera más o menos frecuente usamos, usaremos metáforas en el camino. Ninguna metáfora es perfecta, sin embargo ellas nos ayudan a entender la realidad.

Memoria Virtual

La memoria virtual es el mecanismo por el cual cada proceso recibe un espacio de direcciones propio, independiente y protegido. El hardware traduce direcciones virtuales a físicas según tablas de páginas. Esto permite aislamiento, sobreasignación, mapeos de archivos y demanda dinámica de páginas, más allá de la cantidad de RAM disponible.

Linux trata de usar la mayor cantidad de memoria posible, para poder ejecutar las aplicaciones y acceder a los archivos de la manera más rápida posible. De manera que si la memoria libre es baja no es necesariamente un indicativo de un problema.

Page

Una página es la unidad mínima de memoria, de tamaño fijo (típicamente 4 KB), que el kernel y el hardware de gestión de memoria del procesador utilizan para organizar el espacio de direcciones y realizar el mapeo entre direcciones virtuales y físicas.

Page table

Es una estructura de datos jerárquica administrada por el kernel y usada por el hardware para traducir direcciones virtuales a direcciones físicas, con información de permisos y estado de cada página.

Page Fault

Un page fault ocurre cuando un proceso accede a una dirección válida de su espacio de memoria pero la página correspondiente no está preparada para ese acceso. Puede deberse a que la página aún no fue cargada, a que debe asignarse, o a que debe traerse desde disco. Si la página no está en RAM, el kernel debe cargarla, lo que puede ser lento; si ya estaba en RAM, el costo es menor.

Page cache

Es la caché de páginas de archivos gestionada por el kernel, usada para acelerar lecturas y escrituras almacenando en RAM los datos y metadatos de archivos y directorios, reduciendo accesos al disco.

Tipos de memoria

File Memory

Es la memoria relacionada con el Page Cache.

Anonymous Memory

Es la memoria que un proceso usa y que no está respaldada por un archivo: heap (asignada dinámicamente), stack (llamadas a funciones y almacenamiento de variables locales), COW (parte de la memoria cuando se crea un proceso hijo) y mapeos con MAP_ANONYMOUS. Su único respaldo posible es la swap. La memoria anónima se crea y utiliza en RAM. Si el kernel necesita expulsarla de RAM, su único destino posible es la swap, porque no tiene un archivo desde el cual reconstruirse. Pero su existencia normal no depende de la swap.

Memory Pressure

Memory pressure es estado en el que las páginas libres caen por debajo de umbrales críticos, obligando al kernel a iniciar mecanismos de liberación de memoria.

En términos prácticos cuando la presión es alta pueden surgir ciertos síntomas:

Sitios web / servidores HTTP: La latencia aumenta porque los workers deben esperar a que el kernel libere páginas. Además, puede haber más CPU gastada en recuperar memoria, lo que degrada aún más los tiempos de respuesta.
Sistemas de escritorio: El sistema pierde fluidez porque el scheduler empieza a verse afectado por stalls debidos a las operaciones para liberar memoria y, si hay swap, el sistema puede entrar en swap thrashing. Esto produce lag del mouse, ventanas que tardan en responder, escritorios congelados por segundos, etc.
Acceso remoto (SSH, RDP, VNC): Al haber presión, las operaciones de usuario-espacio tardan más en ejecutarse, y los daemons pueden quedar brevemente estancados esperando memoria. Esto causa retrasos notables en la interacción remota.

¿Y qué sucede si la presión de memoria puede llegar a ser tan alta que el kernel ya no logra conseguir memoria ni siquiera después de intentar liberarla?

Thrashing

El thrashing ocurre cuando la memoria RAM no alcanza para mantener las páginas que los procesos usan todo el tiempo. El kernel empieza a sacar páginas de memoria para hacer lugar a otras nuevas, pero enseguida vuelve a necesitarlas. Esto genera un bucle de fallos de página y de recarga constante desde el disco.

Con swap: las páginas anónimas van y vienen entre RAM y swap, lo que dispara el uso de disco y vuelve el sistema extremadamente lento.
Sin swap: las páginas anónimas no tienen adónde ir y el kernel termina activando el OOM killer.
Incluso sin swap: puede haber thrashing si las páginas vienen de archivos (page cache), ya que el kernel debe recargarlas una y otra vez.

OOM (Out-Of-Memory) 💀 🔥

Out-Of-Memory es una situación en la cual el kernel agotó todos los mecanismos para liberar memoria:

Liberar páginas del caché.
Sacar páginas anónimas de swap.
Compactar memoria.
Liberar memoria mediante kswapd.
Aplicación de políticas de cgroups (muy común al usar contenedores).

OOMKiller

El OOM-killer es el mecanismo que usa el kernel cuando ya no puede asignar más memoria, incluso después de intentar liberar todas las páginas que es posible descartar o mover fuera de la RAM. En esa situación crítica, el kernel calcula un puntaje para cada proceso (oom_score) y finaliza al que resulte más conveniente para recuperar memoria rápidamente y permitir que el sistema siga funcionando. Este comportamiento puede influenciarse ajustando oom_score_adj, que hace que un proceso sea más o menos propenso a ser elegido.

oom_score

Como ya se mencionó a cada proceso se le asigna un puntaje de acuerdo a distintos factores, cuanto más alto es, más susceptible es a ser terminado por OOMKiller.

Y también, como dijimos mediante oom_score_adj podemos influir en el score de un proceso:

En versiones más recientes de las distribuciones existe el comando choom que permite ver y/o ajustar dicho valor.

Swap

Los usuarios ocasionales de Linux y aun muchos sysadmins tienen una idea negativa sobre "la swap". Simplificaciones extremas y conceptos anticuados la han convertido en le gran villana de la historia del sistema operativo.

Si comparamos a la memoria con un escritorio, sin swap podría lucir así:

Photo by Ashim D’Silva on Unsplash

Así que primero vamos a decir lo que no es:

No es la memoria virtual sino que forma parte de la técnica que realiza el sistema operativo para administrar la memoria.
No es un espacio de reserva ni un último recurso. Es un espacio complementario sirve para liberar RAM.
No funciona como último recurso, pero el sistema operativo puede mover hacia la swap las páginas de memoria no usadas recientemente.
No es algo que el sistema operativo pueda alegremente prescindir aun cuando la cantidad de memoria RAM física sea grande. Quienes parecen haber inventado la pólvora, nos cuentan que es posible técnicamente que Linux funcione sin swap. Si bien es cierto, al carecer de swap, el kernel no tiene manera de mover páginas de memoria anónimas hacia el área de swap y liberar así RAM para procesos que la necesitan urgentemente.

Nuestro escritorio con swap:

Photo by Alexandru Acea (edited by me) on Unsplash

¿Los cajones de un escritorio los usamos cuando lo tenemos abarrotado de cosas? No, los usamos para guardar cosas que no son de alta prioridad. Aunque es cierto, si luego queremos usar esa tijera o aquel destornillador en algún momento requerirá un poco más de trabajo, tendremos que abrir el cajón, buscarlo, extraerlo, etc.

Ah, y la swap también sirve para hibernar, aunque honestamente no se cuanta gente mantiene esa práctica.

Tuning

Ahora veremos diferentes tácticas que podemos usar para optimizar el uso de la memoria.

cgroupv2

cgroup es un mecanismo para organizar los procesos de manera jerárquica y distribuir los recursos del sistema a lo largo de la jerarquía en una manera controlada y configurada.

Un cgroup se compone de un núcleo que es responsable primariamente en organizar de manera jerárquica los procesos y controladores que comúnmente distribuyen un tipo específico de recurso del sistema a lo largo de la jerarquía.

En la versión 2 de cgroup un proceso no puede pertenecer a diferentes grupos para diferentes controladores. Si el proceso se uno al grupo alfa, todos los controladores para alfa tomarán control de ese proceso.

Supongamos que los procesos de un cgroup (y todos los grupos hijos) usan poca memoria, podríamos decirle al kernel que libere memoria de otros cgroups. Esto es precisamente lo que hace el parámetro memory.low.

Otro parámetro interesante para monitorear es memory.pressure, la primera línea tiene el tiempo físico de una o más tareas demoradas debido a la falta de memoria. La segunda sería lo mismo pero para todas las tareas del grupo, full es lo mismo pero para todas las tareas del grupo, Entonces si miramos el archivo /sys/fs/cgroup/user.slice/memory.pressure:

some avg10=0.00 avg60=0.13 avg300=0.12 total=1690238
full avg10=0.00 avg60=0.10 avg300=0.09 total=1394199

Significa que, dentro del grupo de control user.slice, en los últimos 10 segundos no hubo tareas afectadas por presión de memoria. Sin embargo, en el último minuto las tareas estuvieron bloqueadas un 0,13% del tiempo y un 0,12% en los últimos cinco minutos. El valor total indica que estas situaciones acumulan aproximadamente 1,7 segundos de espera. La segunda línea muestra las mismas métricas, pero aplicadas a los casos en que todas las tareas del grupo estuvieron simultáneamente afectadas por presión de memoria (full en lugar de some).

Es decir:

some → indica si un retraso afectó al menos una tarea.
full → indica si el retraso afectó a todo el cgroup simultáneamente.

zram

zram es por así decirlo, una manera cool de usar swap gracias a un módulo del kernel.

Photo by chuttersnap on Unsplash

En lugar de gastar espacio en un disco (sea rígido o sólido) usamos dispositivos de bloque en la propia RAM. Los bloques swapeados se guardan comprimidos. Esto discos virtuales son rápidos y ahorran memoria.

Una de las pocas desventajas que tiene esta metodología es la incapacidad para poder hibernar el sistema operativo, al no estar presente la partición en un almacenamiento de tipo persistente.

Sistemas de archivos

El journal de ext4 puede ser lento, xfs puede ser una mejor alternativa o mejor aun btrfs.

EarlyOOM

El oom-killer del kernel solamente se dispara en situaciones extremas y le puede llevar mucho tiempo hasta que puede enviar SIGKILL a los procesos que sean necesarios para poder liberar memoria. Durante ese tiempo probablemente el usuario no pueda interactuar con el sistema operativo.

EarlyOOM trabaja en espacio de usuario y por lo tanto se puede anticipar y ser mucho más rápido.

El comportamiento predeterminado en Fedora es que si hay menos del 10% de RAM y/o SWAP libre, earlyoom envía una señal de terminación a todos los procesos con oom_score más alto. Si la RAM como SWAP libre bajan por debajo del 5%, earlyroom enviará una señal para matar todos los procesos con oom_score más elevado.

La idea es recuperar la usabilidad (especialmente en un entorno de escritorio) lo antes posible.

El problema es que EarlyOOM no soporta al momento la medición de la memory pressure como indicativo para tomar decisiones.

nohang

Este servicio es mucho más configurable y aporta una mejor solución que EarlyOOM.

Algunas funcionalidades son:

Se puede elegir la acción que realizará en una situación OOM.
Ofrece varios criterios para elegir los procesos a finalizar.
Soporta zram
Puede usar memory pressure para tomar una acción.
El archivo de configuración es medianamente sencillo

Sin embargo, este proyecto en la actualidad tiene poca actividad comparado por ejemplo con EarlyOOM

zswap

Con zswap no reemplazamos el espacio swap en el disco sino que usamos un caché comprimido en la RAM. Este método ahorra I/O, obteniendo entonces mejor rendimiento y alargando la vida útil de discos flash o sólidos. La única desventaja es usar algo de tiempo del procesador para realizar la compresión.

Photo by Pineapple Supply Co. on Unsplash

Mediante el caché se logra una diferenciación entre páginas más usadas (zswap) y menos usadas (swap).

systemd-oomd

El servicio systemd-oomd es un proyecto en el que comenzó en Facebook para integrarlo con systemd. En un principio estaba pensado para manejo de memoria a gran escala, y bastante más complejo de configurar. Sin embargo ha sido adoptado desde Fedora 34 reemplazando a EarlyOOM. En las distribuciones que usan versiones recientes de systemd, está disponible, aunque no todas lo habilitan de manera predeterminada.

Resumen

Swap no es la villana de la película
Si existe la opción de migrar a otros sistema de archivos aunque con características un tanto experimental, elegir btrfs. Una opción más moderada es xfs.
El tuning de cgroupv2 puede traer grandes beneficios, no obstante existen proyectos y distribuciones que no lo usan.
EarlyOOM es una solución rápida y aplicable a una amplia gama de sistemas Linux, aunque no siempre es la más exacta ni más elegante.
El servicio nohang (o no hang-desktop) es una opción más madura aunque algo más compleja que EarlyOOM, pero que sin embargo ha caído en cierta inactividad.
El servicio systemd-oomd inicialmente incorporado por Facebook es seguramente la opción más adecuada para escenarios más complejos y de manejo de memoria a gran escala. También es utilizado actualmente en sistemas de escritorio.
Sin embargo, muchas distribuciones o sabores de distribuciones prefieren usar el mecanismo clásico de OOMKiller.
A veces se sugiere el ajuste de parámetros del kernel mediante sysctl.
Si se desea ahorrar espacio en disco se puede reemplazar la swap por zram, sacrificando la opción de hibernar el sistema.
La opción zswap es más sofisticada, aunque dependemos del uso de swap en disco.

Photo by sk on Unsplash

Fuentes consultadas

Comparación de systemd-run con nuhup, tmux y screen

sebelk — Tue, 24 Jun 2025 22:07:30 GMT

Si estamos conectados por ssh y sufrimos una desconexión mientras ejecutamos un comandos, puede representar un problema, desde la interrupción del proceso o la pérdida del acceso a la salida estándar/error del mismo. Existen comandos como nohup que de alguna manera nos ayudan a mitigar esas situaciones, tales como nohup, o multiplexores de terminal como screen y tmux.

Al usar systemd, contamos con una herramienta tan sencilla como poderosa: el comando systemd-run que permite ejecutar un comando muy sencillo como el siguiente en un servicio. O para ser más exactos en una service unit:

systemd-run --user ping 8.8.8.8

Comparación con nohup, tmux/screen

Característica	`systemd-run`	`nohup`	`tmux` / `screen`
Supervisión del estado	Sí, vía `systemctl status` y `journalctl`	No, se debe usar `ps` o `pgrep`	Parcial, requiere inspección manual de la sesión
Control del ciclo de vida	Completo: iniciar, detener, reiniciar con políticas de reinicio	Nulo: solo iniciar, sin reinicio automático	Manual: requiere interacción del usuario
Manejo de logs	Centralizado en journal, con metadata y timestamps	Básico: redirige a `nohup.out` sin rotación	Opcional: solo si se configura logging explícitamente
Integración con el sistema	Alta: como unidad de systemd, con cgroup, slices, y logs centralizados	Nula: proceso genérico del usuario	Baja: proceso de usuario sin integración con systemd
Persistencia tras logout	Alta: configurable vía `lingering` o como unidad del sistema	Limitada: depende de configuración de `logind`	Alta (tradicional), pero afectada por `KillUserProcesses`
Persistencia tras reinicio	Posible mediante conversión a unidad persistente o uso de `systemd-timer`	No, se requiere cron, scripts externos	No, sesión se pierde tras reboot
Políticas de recursos/aislamiento	Completa: límites CPU, memoria, I/O, namespaces, privilegios, etc.	Nula: se requiere uso externo de `ulimit` o `nice`	Nula: requiere herramientas externas
Facilidad de uso interactivo	Baja: orientado a ejecución no interactiva	Nula: no interactivo	Alta: diseñado para interacción, múltiples ventanas/sesiones
Ideal para	Tareas ad-hoc, servicios temporales, pruebas controladas	Procesos simples que deben continuar tras logout	Tareas interactivas largas o sesiones remotas persistentes

Más Ejemplos

Ansible

Advertencia: Los siguiente comandos no son para copiar y pegar sin analizarlos, deben ser ajustados al entorno en los cuales se los desea utiizar. El propósito principal es mostrar la potencia práctica de la herramienta systemd-run.

Objetivo: Ejecutar playbooks críticos en entornos controlados, como servicios temporales autoreiniciables.

systemd-run -p Restart=on-failure -p PrivateTmp=yes -p Description="Provisionar servidores" \
  -p SuccessExitStatus=0 \ 
  -p RestartSec=5 \ 
  -p TimeoutStopSec=30   \ 
  --unit=ansible-run ansible-playbook site.yml -i inventory/prod

Ventajas:

Crea un entorno temporal (/tmp aislado).
Si falla, se reinicia automáticamente.
El log de toda la ejecución queda en journal.

mysqldump

Objetivo: Realizar dumps de bases de datos con límites de memoria y sin cargar el sistema.

systemd-run \
  -p MemoryMax=750M \
  -p MemorySwapMax=150M \
  -p Nice=10 \
  -p Description="Backup de MySQL sin afectar el sistema" \
  --unit=mysql-dump \
  bash -c 'mysqldump --all-databases > /tmp/backup.sql'

Ventajas:

Protege al sistema de un uso excesivo de memoria
Baja prioridad de batch (Nice=10).
Log y control vía systemd.

Azure CLI

Objetivo: Apagar/desasignar todas las VMs del grupo "GrupoDesarrollo" en segundo plano

systemd-run --unit=apagar_vms \
    --service-type=oneshot \
    -p WorkingDirectory=/tmp \
    bash -c 'az login --identity && az vm list -g GrupoDesarrollo --query "[].id" -o tsv | xargs -r az vm deallocate --ids'

Ventajas:

Ejecución desacoplada de la terminal.
Se puede usar journalctl para auditar el comando.
Control sobre el entorno de ejecución

Conclusión

El comando systemd-run es una alternativa más robusta que otros comandos legacy o multiplexores de terminal, ya que permite, no solamente desacoplar el proceso de la terminal sino también poder gestionarlo perfectamente dentro de systend.

Fuentes y más recursos

Manpage de systemd-run
Documentación oficial de systemd-run, incluyendo parámetros como --unit, --service-type, y ejemplos útiles.
Manpage de systemd.service
Referencia esencial sobre unidades de servicio, incluyendo tipos (oneshot, simple) y propiedades como Restart=, WorkingDirectory=, etc.
Autenticación con identidad administrada en Azure CLI
Cómo usar az login --identity de forma segura, sin almacenar credenciales.
Respuesta que recomienda systemd-run cuando nohup falla
Explica por qué procesos protegidos con nohup pueden morir y propone systemd-run --scope --user como solución más fiable.
Explicación de tipos de unidades systemd (Fedora Project)
Introducción accesible al funcionamiento de systemd.

Frameworks para Bash: ¿realmente los necesitamos? Una mirada profunda a bash-it

sebelk — Wed, 02 Apr 2025 18:07:44 GMT

Después de muchos años 📅de usar bash es normal ir acumulando alias, funciones, variables, scripts, qué ponemos por aquí y por allá, con suerte en algún directorio más o menos estandar. Pero llega un momento que es difícil de manejar todo eso. De acuerdo a mi experiencia he notado que muchas veces se usa algo porque se sacó de un foro de reddit, stackoverflow, de una búsqueda en google o DuckDuckGo, de una respuesta de a un prompt en la IA... o porque alguien lo dijo. Funciona, pero no se tiene ni idea de por qué funciona.

Una vez en un curso un alumno me dijo:

- ¡Ahora entiendo porque hago lo que hago cada día en mi trabajo! 😀

Es imposible saber y acordarse de todo, pero tener una idea conceptual al menos general de como funcionan las cosas nos ayuda en el trabajo diario.

Por eso es importante tener en cuenta algunos conceptos de bash fundamentales.

Alias

Los alias se usan para abreviar o cambiar el comportamiento de comandos simples o repetitivos.

Por ejemplo:

alias rm ='rm -i'

De este modo, estamos cambiando el comportamiento del comando rm para que nos pregunte antes de borrar archivos. Hay otras situaciones en los cuales queremos hacer un comando mucho más sencillo:

alias dma='date +%d-%m-%y'

Funciones

Si bien los alias son muy útiles, tienen limitaciones:

❌ No se expanden de manera predeterminada en scripts.
❌ No soportan parámetros posicionales.
❌ Tienen un soporte muy estrecho para lógica condicional.

Si tenemos alguno de esos requerimientos entonces usaremos funciones, como la siguiente que sirve para ver un archivo sin líneas vacías o con "#":

clrfile () 
{ 
    if [[ $# -eq 0 ]]; then
        echo "Error: Proporciona al menos un archivo." 1>&2;
        return 1;
    fi;
    local file;
    for file in "$@";
    do
        if [[ ! -f "$file" ]]; then
            echo "Error: '$file' no es un archivo válido." 1>&2;
            continue;
        fi;
        grep -Ev '^[[:space:]]*#|^$|^[[:space:]]*;' "$file";
    done
}

Variables

A medida que vamos usando bash, encontramos la necesidad de crear variables, por ejemplo:

HISTFILESIZE=1048576
export nikola="/home/sergio/Documentos/Arts/nikola-env"
export GTK_USE_PORTAL=1

Opciones de bash

Bash posee muchas opciones que nos sirven para modificar el comportamiento del shell como vemos a continuación:

shopt -s histappend
shopt -s autocd
shopt -s dirspell
shopt -s cdspell
shopt -s cdable_vars

Con el paso del tiempo, nuestro archivo .bashrc, puede hacerse muy largo, poco claro, poco modular, o hasta incluso creamos muchos archivitos aquí y allá con funciones y/o alias como si fueran scripts. Con suerte tal vez los pongamos en ~/bin o ~ /.local/bin. Cuando llegamos a este punto tal vez estemos necesitando que nuestras herramientas estén organizadas, que manejen estándares, que podamos contar con módulos que se puedan habilitar o deshabilitar para poder administrar y/o desarrollar de manera más profesional. Es decir, necesitamos un framework.

bash-it, un framework como aliado

El shell zsh usa un framework llanado "Oh My Zsh". Sin embargo, las distribuciones principales, a excepción de Kali, el resto usa bash de manera predeterminada. Así que en muchos casos no tiene sentido invertir tiempo en cambiarse a zsh 😄. Y en particular para los que quieran aprender Linux, recomiendo que comiencen con Bash, luego si tienen tiempo y el ámbito corporativo se los permite podrán explorar Zsh como una excelente alternativa.

Por lo tanto, ¿qué tenemos para bash? En un principio encontré que justamente existe: Oh My Bash. Este proyecto usa el popular pero no por eso recomendado método de instalación desde el punto de vista de la seguridad que consiste en "curl-pipe-script". Sin embargo, ciertos problemas de Instalación manual con OMB, me llevaron a considerar a bash-it por tener mejores métricas:

Estas estadísticas hacen que más allá del bonito sitio que armó la comunidad de Oh My Bash eligiera bash-it:

✅ ¿Es técnicamente confiable Bash-it para producción?

No vamos a encontrar a bash-it en repositorios de las distribuciones principales, sin embargo desde un punto de vista técnico puro, Bash-it es bastante seguro porque:

✔️ No requiere privilegios especiales (se instala en el home del usuario).
✔️ Usa código abierto auditable (podés revisar cada plugin, alias, función).
✔️ Es fácil de activar/desactivar funcionalidades individuales (plugins, alias, temas).
✔️ Está diseñado para usarse solo en entornos interactivos, no impactando scripts automáticos.

Sin embargo, la confiabilidad depende mucho del criterio de quien lo administra.

🔐 ¿Consideraciones de seguridad para entorno corporativo?

⚠️ Es código abierto no revisado oficialmente por las distribuciones más populares, por lo cual debés auditar lo que habilitás.
⚠️ Debe implementarse con criterio, evitando plugins que hagan conexiones externas automáticas o definan alias potencialmente riesgosos.
⚠️ Es aconsejable versionar y usar un fork corporativo que controles.

🚨 ¿Riesgos o precauciones a considerar?

❌ Podrías introducir complejidad innecesaria si el equipo no está acostumbrado a Bash avanzado.
❌ Posibilidad de romper comandos estándar con alias mal elegidos.
❌ Necesidad de capacitación interna sobre su uso para evitar malentendidos.

💡 Recomendaciones profesionales (cómo hacerlo confiable):

📌 Usá un fork interno auditado por el equipo de seguridad o infraestructura.
📌 Instalá solo plugins y funcionalidades que realmente necesitás.
📌 No habilites funciones o plugins "experimentales" o desconocidos.
📌 Documentá claramente qué está habilitado y por qué.

Hechas las aclaraciones en las que me siento obligado a hacer, vayamos al procedimiento de instalación 😄.

Instalación de bash-it

Clonamos el repositorio y ejecutamos el script de instalación:

 git clone --depth=1 https://github.com/Bash-it/bash-it.git ~/.bash_it
 ~/.bash_it/install.sh

El script nos va a preguntar si queremos mantener el archivo ~/.bashrc o sobrescribir el archivo y crear un backup (comportamiento por default) o bien agregarlo al final de ~/.bashrc.

¿Dónde guardamos nuestras configuraciones?

Sea que necesitemos agregar nuestras propias configuraciones o rescatarlas del archivo de backup ~/.bashrc.bak es importante comprender donde tenemos que guardar cada cosa, para eso contamos la siguiente tabla:

Configuración	Ubicación
Alias	`~/.bash_it/aliases/custom.aliases.bash`
Funciones	`~/.bash_it/lib/custom.bash`
Opciones de shell	`~/.bash_it/lib/custom.bash`
Variables	`~/.bash_it/lib/custom.bash`
Autocompletados	`completion/custom.completion.bash`
Funciones agrupadas	`plugins/custom.plugins.bash`
Temas	`custom/themes/mi-tema/mi-tema.theme.bash`

¿Dónde colocar nuestros scripts?

Aquí, abro un paréntesis, ya que es importante que entendamos que si contamos con scripts más complejos, lo recomendable es que esté en algún directorio de nuestro path tal como ~/.local/bin. No sería conveniente sobrecargar el entorno, es decir, usarlo con bash-it. Si estamos en duda podemos responder algunas de estas preguntas, frente a un determinado script:

✔️ ¿Tienen su propio #!/bin/bash?

✔️ ¿Son ejecutables y no deben ser cargados en el entorno de bash?

✔️ ¿Pueden usarse desde cualquier shell?

✔️ ¿Podrían ser usados por otros scripts o tareas automatizadas?

✔️ ¿Dependen del contexto del entorno interactivo?

Si la respuesta para una o más a estas preguntas es afirmativa entonces lo mejor es excluirlos del framework bash-it.

Gestión de alias de bash-it

Podemos ver los alias habilitados con el comando siguiente:

bash-it help aliases

Ese comando nos va a mostrar en principio, los alias clasificados en dos categorías: general y custom. Si queremos ver los alias que tenemos disponibles, ejecutamos:

bash-it help aliases | less

Si queremos habilitar los alias para ansible

bash-it enable alias ansible
ansible enabled with priority 150.
cat .bash_it/enabled/150---ansible.aliases.bash 
# shellcheck shell=bash
about-alias 'ansible abbreviations'

alias ans=ansible
alias ap=ansible-playbook

En el ejemplo de arriba podemos inspeccionar los alias activados.

¿Cómo ver y activar plugins?

Las funciones son un grupo de funciones relacionados un tema.

bash-it show plugins | fgrep "[x]"
base                 [x]        miscellaneous tools

bash-it enable plugin fzf

⚠ A veces es necesario ejecutar bash-it restart para que aplique un cambio, por ejemplo la eliminación de un alias.

¿Cómo activar temas?

Bash-it cuenta con una gran cantidad de temas para darle un aspecto visual al shell

ls ~/.bash_it/themes/
90210            candy                        elixr                  liquidprompt  nwinkler                pure          slick
agnoster         clean                        emperor                luan          nwinkler_random_colors  purity        standard
atomic           codeword                     envy                   mairan        oh-my-posh              radek         tonka
axin             cooperkid                    essential              mbriggs       p4helpers.theme.bash    rainbowbrite  tonotdo
bakke            cupcake                      font                   metal         parrot                  ramses        tylenol
barbuk           demula                       gallifrey              minimal       pete                    rana          wanelo
base.theme.bash  dos                          githelpers.theme.bash  modern        powerline               redline       zitron
binaryanomaly    doubletime                   gitline                modern-t      powerline-multiline     rjorgenson    zork
bira             doubletime_multiline         hawaii50               modern-time   powerline-naked         robbyrussell
bobby            doubletime_multiline_pyonly  inretio                morris        powerline-plain         roderik
bobby-python     dulcie                       iterate                n0qorg        powerturk               sexy
brainy           duru                         kitsune                newin         primer                  simple
brunton          easy                         lambda                 norbu         pro                     sirup

Para cambiar un tema hay que editar una variable y reiniciar bash-it. Buscar en ~./.bashrc y cambiarla por el tema que nos guste (el predetermindo es bobby):

export BASH_IT_THEME='bobby'

🧩 ¿Entonces qué significa que Bash-it es un framework?

Significa que Bash-it provee un entorno estructurado y modular para personalizar tu shell Bash, con:

Elemento del framework	¿Qué ofrece?
📁 Estructura de directorios	Carpetas organizadas (`aliases/`, `plugins/`, `completion/`, `themes/`)
⚙️ Convenciones	Nombres de archivos (`custom.aliases.bash`, `custom.plugins.bash`)
🧰 Herramientas	Comandos como `bash-it enable`, `bash-it reload`
📦 Contenido reutilizable	Alias, funciones, completions y temas listos para usar o modificar
🔌 Modularidad	Activar o desactivar componentes sin tocar `.bashrc` directamente
🚀 Extensibilidad	Agregás tus propios módulos sin romper la base (`custom/` y `enabled/`)

🧪 Comparación simple

Sin framework (bash "a mano")	Con Bash-it
`.bashrc` lleno de alias y funciones	Alias y funciones separados por módulo
No hay forma de desactivar cosas fácilmente	`bash-it disable alias docker`
No hay temas de prompt	Temas configurables (`BASH_IT_THEME=...`)
Todo depende de cómo lo escribas vos	Hay convenciones y helpers

🔧 Troubleshooting

La mejor manera de descargar falsos positivos es instalar bash-it en contenedor podman o docker. Una vez que lo probamos allí y descartamoos que haya algo inherente a bash-it o al propio contendor. Luego podemos probarlo en la máquina que tiene el problema creando un usuario de prueba y realizar las siguientes pruebas.

Comparación de archivos de configuración

diff -u /home/sergio/.bashrc /home/test/.bashrc
diff -u /home/sergio/.bash_profile /home/test/.bash_profile

Verificar múltiples cargas de un determinado componente

Por ejemplo, si tenemos sourceado fzf en otro lugar además del plugin de fzf, tendrá problemas al hacer autocompletados de rutas inexistentes, y bash se colgará.

grep -r fzf ~/.bash*

Deshabilitar bash-it temporalmente

cp ~/.bashrc ~/.bash.bash-it
cp ~/.bashrc.bak ~/.bashrc
source `~/.bashrc`

Luego se puede realizar el proceso inverso si estamos en condiciones de volver a cargar bash-it.

✅ Conclusión

Bash-it un framework es decir que no es solo una colección de scripts, sino una forma organizada, modular y extensible de gestionar tu entorno de Bash, con convenciones y herramientas que te permiten escalar y mantener esa personalización de forma profesional.

Nos puede proporcinar un salto de calidad en el uso de bash. Por supuesto, ningún software es perfecto. Muchos plugins por ejemplo, tienen funcionalidades obsoletas o que no existen más. Y recordar que bash-it puede ser confiable en producción, siempre que:

✔️ Sea auditado y validado por tu equipo.
✔️ Se mantenga un control estricto sobre lo que se habilita.
✔️ Se provea capacitación a los usuarios.

Si no estás dispuesto a mantener estos controles internos, entonces sería más seguro no utilizarlo y seguir con .bashrc tradicionales o scripts controlados internamente.

De todas maneras esas tres condiciones: ¿no deberían aplicarlse a cualquier herramienta que se quiera adoptar?

Por otro lado, probar bash-it me sirvió para revisar configuraciones que venía acumulando con los años, muchas de ellas, las eliminé y otras las mejoré para adoptar las mejores prácticas de bash. Indudablemente un sysadmin experimentado podrá probablemente prescindir de bash-it, y usar una configuración ajustada a sus necesidades. Y ese es el aporte de bash-it, hacernos ver que podemos tener una configuración mucho más modular y ordenada.

¿Cuándo fue la última vez que verificaste tu entorno de shell?

🔗 Recursos recomendados para aprovechar a fondo Bash

🔖 Bash Manual (GNU)
La referencia canónica de Bash. Leé esto si querés entender cómo y por qué funciona Bash, no solo qué comandos usar.

🔖 Repositorio oficial de Bash-it
Tu punto de partida para transformar Bash en un entorno potente, modular y personal.

🔖 The Bash Hackers Wiki
Recurso mantenido por la comunidad técnica, con explicaciones brillantes sobre los aspectos más sutiles del shell.

🔖 Greg's Wiki – Bash Pitfalls
Una lista imprescindible de errores comunes en Bash, explicados por uno de los gurús del scripting shell.

🔖 Checks – ShellCheck Wiki
Una guía didáctica, profunda y sin concesiones. Ideal para quienes ya programan pero quieren escribir Bash de verdad. ShellCheck es una extraordinaria herramienta para verificar la calidad de nuestrs scrits y configuracines de bash. Aquí podemos consultar los SC codes,

Introducción a nftables y familia de direcciones

sebelk — Wed, 22 Jan 2025 18:07:44 GMT

Historia e Introducción

Antes de iptables y nftables, existía ipfwadm, una herramienta que se utilizaba en las primeras versiones del kernel de Linux para gestionar el firewall. Aunque ipfwadm sentó las bases para el firewalling en Linux, fue reemplazada debido a su limitada capacidad de manejo de tráfico y escalabilidad. Primero fue sustituida por ipchains y más tarde por el popular iptables.

Comunidad y Grupos Clave

Netfilter Project: La comunidad principal detrás de iptables y nftables. Este grupo ha sido esencial en el desarrollo, mantenimiento y promoción de herramientas de filtrado de paquetes en Linux.
Kernel Contributors: Muchos desarrolladores de kernel han colaborado en la optimización de las capacidades de firewalling en Linux, asegurando su integración fluida y eficiente.

Creación de nftables

nftables fue introducido en 2014 como el sucesor de iptables, diseñado para abordar las limitaciones de su predecesor en términos de rendimiento y escalabilidad.

Si bien eso fue hace más de 10 años, hay cambios tecnológicos que van por ascensor y otros por escalera. En ámbitos corporativos el mero hecho de reemplazar un software que es cardinal en una infraestructura, no es una tarea trivial. Ese cambio se debe a que los tiempos de vida de las distribuciones que las medianas y grandes organizaciones tienen soporte a largo a plazo. A veces es falta de urgencia y otras veces por sencilla negligencia :smile:.

Sin embargo apenas 3 datos para considerar la adopción de nftables:

RHEL9 considera iptables, ipset y ebtables herramientas depreciadas.
iptables no estará disponible en RHEL10 ni en OpenShift 4.16.
Debian Bullseye (a la fecha oldstable) ha depreciado iptables en favor de nftables.

¿Cuál es el problema de iptables?

Aunque ha sido una herramienta extraordinaria que ha servido de base para muchas soluciones de firewall, iptables presenta algunas limitaciones. A continuación, mencionamos tres de las más importantes:

Reprocesamiento completo al modificar reglas:
Cada vez que se agrega o elimina una regla, el kernel debe volver a procesar toda la lista de reglas. Este enfoque resulta ineficiente, especialmente en entornos donde se realizan cambios frecuentes o se manejan firewalls con un gran número de reglas.
Gestión complicada de rangos de direcciones IP:
Manejar rangos de direcciones IP o grandes conjuntos de direcciones en iptables puede ser tedioso y poco práctico. La herramienta ipset fue una solución ingeniosa para optimizar esta tarea, ya que permite manejar conjuntos de IPs, rangos o puertos de manera más eficiente. Sin embargo, su uso añade una capa de complejidad adicional al proceso de configuración y gestión.
Extensiones con sintaxis inconsistente:
iptables cuenta con extensiones como xtables, que amplían sus funcionalidades al incluir capacidades avanzadas como el seguimiento de conexiones o la inspección profunda de protocolos. No obstante, la sintaxis de estas extensiones no siempre es uniforme ni intuitiva, lo que puede dificultar su uso y generar confusiones en configuraciones complejas.

En cambio, desde su incorporación, nftables ha demostrado ser una herramienta eficiente y moderna para la gestión del tráfico de red en Linux. Una de sus principales innovaciones es consolidar las herramientas clásicas como iptables, ip6tables, ebtables y arptables en una única interfaz, simplificando tanto la configuración como el mantenimiento.

Conceptos claves de nftables

Contexto y Familias de Direcciones

En iptables, cada tipo de tráfico o protocolo tenía su propio comando o herramienta específica, que funcionaba de manera independiente:

Comando/herramienta	Propósito
`iptables`	Filtrar y manipular tráfico IPv4.
`ip6tables`	Filtrar y manipular tráfico IPv6.
`arptables`	Filtrar y manipular tráfico ARP.
`ebtables`	Filtrar tráfico en bridges (Ethernet frames).

Cada una de estas herramientas tenía su propia sintaxis y requería comandos separados para manejar diferentes tipos de tráfico, lo que podía ser confuso y propenso a errores.

Problemas del enfoque de iptables

Fragmentación:
- Si querías manejar tráfico IPv4 e IPv6, debías configurar reglas separadas con iptables e ip6tables, incluso si las reglas eran idénticas.
- Lo mismo ocurría si querías gestionar tráfico ARP con arptables o tráfico en bridges con ebtables.
Falta de unificación:
- Cada herramienta tenía su propia lógica, lo que aumentaba la complejidad administrativa.
- No existía una forma centralizada de gestionar tráfico que abarcase múltiples protocolos o tipos de datos.
Mantenimiento difícil:
- Las configuraciones de firewall requerían gestionar múltiples conjuntos de reglas, lo que hacía el mantenimiento y la depuración más complicados.

Cómo nftables mejoró este enfoque:

Introducción de familias: En nftables, las familias permiten manejar diferentes tipos de tráfico dentro de un mismo marco conceptual, con una sintaxis unificada.
- Familia ip: Maneja tráfico IPv4.
- Familia ip6: Maneja tráfico IPv6.
- Familia inet: Unifica IPv4 e IPv6.
- Familia arp: Maneja tráfico ARP.
- Familia bridge: Maneja tráfico L2 en bridges.
- Familia netdev: Maneja tráfico en interfaces específicas.
Unificación de reglas:
- Con la familia inet, puedes escribir reglas que funcionen tanto para IPv4 como para IPv6.
- Esto simplifica significativamente la configuración y el mantenimiento del firewall.
Menor duplicación de configuraciones: En lugar de mantener múltiples herramientas (iptables, ip6tables, arptables, ebtables), todo se gestiona con el comando nft.

Ejemplos en nftables:

# Una regla para IPv4 e IPv6
nft add rule inet filter input ip saddr 192.168.0.0/24 accept
nft add rule inet filter input ip6 saddr fc00::/7 accept

nft add table arp filter
nft add chain arp filter input { type filter hook input priority 0; }
# Permitir solicitudes ARP desde el rango 192.168.1.0/24 en eth0
nft add rule arp filter input iif "eth0" arp sip 192.168.1.0/24 arp op request accept

# Bloquear cualquier otra solicitud ARP
nft add rule arp filter input iif "eth0" arp op request drop

nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0; }
# Permitir solicitudes ARP desde direcciones MAC específicas en el bridge br0
nft add rule bridge filter forward iif "br0" ether type arp arp op request ether saddr 00:11:22:33:44:55 accept
nft add rule bridge filter forward iif "br0" ether type arp arp op request ether saddr 00:aa:bb:cc:dd:ee accept

# Bloquear cualquier otra solicitud ARP en el bridge
nft add rule bridge filter forward iif "br0" ether type arp arp op request drop

Diferencia entre las familias inet y netdev

La familia netdev puede ser una opción adecuada para implementar policing con nftables, dependiendo del escenario. Esto se debe a que la familia netdev opera en el hook ingress, lo que significa que puede evaluar el tráfico directamente en la interfaz antes de que llegue al stack de red.

Vamos a explorar por qué usar la familia netdev podría ser más apropiado para policing en algunos casos y cuándo es mejor utilizar otras familias.

Por qué usar la familia netdev para policing:

Posición temprana en el flujo del tráfico:
La familia netdev opera en el hook ingress, lo que significa que intercepta el tráfico inmediatamente después de que llega a la interfaz de red y antes de que sea procesado por el stack TCP/IP.
Esto permite implementar políticas de policing directamente en el nivel de la interfaz, evitando sobrecargar el sistema con tráfico innecesario.

Ejemplo de regla de policing en netdev:

nft add table netdev ingress
nft add chain netdev ingress mychain { type filter hook ingress priority 0; }
nft add rule netdev ingress mychain ip limit rate 10 mbps drop

Esta regla limita el tráfico IP entrante a 10 Mbps en la interfaz.
Evitar procesamiento innecesario:
Como netdev actúa antes de que los paquetes sean entregados al stack TCP/IP, los paquetes que no cumplen con las políticas son descartados sin consumir recursos adicionales del sistema.
Ideal para interfaces específicas:
Cuando el objetivo es aplicar policing solo en una interfaz específica (por ejemplo, eth0), la familia netdev es la opción más directa.
Compatibilidad con limit rate:
La familia netdev admite acciones como limit rate, que es esencial para configurar políticas de policing basadas en rates.

¿Cuándo usar netdev frente a otras familias (ip, inet)?

Criterio	Familia `netdev`	Familias `ip`/`inet`
Posición en el stack	Hook `ingress`, antes del stack TCP/IP.	Hook `prerouting`, `forward`, o `input`, después de ingresar al stack.
Eficiencia	Muy alta: paquetes descartados antes de procesarse.	Menor: los paquetes son procesados parcialmente antes de aplicar las políticas.
Tráfico inspeccionado	Solo tráfico entrante en una interfaz específica.	Tráfico en todas las interfaces (dependiendo de la configuración).
Complejidad de las reglas	Más limitada: ideal para políticas simples (policing básico).	Más flexible: soporta reglas complejas (filtrado avanzado, conntrack).
Uso típico	Policing directo en una interfaz (DDoS, límites de ancho de banda).	Filtrado y políticas basadas en estado o dirección IP.

Limitaciones de la familia netdev:

Solo para tráfico entrante:
La familia netdev opera únicamente en el hook ingress, por lo que no puedes aplicar policing en el tráfico saliente de una interfaz.
Falta de seguimiento de conexiones (conntrack):
No puedes usar estados como NEW o ESTABLISHED, ya que netdev opera antes de que el módulo conntrack pueda procesar el tráfico.
Menor flexibilidad:
Si necesitás reglas más complejas basadas en capas superiores (por ejemplo, L7 o estados de conexión), las familias ip o inet son más adecuadas.

¿Cuándo es mejor usar la familia netdev para policing?

Tráfico entrante en una interfaz específica: Cuando necesitás limitar o descartar tráfico directamente en una interfaz antes de que afecte el sistema. Ejemplo: Mitigar un ataque DDoS en eth0.
Simplicidad y eficiencia: Si solo necesitas evaluar tráfico basándote en tasas o direcciones básicas (IP, MAC).

Ejemplo práctico:

Supongamos que queremos limitar el tráfico entrante a 100 Mbps en una interfaz específica (eth0):

nft add table netdev ingress
nft add chain netdev ingress eth0_chain { type filter hook ingress priority 0; }
nft add rule netdev ingress eth0_chain limit rate 100 mbps drop

Diferencia entre la familia bridge y netdev

Dado que la tanto la tabla bridge como la tabla netdev operan en Capa 2 uno podría preguntarse, qué diferencia hay entre estas dos familias, aquí tenemos una tabla comparativa detallada entre las familias bridge y netdev en nftables:

Aspecto	Familia `bridge`	Familia `netdev`
Nivel del modelo OSI	Capa 2 (L2)	Capa 2 (L2), pero en el contexto de interfaces individuales.
Tráfico manejado	Tráfico que cruza un bridge (tramas Ethernet).	Todo el tráfico en una interfaz específica antes de llegar al stack de red.
Propósito principal	Controlar y filtrar tráfico dentro de bridges.	Filtrar tráfico en una interfaz individual (sin importar si forma parte de un bridge).
Ámbito de aplicación	Solo funciona en interfaces que forman parte de un bridge.	Funciona en cualquier interfaz (física o virtual), bridge o no.
Casos de uso típicos	- Aislar tráfico entre puertos de un bridge. - Proteger bridges contra broadcast storms, spoofing de MAC, etc. - Controlar tráfico entre VLANs en un bridge.	- Filtrar tráfico directo en una interfaz (ingress/egress). - Detectar y mitigar DDoS a nivel de interfaz. - Filtrar ARP o IPv4 antes de pasar al stack de red.
Compatibilidad con VLANs	Sí, puede filtrar tráfico basado en etiquetas VLAN (802.1Q).	No trabaja específicamente con VLANs.
Estado de conexión	No tiene integración con `conntrack`.	No tiene integración con `conntrack`.
Posición en el stack	Filtra tráfico que pasa a través de un bridge antes de ser reenviado.	Filtra tráfico directamente en una interfaz, antes de ser procesado por el stack de red.
Soporte de ARP	Sí, puede filtrar tramas ARP.	Sí, puede filtrar tramas ARP.
Soporte de IPv4/IPv6	Sí, puede inspeccionar tráfico IP encapsulado.	Sí, puede inspeccionar tráfico IP encapsulado.
Direcciones MAC	Puede filtrar según direcciones MAC de origen y destino.	Puede filtrar según direcciones MAC de origen y destino.
Uso con interfaces individuales	No, requiere que las interfaces formen parte de un bridge.	Sí, funciona en cualquier interfaz individual.
Reemplaza a...	`ebtables`.	`tc ingress` para ciertas tareas de filtrado.
Limitaciones	- Solo opera en tráfico dentro de bridges. - No puede controlar tráfico de interfaces individuales fuera del bridge.	- No tiene integración con `conntrack`. - No puede manejar tráfico reenviado entre interfaces.

Diferencias clave entre bridge y netdev:

Ámbito del tráfico manejado:
bridge: Filtra tráfico que cruza un bridge, conectando múltiples interfaces dentro del mismo dominio de difusión.
netdev: Filtra tráfico directo en una interfaz individual, antes de pasar al stack de red.
Dependencia de bridges:
bridge: Solo funciona en interfaces que son parte de un bridge.
netdev: Funciona en cualquier interfaz, sin importar si es parte de un bridge o no.
Posición en el stack de red:
bridge: Opera después de que el tráfico ha ingresado al bridge pero antes de ser reenviado a otra interfaz.
netdev: Opera antes de que el tráfico entre al stack de red del sistema operativo, en el hook ingress.
Casos de uso:
bridge: Aislar tráfico dentro del bridge, controlar VLANs, proteger contra ataques L2 como spoofing de MAC.
netdev: Inspeccionar todo el tráfico que entra o sale de una interfaz específica, ideal para mitigación temprana de DDoS o filtros basados en MAC/IP/ARP.

¿Cuándo usar cada una?

Usa la familia bridge si:

Tenemos configurado un bridge que conecta múltiples interfaces.
Necesitamos controlar tráfico entre dispositivos conectados al mismo bridge.
Queremos aislar tráfico entre VLANs o puertos del bridge.
Deseamos implementar políticas de seguridad para tráfico L2 dentro del bridge.

Usa la familia netdev si:

Queremos filtrar tráfico directo en una interfaz individual, incluso si no es parte de un bridge.
Necesitamos mitigar DDoS o ataques en el hook más temprano (ingress), antes de que el tráfico llegue al stack de red.
Deseamos inspeccionar tráfico ARP, IPv4 o IPv6 en una interfaz específica.

Ejemplos prácticos:

Con bridge:

Bloquear tráfico entre dos interfaces en un bridge:

nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0; }
nft add rule bridge filter forward iif "eth0" oif "eth1" drop
nft add rule bridge filter forward iif "eth1" oif "eth0" drop

Permitir solo tráfico ARP en el bridge:

nft add rule bridge filter forward ether type arp accept
nft add rule bridge filter forward drop

Con netdev:

Bloquear todo el tráfico IPv4 en una interfaz específica (eth0):

nft add table netdev filter
nft add chain netdev filter ingress { type filter hook ingress priority 0; }
nft add rule netdev filter ingress iif "eth0" ip drop

Mitigar ataques DDoS limitando paquetes por segundo:

nft add rule netdev filter ingress iif "eth0" ip limit rate 1000/second drop

Entonces:

Familia bridge: Para manejar tráfico dentro de un bridge, enfocándose en L2 (direcciones MAC, VLANs, tramas Ethernet).
Familia netdev: Para filtrar tráfico temprano en una interfaz específica, independientemente de si forma parte de un bridge.

Ambas familias trabajan en L2, pero con propósitos distintos y aplicables en diferentes escenarios.

Resumen:

En iptables, no existía el concepto de familias. En su lugar, se usaban herramientas separadas para cada protocolo o tipo de tráfico (iptables, ip6tables, arptables, ebtables). Esto hacía que la configuración fuera fragmentada y menos eficiente.

Con la llegada de nftables, se introdujo el concepto de familias para unificar la gestión de diferentes tipos de tráfico, mejorando la flexibilidad, la simplicidad y el mantenimiento de las reglas de firewall. Este cambio fue una de las razones clave por las que nftables es considerado un reemplazo moderno y más avanzado.

Conocer en profundidad nftables y el concepto de las familias, tiene implicancias sumamente prácticas. Por ejemplo: ¿qué familia usarías para poder separar en una misma LAN el tráfico inalámbrico del cableado? Lo dejo para que lo pienses. 😊

Fuentes y más información

¿SELinux? Nah, dejalo en Disabled

sebelk — Mon, 25 Nov 2024 00:15:35 GMT

En el mundo real muchos sysadmins y developers en sistemas operativos de la familia Red Hat deshabilitan SELinux. "¡Es muy difícil!" dicen. En Ubuntu ni en Debian existe esa cuestión ya que en su lugar se usa AppArmor. Este post no te dará servido en bandeja como solucionar un problema, sino algo mucho más valioso, que es entender el fundamento del comportamiento de SELinux y por qué funciona la solución que vayas a aplicar.

Usamos un caso práctico: tenemos una instalación basada en Laravel, php-fpm y con nginx como web server.

Tenemos una estructura de directorio así:

> tree -L 1 /home/sergio/laravel-voyager/
/home/sergio/laravel-voyager/
├── app
├── artisan
├── bootstrap
├── composer.json
├── composer.lock
├── config
├── database
├── lang
├── package.json
├── phpunit.xml
├── public
├── README.md
├── resources
├── routes
├── storage
├── tests
├── vendor
└── vite.config.js

11 directories, 7 files

Veamos la información de SELinux para algunos archivos y directorios:

[sergio@masterk laravel-voyager]$ sudo ls -Zd public/storage /etc/nginx /home/sergio/.bashrc /root/.bashrc /usr/share/nginx/ bootstrap/cache/
[sudo] password for sergio: 
unconfined_u:object_r:user_home_t:s0 bootstrap/cache/      unconfined_u:object_r:user_home_t:s0 public/storage
 system_u:object_r:httpd_config_t:s0 /etc/nginx               system_u:object_r:admin_home_t:s0 /root/.bashrc
    system_u:object_r:user_home_t:s0 /home/sergio/.bashrc            system_u:object_r:usr_t:s0 /usr/share/nginx/

Si bien la salida es demasiado críptica, la podemos descifrar:

Archivo/Directorio	Usuario (SELinux)	Rol (SELinux)	Asignación basada en tipos (SELinux)	Rango (SELinux)	Descripción y Observaciones
bootstrap/cache/	`unconfined_u`	`object_r`	`user_home_t`	`s0`	Considerado como parte del directorio personal de un usuario. Debe ser `httpd_sys_rw_content_t` para Laravel.
public/storage	`unconfined_u`	`object_r`	`user_home_t`	`s0`	Similar a `bootstrap/cache`. Debe ser `httpd_sys_content_t` para que Laravel sirva archivos estáticos.
/etc/nginx	`system_u`	`object_r`	`httpd_config_t`	`s0`	Archivo de configuración de Nginx. Correctamente etiquetado como `httpd_config_t`. No requiere cambios.
/home/sergio/.bashrc	`system_u`	`object_r`	`user_home_t`	`s0`	Archivo personal de configuración de un usuario. Etiquetado como `user_home_t`, lo cual es correcto.
/root/.bashrc	`system_u`	`object_r`	`admin_home_t`	`s0`	Archivo de configuración del usuario `root`. Etiquetado como `admin_home_t`, lo cual es correcto.
/usr/share/nginx/	`system_u`	`object_r`	`usr_t`	`s0`	Etiquetado como `usr_t`, que es genérico. Debe ser `httpd_sys_content_t` si Nginx sirve contenido estático aquí.

Descripción de los campos

Concepto	Descripción	Ejemplo
Usuario (SELinux)	Define el usuario de SELinux asociado al recurso.	`system_u`: Archivo gestionado por el sistema. `unconfined_u`: Archivo de un usuario sin restricciones.
Rol (SELinux)	Define el rol asignado al recurso.	Usualmente es `object_r` para archivos regulares y directorios.
Asignación basada en tipos	Determina qué procesos o aplicaciones pueden interactuar con un recurso.	`httpd_sys_rw_content_t`: Permite lectura/escritura por parte del servidor web. `httpd_sys_content_t`: Permite solo lectura por parte del servidor web. `user_home_t`: Para directorios o archivos en `/home`.
Rango (SELinux)	Se usa para configuraciones de seguridad MLS o TE (usualmente `s0` en configuraciones estándar).	Normalmente no requiere ajustes en configuraciones básicas.

Ahora bien, hay varios tipos de políticas en cuanto a funcionalidades que se pueden aplicar en SELinux, la que se usa en general es targeted. El tipo de política targeted significa que determinados servicios se ejecutan de manera confinada, es decir limitada para realizar solamente determinadas acciones más allá de los permisos ordinarios.

Y es importante enfatizar que cuando usamos targeted el campo que más nos tiene que interesar de un contexto es el "Type Enforcement". En general no prestaremos demasiada atención al resto de los campos.

Lo más importante para entender es que las reglas de SELinux tienen sujetos y objetos. El contexto o etiqueta del objeto podría no permitir que el sujeto realice una determinada acción al sujeto, y es allí cuando se produce un error. Dicho error tiene por objetivo proteger al sistema. En este ejemplo los sujetos son nginx y php-fpm y los objetos son los directorios bootstrap/cache y public/storage (y sus respectivos contenidos).

Por ejemplo, nginx sería el sujeto y con el siguiente comando vemos el contexto del proceso:

> ps -C nginx,php-fpm -Z
LABEL                               PID TTY          TIME CMD
system_u:system_r:httpd_t:s0        898 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1118 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1119 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1120 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1121 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1122 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1451 ?        00:00:00 nginx
system_u:system_r:httpd_t:s0       1452 ?        00:00:00 nginx
system_u:system_r:httpd_t:s0       1453 ?        00:00:00 nginx

Pero habrá problemas...

La cuestión es que tanto nginx como php-fpm se ejecutan con la asignación de tipo (TE) httpd_t y la TE que tienen directorior como bootstrap/cache y public/storage es user_home_t.

Con el siguiente comando podemos verificar qué cosas puede hacer el dominio httpd_t en el contexto del objeto que tiene el tipo de asignación user_home_t:

> sesearch -s httpd_t -A -t user_home_t
allow daemon user_home_t:file { append getattr };
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow httpd_t file_type:dir { getattr open search };
allow httpd_t file_type:filesystem getattr;
allow httpd_t user_home_t:file map; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr ioctl lock open read search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_enable_homedirs ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:file { getattr ioctl lock open read }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:lnk_file { getattr read }; [ httpd_enable_homedirs ]:True

Cada regla tiene:

El tipo de regla ( allow )
El sujeto de la regla ( httpd_t )
El contexto y tipo del objeto ( user_home_t:file )
Los permisos (append y getattr)

¡No hay ninguna regla que permita la modificación total del contenido del archivo ni la creación de archivos en la carpeta (por ejemplo, el permiso write)!. Esto significa que, de manera predeterminada, servicios como apache o nginx no tienen permiso para escribir en los directorios home de los usuarios. Y por ese motivo hay cosas que fallarán, sin importar los permisos ni el usuario...

Por lo tanto los directorios public/storage y bootstrap/cache y su contenido necesitan otro contexto para que Laravel funcione correctamente cuando está ubicado en un subdirectorio de /home. Mirando la documentación podemos ver que httpd_sys_content_t y httpd_sys_rw_content son respectivamente los apropiados para esos directorios y su contenido:

httpd_sys_content_t

- Set files with the httpd_sys_content_t type, if you want to treat the files as httpd sys content.

Paths:
     /srv/([^/]*/)?www(/.*)?,  /var/www(/.*)?,  /etc/htdig(/.*)?,   /srv/gallery2(/.*)?,   /var/lib/trac(/.*)?,   /var/lib/htdig(/.*)?,
     /var/www/icons(/.*)?,     /usr/share/glpi(/.*)?,     /usr/share/htdig(/.*)?,     /usr/share/drupal.*,     /usr/share/z-push(/.*)?,
     /var/www/svn/conf(/.*)?,         /usr/share/icecast(/.*)?,          /var/lib/cacti/rra(/.*)?,          /usr/share/ntop/html(/.*)?,
     /usr/share/nginx/html(/.*)?,      /usr/share/doc/ghc/html(/.*)?,      /usr/share/openca/htdocs(/.*)?,      /usr/share/selinux-pol‐
     icy[^/]*/html(/.*)?

httpd_sys_rw_content_t

- Set files with the httpd_sys_rw_content_t type, if you want to treat the files as httpd sys read/write content.

Paths:
     /etc/rt(/.*)?,  /etc/glpi(/.*)?,  /etc/horde(/.*)?,  /etc/drupal.*,  /etc/z-push(/.*)?,  /var/lib/svn(/.*)?,   /var/www/svn(/.*)?,
     /etc/owncloud(/.*)?,    /var/www/html(/.*)?/uploads(/.*)?,    /var/www/html(/.*)?/wp-content(/.*)?,   /var/www/html(/.*)?/wp_back‐
     ups(/.*)?,  /var/www/html(/.*)?/sites/default/files(/.*)?,  /var/www/html(/.*)?/sites/default/settings.php,  /etc/mock/koji(/.*)?,
     /etc/nextcloud(/.*)?,       /var/lib/drupal.*,      /etc/zabbix/web(/.*)?,      /var/lib/moodle(/.*)?,      /var/log/z-push(/.*)?,
     /var/spool/gosa(/.*)?,   /etc/WebCalendar(/.*)?,   /usr/share/joomla(/.*)?,   /var/lib/dokuwiki(/.*)?,    /var/lib/owncloud(/.*)?,
     /var/spool/viewvc(/.*)?, /var/lib/nextcloud(/.*)?, /var/lib/pootle/po(/.*)?, /var/lib/phpMyAdmin(/.*)?, /var/www/moodledata(/.*)?,
     /srv/gallery2/smarty(/.*)?,      /var/www/moodle/data(/.*)?,      /var/lib/graphite-web(/.*)?,      /var/log/shibboleth-www(/.*)?,
     /var/www/gallery/albums(/.*)?,  /var/www/html/owncloud/data(/.*)?, /var/www/html/nextcloud/data(/.*)?, /usr/share/wordpress-mu/wp-
     content(/.*)?, /usr/share/wordpress/wp-content/upgrade(/.*)?, /usr/share/wordpress/wp-content/uploads(/.*)?, /var/www/html/config‐
     uration.php

De modo que esos son los contextos que tendrías que aplicar a esos directorios y sus contenidos. El resto, si sos administrador o desarrollador de Linux con algo de experiencia es anecdótico.

Fuentes y más recursos

Página del manual de httpd_selinux
Ventajas de usar SELinux
Desactivación de SELinux
Página del manual de booleans (concepto importante que complementan a las reglas de las políticas de SELinux)

Qué son los cgroups y para qué sirven

sebelk — Fri, 25 Oct 2024 22:46:07 GMT

En el post anterior vimos los namespaces, que sirven para aislar diferentes aspectos del sistema, como los procesos, la red y los puntos de montaje, creando entornos independientes para cada grupo de procesos. En este post, exploraremos los cgroups, que permiten controlar cuánto de los recursos del sistema, como CPU, memoria y disco, puede usar cada grupo de procesos. Ambas tecnologías se complementan: los namespaces proporcionan el aislamiento necesario, mientras que los cgroups gestionan y limitan los recursos que esos entornos aislados pueden consumir.

¿Qué son los cgroups?

Los cgroups (control groups) son una funcionalidad del kernel Linux que permite agrupar procesos y controlar de manera granular los recursos del sistema que consumen, como CPU, memoria, I/O, y otros. Se incorporaron en 2008 en el kernel de Linux 2.6.24, los cgroups permiten a los administradores de sistemas gestionar el uso de recursos por grupos de procesos de forma eficiente, garantizando una distribución justa y controlada.

Los cgroups crean una jerarquía de control donde es posible asignar límites a recursos específicos para un conjunto de procesos, de manera que el sistema operativo pueda monitorear, limitar, priorizar o aislar estos procesos según sea necesario. Esta capacidad es clave para garantizar que los sistemas multitarea, servidores, y contenedores funcionen de manera eficiente.

¿Para qué sirven los cgroups?

Los cgroups sirven para:

Limitar el uso de recursos
Priorizar procesos
Aislar procesos
Monitorear el consumo de recursos
Controlar procesos en contenedores (Docker, podman,etc.)

Un pantallazo de los cgroups

Dentro del propio directorio /proc podemos encontrar información sobre los cgroups:

❯ cat /proc/cgroups 
#subsys_name    hierarchy       num_cgroups     enabled
cpuset  0       241     1
cpu     0       241     1
cpuacct 0       241     1
blkio   0       241     1
memory  0       241     1
devices 0       241     1
freezer 0       241     1
net_cls 0       241     1
perf_event      0       241     1
net_prio        0       241     1
hugetlb 0       241     1
pids    0       241     1
rdma    0       241     1
misc    0       241     1

Este archivo muestra 4 columnas

Campo	Significado
subsys_name	Componente del kernel que controlar un recurso específico un aspecto del sistema.
hierarchy	La columna `hierarchy` indica el ID de jerarquía asignado a cada subsistema. En este caso, todas las jerarquías tienen el valor 0, lo que indica que todos los subsistemas listados están utilizando una jerarquía unificada, común en sistemas que usan cgroups v2. En cgroups v2, todos los controladores utilizan una única jerarquía para gestionar los recursos de manera más eficiente, a diferencia de cgroups v1, donde cada subsistema podía tener su propia jerarquía.
num_cgroups	Muestra el número de cgroups activos o instancias creadas bajo cada controlador. Estos cgroups pueden pertenecer a procesos que están ejecutándose actualmente en el sistema, como servicios, contenedores, o procesos individuales.
enabled	Esta columna muestra si el subsistema está habilitado o no. El valor 1 indica que el controlador está habilitado y activo, mientras que un valor de 0 indicaría que está deshabilitado.

Evolución de los cgroups:

cgroups v1: En la versión original, cada tipo de recurso (CPU, memoria, etc.) tenía su propia jerarquía de control, lo que permitía una gestión separada pero a veces compleja. Aunque era útil, la administración independiente de subsistemas podía resultar difícil de manejar en entornos complejos.
cgroups v2 (2016): Para mejorar la gestión de recursos, se introdujo cgroups v2 en el kernel de Linux 4.x, que unificó los diferentes controladores bajo una jerarquía única. Esta versión simplificó el control de recursos y mejoró la eficiencia, permitiendo que todos los subsistemas trabajaran de manera más coordinada y con configuraciones más claras.

Cómo crear un cgroup y limitar el uso de CPU en cgroups v2

En este ejemplo, limitaremos el uso de CPU de un proceso utilizando cgroups v2 en un entorno moderno.

Paso 1: Crear un directorio para el cgroup

En cgroups v2, se gestiona todo bajo una jerarquía unificada. Primero, crea un nuevo directorio en /sys/fs/cgroup:

sudo mkdir /sys/fs/cgroup/mi_cgroup

Paso 2: Establecer un límite de CPU

En cgroups v2, puedes establecer límites en el uso de CPU mediante el archivo cpu.max. Este archivo recibe dos valores: el primero es el límite de uso de CPU en microsegundos por cada período de 100 milisegundos, y el segundo es la duración del período en microsegundos.

Para limitar el uso de CPU al 50%, puedes hacer lo siguiente:

echo "50000 100000" | sudo tee /sys/fs/cgroup/mi_cgroup/cpu.max

Este comando establece que los procesos en este cgroup pueden usar un máximo de 50.000 microsegundos de CPU en un período de 100.000 microsegundos (100 ms), lo que equivale al 50% de un núcleo de CPU.

Paso 3: Añadir un proceso al cgroup

Para añadir un proceso existente al cgroup, escribe su PID (ID del proceso) en el archivo cgroup.procs de ese cgroup. Supongamos que el PID del proceso es 78435:

echo 78435| sudo tee /sys/fs/cgroup/mi_cgroup/cgroup.procs

Esto moverá el proceso con PID 78435 al cgroup mi_cgroup, aplicando las restricciones de CPU configuradas.

En cgroups v1, los recursos se gestionan usando archivos como cpu.shares para establecer prioridades relativas de CPU, y tasks para asignar procesos a un cgroup. En cambio, en cgroups v2, el control de CPU se realiza a través de cpu.max, donde se puede establecer un límite absoluto en el uso de CPU (como un porcentaje). Además, en v1 cada subsistema tiene su propio directorio (como cpu/, memory/), mientras que en v2 todo se gestiona dentro de una única jerarquía unificada bajo /sys/fs/cgroup/.

Conclusión

Hoy en día, los cgroups son una herramienta crítica en la gestión moderna de servidores. RHEL8 usa de manera predeterminada la versión 1, pero es posible usar la versión 2, dependiendo del software que utilicemos. En definitiva, los cgroups son fundamentales para la operación de tecnologías como contenedores (Docker, Podman), orquestadores como Kubernetes, y cualquier sistema que necesite control granular de recursos. La capacidad de aislar, priorizar y monitorear el uso de recursos en servidores es clave para garantizar la estabilidad y el rendimiento en entornos de alta demanda.

Fuentes y más información

Qué son los namespaces y que podemos hacer con ellos

sebelk — Sat, 03 Aug 2024 19:29:34 GMT

En el post anterior, exploramos qué es Flatpak, una excelente alternativa o complemento a los métodos tradicionales de instalación de programas en Linux. Flatpak utiliza una herramienta llamada bubblewrap, que a su vez emplea la tecnología de namespaces.

Veamos con lupa lo que hay debajo de una aplicación flatpak.

Listado de procesos de aplicaciones flatpak

❯ flatpak ps --columns=pid,child-pid,application
PID  PID-hijo Aplicación
4588 4610     com.github.marktext.marktext
4629 4639     com.github.marktext.marktext
4841 4853     com.spotify.Client

Este listado nos muestra que hay dos aplicaciones corriendo: MarkText y Spotify. Vamos a ver qué pasa con uno de los procesos relacionados con MarkText.

El comando detrás de flatpak

❯ ps p  4610 o args
COMMAND
/usr/bin/bwrap --args 42 -- spotify

bwrap es una herramienta para crear sandboxes por medio de namespaces. Un namespace es un recurso del sistema que se puede aislar, pero... en lugar de abundar en tecnicismos, para comprender este concepto en la práctica, veremos algunas propiedades del proceso 4610 (MarkText):

❯ ls -l /proc/4610/ns
total 0
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:40 mnt -> 'mnt:[4026532856]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 net -> 'net:[4026531840]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:40 pid -> 'pid:[4026532857]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 pid_for_children -> 'pid:[4026532857]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 time -> 'time:[4026531834]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 time_for_children -> 'time:[4026531834]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:40 user -> 'user:[4026532858]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 uts -> 'uts:[4026531838]'

Ese listado nos muestra que están los namespaces cgroup, ipc, mnt, net, pid, time, user y uts. Cada uno de ellos tiene un número que lo identifica.

Podemos compararlo con otros procesos por ejemplo con el pid 1 y con el pid del shell que estamos usando:

Podemos ver que tanto bash como systemd comparten todos los namespaces. Sin embargo, bwrap tiene namespaces distintos para mnt, pid y user. Es decir tiene esos recursos aislados.

El cuadro siguiente nos sirve para saber qué namespace usar de acuerdo a lo que queramos aislar:

Para aislar	Usar namespace...
Límites de recursos	cgroups
Colas de mensaje, semáforos, memoria compartida	ipc
Lista de montajes	mount
Interfaces de red, ruteo, sockets, etc.	net
Números de pid	pid
UID's, GID's, capabilities, etc	user
Hostnames	uts
Relojes/Tiempo	time

El soporte en el kernel lo podemos verificar de la siguiente manera:

grep -E 'CONFIG_[A-Z]+_NS=y' /boot/config-$(uname -r)
CONFIG_UTS_NS=y
CONFIG_TIME_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y

Crear nuevos namespaces para procesos y usuarios

La herramienta unshare nos permite experimentar y solucionar problemas en aplicaciones y servicios que usan namespaces. En el siguiente ejemplo abrimos un shell con namespaces aislados para usuarios y números de procesos:

❯ unshare --mount-proc --pid --fork --user bash
❯ ps aux
   USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   nobody         1  2.8  0.0 237808 12996 pts/1    S    13:43   0:00 bash
   nobody       104  0.0  0.0 230836  4096 pts/1    R+   13:43   0:00 ps aux

Aquí vemos que bash usa el PID 1 en lugar de systemd, y que el comando ps aux toma el pid 2.
Además, el usuario pasa a ser nobody.
Para salir del namespace, simplemente hay que ejecutar exit. Es importante asegurarse de que todos los procesos dentro del namespace hayan terminado, de lo contrario, puede ser que exit sea insuficiente para salir completamente del namespace.

¿Por qué usamos --mount-proc?

Bueno... porque si no lo hacemos sucede esto:

❯ unshare --mount --pid --fork --user /bin/bash
basename: falta un operando
Pruebe 'basename --help' para más información.

Este mensaje aparece porque el comando basename usa readlink para ver hacia dónde apunta /proc/$$/exe. Como el PID de la shell en el nuevo namespace es 1, intenta acceder incorrectamente al directorio /proc en los namespaces del host. Linux impide este acceso para mantener el aislamiento y la seguridad, lo que resulta en ese error.

Particularidades de namespaces

❯ unshare --mount-proc --pid --user /bin/bash
unshare: mount /proc failed: Operación no permitida
❯ unshare --pid --user /bin/bash
bash: fork: No se pudo asignar memoria

En el primer intento, ni siquiera pudo crear los namespaces; en el segundo, aunque lo logró, muestra un mensaje críptico:

bash: fork: No se pudo asignar memoria

Estos errores ocurren porque unshare, por defecto, ejecuta el comando indicado en el mismo proceso (similar a exec), lo que resulta en:

Error de Montaje: El sistema no permite montar /proc porque el proceso no tiene el contexto completo de namespace de usuario y PID necesario.
Error de Memoria: Debido a que bash no se convierte en PID 1 ni puede acceder a otro proceso con PID 1, Linux no permite la asignación de memoria porque no hay un proceso para manejar la recolección de zombies y otras tareas esenciales.

Por lo tanto, usar --fork es necesario para asegurar que el proceso tenga el contexto de namespace completo y para crear un nuevo proceso que actúe como PID 1 en el nuevo namespace.

Entrar en namespaces de una app de flatpak

❯ sudo nsenter --mount --pid -S $UID -t 4610
-bash-5.2$ ps auxwww
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
sergio         1  0.0  0.0   3764  1288 ?        S    18:40   0:00 /usr/bin/bwrap --args 40 -- marktext
sergio         2  0.9  0.5 21637908 182648 ?     SLl  18:40   0:15 /app/marktext/marktext
sergio         5  0.0  0.0   5640  1664 ?        S    18:40   0:00 cat
sergio         6  0.0  0.0   5640  1792 ?        S    18:40   0:00 cat
sergio        10  0.0  0.1 16987244 46720 ?      S    18:40   0:00 /app/marktext/marktext --type=zygote --no-zygote-sandbox
sergio        12  0.0  0.0      0     0 ?        Z    18:40   0:00 [zypak-sandbox] <defunct>
sergio        15  0.0  0.0   3768  1152 ?        S    18:40   0:00 /usr/bin/bwrap --args 42 -- /app/bin/zypak-helper child - /app/marktext/marktext --type=zygote
sergio        16  0.0  0.1 16989892 49152 ?      S    18:40   0:00 /app/marktext/marktext --type=zygote
sergio        48  1.4  0.2 17065152 72664 ?      Sl   18:40   0:23 /app/marktext/marktext --type=gpu-process --field-trial-handle=9170851604328465342,17458150017059513700,131072 --disable-features=SpareRendererForSitePerProcess --enable-crash-reporter=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel --global-crash-keys=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel,_companyName=marktext,_productName=marktext,_version=0.17.1 --user-data-dir=/home/sergio/.var/app/com.github.marktext.marktext/config/marktext --gpu-preferences=UAAAAAAAAAAgAAAIAAAAAAAAAAAAAAAAAABgAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA= --use-gl=swiftshader-webgl --shared-files
sergio        53  0.0  0.0 16998948 14448 ?      S    18:40   0:00 /app/marktext/marktext --type=broker
sergio        63  0.0  0.1 17044740 57216 ?      Sl   18:40   0:00 /app/marktext/marktext --type=utility --utility-sub-type=network.mojom.NetworkService --field-trial-handle=9170851604328465342,17458150017059513700,131072 --disable-features=SpareRendererForSitePerProcess --lang=es-419 --service-sandbox-type=none --enable-crash-reporter=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel --global-crash-keys=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel,_companyName=marktext,_productName=marktext,_version=0.17.1 --user-data-dir=/home/sergio/.var/app/com.github.marktext.marktext/config/marktext --shared-files=v8_context_snapshot_data:100
sergio        74  5.2  0.6 25595728 212480 ?     Sl   18:40   1:27 /app/marktext/marktext --type=renderer --enable-crash-reporter=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel --global-crash-keys=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel,_companyName=marktext,_productName=marktext,_version=0.17.1 --user-data-dir=/home/sergio/.var/app/com.github.marktext.marktext/config/marktext --app-path=/app/marktext/resources/app.asar --no-sandbox --no-zygote --field-trial-handle=9170851604328465342,17458150017059513700,131072 --disable-features=SpareRendererForSitePerProcess --disable-gpu-compositing --lang=es-419 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=4 --no-v8-untrusted-code-mitigations --shared-files=v8_context_snapshot_data:100
sergio       144  0.0  0.0   7884  4224 ?        S    19:08   0:00 -bash
sergio       145  0.0  0.0  11032  4608 ?        R+   19:08   0:00 ps auxwww

La herramienta nsenter permite ejecutar comandos en namespaces de un proceso determinado, en este caso, el de bwrap. Como no especificamos ningún comando, corre el shell bash.

Allí podemos ver el espacio de nombres aislados de números de procesos, como se ve arriba, o como mostramos a continuación, los montajes aislados:

-bash-5.2$ df -h  
S.ficheros     Tamaño Usados  Disp Uso% Montado en  
tmpfs             16G    92K   16G   1% /etc/timezone  
/dev/sda6        511G   434G   76G  86% /cs  
tmpfs             16G      0   16G   0% /usr/lib/x86_64-linux-gnu/GL  
/dev/sda6        511G   434G   76G  86% /home  
tmpfs            3,2G    11M  3,2G   1% /run/host/monitor  
tmpfs             16G    15M   16G   1% /dev  
devtmpfs         4,0M      0  4,0M   0% /dev/tty  
tmpfs             16G      0   16G   0% /home/sergio/.local/share/flatpak  
tmpfs             16G      0   16G   0% /home/sergio/.var/app  
/dev/sda3        382G   100G  283G  27% /mnt/win10  
tmpfs            6,3G   2,3M  6,3G   1% /run/media  
tmpfs             16G   4,0M   16G   1% /tmp  
tmpfs             16G      0   16G   0% /tmp/.X11-unix

También podemos pensar que estos recursos que se aíslan se virtualizan. Cuando hablamos de virtualización, probablemente pensemos en un disco o en una interfaz de red virtual. Pero aquí vemos, por ejemplo, que un espacio de nombres de PID's también se puede virtualizar.

Y cuando más de un recurso se puede virtualizar, de ahí a crear un contenedor hay una corta distancia. De hecho, los namespaces sirve tanto para un usuario final con flatpak como en la creación de contenedores lxc (ah, sí lxc existe desde 2008, aunque ya no esté más de moda 😁) docker o podman para un sysadmin o un desarrollador.

A continuación, veremos algunos ejemplos de cómo utilizar los namespaces en contenedores Podman. Es importante conocer el PID del contenedor en el host para estos ejemplos.

Ejemplo 1: Ver la configuración de red del contenedor que usa network mode pasta

❯ podman unshare nsenter --target 29420 --net  
❯ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
2: wlp108s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether ea:38:5b:0b:a8:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.144/24 brd 192.168.0.255 scope global noprefixroute wlp108s0
       valid_lft forever preferred_lft forever
    inet6 fe80::e838:5bff:fe0b:a8a8/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Ejemplo 2: Ver la configuración de red del contenedor que usa network mode slirp4netns

  podman unshare nsenter --target 46222 --net  

  root in ~/to_delete 
  ❯ ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host proto kernel_lo 
         valid_lft forever preferred_lft forever
  2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
      link/ether 92:b6:67:25:13:33 brd ff:ff:ff:ff:ff:ff
      inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
         valid_lft forever preferred_lft forever
      inet6 fd00::90b6:67ff:fe25:1333/64 scope global dynamic mngtmpaddr proto kernel_ra 
         valid_lft 86356sec preferred_lft 14356sec
      inet6 fe80::90b6:67ff:fe25:1333/64 scope link proto kernel_ll 
         valid_lft forever preferred_lft forever

Ejemplo 3: Probar la resolución de nombres usando el archivo /etc/resolv.conf del contenedor

❯ container_id=$(podman inspect --format '{{.Id}}' namespace-demo)
❯ cp /run/user/1000/containers/overlay-containers/$container_id/userdata/resolv.conf /tmp/container_resolv.conf    
❯ podman unshare nsenter --target 46222  --net dig google.com @$(grep -m 1 'nameserver' /tmp/container_resolv.conf | awk '{print $2}')

; <<>> DiG 9.18.26 <<>> google.com @10.0.2.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25213
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             263     IN      A       142.251.133.78

;; Query time: 30 msec
;; SERVER: 10.0.2.3#53(10.0.2.3) (UDP)
;; WHEN: Thu Jul 25 19:50:18 -03 2024
;; MSG SIZE  rcvd: 55

Ejemplo 4: Ver los procesos de un contenedor rootless

❯ sudo nsenter --pid=/proc/$container_pid/ns/pid unshare --mount-proc
[sudo] contraseña para sergio: 
❯ ps
  PID TTY          TIME CMD
 1508 pts/6    00:00:00 bash
 1612 pts/6    00:00:00 ps
❯ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
sergio         1  0.0  0.0  14932  7168 ?        Ss   jul25   0:00 sudo /usr/sbin/sshd -D
sergio         2  0.0  0.0  14084  7936 ?        S    jul25   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root        1508  0.5  0.0 231260  6528 pts/6    S    19:00   0:00 -bash
root        1641  0.0  0.0 230836  3968 pts/6    R+   19:00   0:00 ps aux

Ejemplo 5: Crear namespaces no privilegiados con un poco de ayuda

Por último, veamos como usar la herramienta rootlesskit para crear fácilmente namespaces rootless:

❯ rootlesskit bash
❯ id
uid=0(root) gid=0(root) grupos=0(root),65534(nobody)
❯ exit
❯ rootlesskit --copy-up=/etc bash  
❯ touch /etc/sample
❯ ls -l /etc/sample
-rw-r--r-- 1 root root 0 jul 26 12:12 /etc/sample
❯ exit
❯ ls -l /etc/sample
ls: no se puede acceder a '/etc/sample': No existe el fichero o el directorio

Conclusión

En este post, hemos visto que los namespaces sirven para aislar recursos con diferentes propósitos y que herramientas como unshare y nsenter son muy útiles para entender cómo funciona una aplicación instalada con Flatpak, pero también un contenedor podman o similar, lo cual facilita la resolución de problemas. Algunas actividades que propongo para continuar ejercitando este tema son:

Instalar aplicaciones de Flatpak y observar qué sucede cuando más de un proceso está involucrado.
Examinar qué ocurre con las tablas de ruteo, las listas de iptables o nftables, etc., en un nuevo namespace de red.
Crear un namespace de usuario y explorar cómo este afecta la ejecución de comandos y procesos.

¡Hasta la próxima!

Fuentes y Recursos

¿Qué es flatpak?

sebelk — Sat, 22 Jun 2024 20:11:07 GMT

Es conveniente y merecido que Flatpak tenga un post especialmente dedicado a él, más allá de su interacción con polkit que dejamos planteado en el post anterior.

Brevísimo repaso histórico

En agosto de 2007 el desarrollador sueco Alexander Larsson lanza su primer intento de empaquetar aplicaciones con todas sus dependencias. A fines de 2014 comienza a trabajar en el proyecto xdg-app, el cual cambia de nombre a Flatpak en 2016.

¿Qué es Flatpak?

Flatpak es un sistema para compilar, distribuir y ejecutar aplicaciones. Las aplicaciones se pueden compilar y distribuir independientemente del sistema en que se usan, y al ejecutarse están aisladas del mismo hasta cierto punto.

Cada aplicación está en un sandbox, de manera predeterminada solamente puede acceder al contenido del mismo. Cada programa en flatpak tiene acceso a

~/.var/app/$FLATPAK_ID, y $XDG_RUNTIME_DIR/app/$FLATPAK_ID.
De manera limitada a llamadas del sistema.
De manera limitada a la instancia de D-BUS.

Aun así, para ser realistas, las aplicaciones en general necesitan más permisos, en este caso se insta a los empaquetadores a que adviertan qué accesos necesitará la aplicación para que el usuario esté conciente de ello, tal como cuando se instala una app desde el Play Store de Android.

Flatpak ofrece un repositorio llamado Flathub. Nada impide que cualquier persona o proyecto (como es el caso de Fedora) tenga el suyo propio.

Flatpak usa OSTree (Fedora usa OCI) para distribuir y desplegar datos. OSTree es similar a Git pero está diseñado para hacer control de versiones de binarios y archivos grandes de datos. El uso de OSTree permite además que un mismo archivo sea usado por más de una misma aplicación, ahorrando de esta manera espacio en disco. Cada aplicación que se instala es almacenada en un repositorio local de control de versiones, y luego se mapea en el sistema de archivos local.

Los cambios entre las diferentes versiones de una aplicación se aplican en el filesystem mediante enlaces duros.

Por ejemplo, con el comando siguiente podemos ver log del último commit de una aplicación flatpak (Logseq): .

❯ ostree log --repo=/var/lib/flatpak/repo  deploy/app/com.logseq.Logseq/x86_64/stable
commit a54ee70b0ec9047c2083f77b9f9175e8e8edcac998e3be8d395009255a6a03f6
Parent:  8c36feebe7ea23654917f542eb5419b71426359a42165f53496c9d82049a6806
ContentChecksum:  4d06f4e875d0335f2ff1c7a30ffa5b200c9a3eb3aeb0b608588eadb045994b22
Date:  2024-06-09 07:22:27 +0000

    Remove screenshot locale (8a160109)

    Name: com.logseq.Logseq
    Arch: x86_64
    Branch: stable
    Built with: Flatpak 1.14.8

<< History beyond this commit not fetched >>

En realidad el comando mostrado es de bajo nivel solamente a los efectos de mostrar ostree como software subyacente, para obtener información a más alto nivel, es conveniente usar directamente el comando flatpak para obtener información de la aplicación:

> flatpak info com.logseq.Logseq 

Logseq - Connect your notes and knowledge

                 ID: com.logseq.Logseq
         Referencia: app/com.logseq.Logseq/x86_64/stable
       Arquitectura: x86_64
               Rama: stable
            Versión: 0.10.9
           Licencia: AGPL-3.0-or-later
             Origen: flathub
          Colección: org.flathub.Stable
        Instalación: system
          Instalada: 437,7 MB
Tiempo de ejecución: org.freedesktop.Platform/x86_64/23.08
                Sdk: org.freedesktop.Sdk/x86_64/23.08

             Commit: a54ee70b0ec9047c2083f77b9f9175e8e8edcac998e3be8d395009255a6a03f6
              Padre: 8c36feebe7ea23654917f542eb5419b71426359a42165f53496c9d82049a6806
             Asunto: Remove screenshot locale (8a160109)
              Fecha: 2024-06-09 07:22:27 +0000

Comparación entre dnf, apt y flatpak

Flatpak está pensado para todo tipo de aplicaciones de escritorio y se esfuerza por ser tan neutral como sea posible en cuanto a los métodos que usa para compilar aplicaciones.

Además, flatpak proporciona actualizaciones atómicas, rollback y consistencia post-instalación.

El siguiente cuadro nos ayuda a ver las diferencias con los dos gestores populares de paquetes: dnf y apt.

Característica	DNF	APT	Flatpak
Distribución Principal	Fedora, RHEL, CentOS	Debian, Ubuntu	Varias distribuciones de Linux
Formato de Paquete	RPM	DEB	OSTree, Flatpak Bundle
Gestión de Dependencias	Manejo automático de dependencias	Manejo automático de dependencias	Manejo dentro del sandbox
Aislamiento	No	No	Sí, aplicaciones ejecutadas en sandbox
Instalación de Aplicaciones	Desde repositorios específicos del sistema	Desde repositorios específicos del sistema	Desde repositorios centralizados (Flathub) y repositorios personalizados
Actualizaciones	`dnf update`	`apt update && apt upgrade`	`flatpak update`
Permisos de Instalación	Requiere permisos de root	Requiere permisos de root	Puede instalarse sin permisos de root
Compatibilidad entre Distros	Limitada a sistemas basados en RPM	Limitada a sistemas basados en DEB	Compatible con múltiples distribuciones
Seguridad	Depende de la configuración del sistema	Depende de la configuración del sistema	Sandboxing y permisos controlados por portales
Facilidad de Uso	Interfaz de línea de comandos	Interfaz de línea de comandos	Interfaz de línea de comandos y GUI
Espacio de Disco	Compartido entre aplicaciones	Compartido entre aplicaciones	Deduplicación y compartición de runtimes
Formato de Archivo Individual	No aplica	No aplica	Flatpak Bundle (`.flatpak`)
Desventajas	Depende de la política de la distro	Dependencia de la política de la distro	Las aplicaciones pueden tener un mayor tamaño inicial
Compatibilidad con Aplicaciones Antiguas	Sí, con soporte de versiones específicas	Sí, con soporte de versiones específicas	Generalmente más adecuado para nuevas aplicaciones
Desarrollo y Mantenimiento	Desarrollado por el proyecto Fedora	Desarrollado por el proyecto Debian	Desarrollado por el proyecto Flatpak, con apoyo de Red Hat y GNOME
Adopción	Usado por muchas distribuciones y entornos de escritorio	Usado principalmente en Debian, Ubuntu y derivadas	Usado en diversas distribuciones, especialmente para aplicaciones portátiles
Ejemplo de Comando de Instalación	`dnf install gedit`	`apt install gedit`	`flatpak install flathub org.gnome.Gedit`

Inconvenientes para usuarios y desarrolladores de aplicaciones Linux

Si bien Linux mejoró significativamente en cuando a usabilidad y experiencia de usuario en los últimos años, hay obstáculos tanto para usuarios como para desarrolladores:

Una aplicación para un entorno de escritorio en Linux se debe empaquetar para que esté disponible (como Debian, Fedora, Ubuntu, Arch Linux, etc.), y asegurarse de que cumpla con los requisitos específicos de cada sistema de paquetes (deb, rpm, etc.). Esto requiere un esfuerzo considerable para mantener múltiples versiones y asegurarse de que cada paquete funcione correctamente en su respectiva distribución. Todo esto demanda o más tiempo o bien más gente idónea dedicada en la tarea de crear y mantener paquetes.
Si un usuario quiere usar aplicación que no está empaquetada en la distribución, tendrá que realizar algún paso extra, que van desde operaciones relativamente sencillas como bajar un ejecutable (darle permisos, ubicarlo en un directorio del PATH, etc.), hasta procedimientos bastante más complejos y fuera del interés y conocimiento de un usuario final como puede ser compilar el programa.
Una distribución de soporte a largo plazo como Debian Stable no posee versiones actualizadas de la mayoría de las aplicaciones. Por lo tanto un usuario tiene que elegir estabilidad a cambio de software un tanto anticuado.

Flatpak tiene como propósito justamente eliminar esas barreras. Gracias a Flatpak un usuario podrá instalar una aplicación como Logseq aun cuando no esté incluida en los repositorios de su distribución, o instalar una versión reciente de Kdenlive en Debian Stable.

En la actualidad existen distribuciones con la mirada puesta en la innovación que se benefician de Flatpak, por ejemplo:

Características de flatpak

Analicemos la app ONLYOFFICE en flatpak:

flatpak info org.onlyoffice.desktopeditors

ONLYOFFICE Desktop Editors - Office productivity suite

                 ID: org.onlyoffice.desktopeditors
         Referencia: app/org.onlyoffice.desktopeditors/x86_64/stable
       Arquitectura: x86_64
               Rama: stable
            Versión: 8.0.1
           Licencia: AGPL-3.0-only
             Origen: flathub
          Colección: org.flathub.Stable
        Instalación: system
          Instalada: 863,8 MB
Tiempo de ejecución: org.freedesktop.Platform/x86_64/23.08
                Sdk: org.freedesktop.Sdk/x86_64/23.08

             Commit: c9f73db43c9639df65e597108eb4c685025fe484fde05f73f650d05f9ea28512
              Padre: a38db7bbfaa18eda6d26e9d113ce850c077bf533d9ebf5aa7e34988a58b91b28
             Asunto: Update version to 8.0.1 (#117) (a88ad400)
              Fecha: 2024-03-04 15:34:56 +0000

La aplicación ONLYOFFICE usa como runtime org.freedesktop.Platform/x86_64/23.08. El runtime org.freedesktop.Platform/x86_64/23.08 es un entorno estandarizado y versionado que provee FreeDesktop.org para ejecutar aplicaciones de escritorio en Linux. Incluye una colección de librerías y servicios comunes, que aseguran la compatibilidad y la estabilidad entre las diferentes distribuciones de Linux. Este runtime está compilado específicamente para arquitecturas de 64-bit y fue actualizado o liberado en agosto de 2023.

Los runtimes no dependen ni de una distribución ni de una versión en particular de una distribución. Y una aplicación instalada en flatpak será exactamente igual no importa si se instala en Debian o en Fedora. Una aplicación como GIMP, empaquetada como Flatpak, debería proporcionar la misma funcionalidad principal y experiencia de usuario tanto en Debian como en Fedora, dado que todas las dependencias y configuraciones críticas se gestionan dentro del contenedor Flatpak. Desde luego, hay diferencias potenciales: Si una aplicación Flatpak utiliza características específicas del sistema, como integraciones con servicios de notificación de escritorio, la forma en que estas integraciones funcionan puede variar ligeramente entre GNOME en Fedora y KDE en Debian.

Objeciones en cuanto a la seguridad

Han existido críticas severas a la seguridad de flatpak, en especial por el sitio anónimo Flatkill. El siguiente cuaddro es un resumen de los argumentos en contra y favor de Flatpak en cuanto a este tema:

Objeción de Seguridad	Descripción	Respuesta / Acción Tomada
Sandboxing Ineficaz	Muchas aplicaciones en Flathub tienen permisos amplios como `filesystem=host` o `filesystem=home`, lo que permite acceso completo al sistema de archivos del usuario.	Flatpak ha mejorado la transparencia sobre los permisos de las aplicaciones y trabaja en fortalecer el modelo de sandboxing. Se han introducido portales para permitir el acceso controlado a los recursos del sistema. Flatpak Documentation
Actualizaciones de Seguridad Retrasadas	Algunas aplicaciones y runtimes en Flatpak no reciben actualizaciones de seguridad oportunas, lo que deja a los usuarios expuestos a vulnerabilidades conocidas.	La herramienta flatpak-external-data-checker automatiza la verificación de fuentes externas y la generación de solicitudes de fusión cuando se encuentran actualizaciones. Al implementar f-e-d-c, los desarrolladores pueden asegurar que las aplicaciones en Flathub se mantengan actualizadas más fácilmente y de manera más eficiente, lo que reduce el tiempo de espera para las actualizaciones de los usuarios finales
Integración Limitada del Escritorio	Problemas con la integración de aplicaciones Flatpak en escritorios Linux, como la falta de soporte para configuraciones de fuentes y temas de escritorio.	Se han mejorado los mecanismos de integración de escritorio, incluyendo mejor soporte para fuentes y temas en KDE y GNOME. Flatpak sigue trabajando en mejorar la compatibilidad con configuraciones del sistema host.)
Explotación Local de Root	Riesgo de explotación de root local debido a aplicaciones Flatpak instaladas con permisos suid.	Flatpak utiliza nuevas APIs de libostree para rechazar cualquier archivo con permisos suid o de escritura mundial al instalar aplicaciones.
Gestión de Permisos Confusa para el Usuario	Los usuarios pueden ser engañados por íconos y descripciones que indican un falso sentido de seguridad sobre las aplicaciones sandboxed.	Flatpak ha mejorado la interfaz de usuario para mostrar de manera más clara los permisos que solicita cada aplicación, ayudando a los usuarios a tomar decisiones informadas sobre las aplicaciones que instalan.

¿Cómo hace flatpak para no pedirle a un usuario de un grupo administrativo que se autentique nuevamente?

En el post anterior vimos como funciona polkit. Flatpak se vale de polkit para facilitar la instalación de paquetes por parte de usuarios con permisos administrativos. Basta con mirar el archivo /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules.

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.Flatpak.app-install" ||
         action.id == "org.freedesktop.Flatpak.runtime-install"||
         action.id == "org.freedesktop.Flatpak.app-uninstall" ||
         action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
         action.id == "org.freedesktop.Flatpak.modify-repo") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }

    return polkit.Result.NOT_HANDLED;
});

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
            return polkit.Result.AUTH_ADMIN;
    }

    return polkit.Result.NOT_HANDLED;
});

Este archivo tiene dos reglas:

Permite a los usuarios del grupo "wheel", que están loogoueados localmente y tienen una sesión activa instalar, desinstalar, y modificar aplicaciones y repositorios sin autenticación adicional.
No se pueden pasar por arriba de los controles parentales sin autenticarse con una cuenta de usuario administrativa.

Para ambos casos, si las condiciones no se cumplen, el resultado dependerá de otras reglas o de la regla predeterminada.

Para terminar...

Flatpak elimina barreras y obstáculos tanto para desarrolladores como para usuarios finales. Para los primeros, significa les ofrece la posibilidad de poner aplicaciones disposición de cualquier distribución de Linux. Para los segundos representa una mayor facilidad para obtener los programas que están necesitando.

Fuentes y Más Recursos

Entendiendo Polkit

sebelk — Sat, 15 Jun 2024 18:56:09 GMT

Introducción

El esquema de permisos en Linux es simple:

Un superusuario con todos los poderes para leer, modificar y ejecutar todo.
El resto de los usuarios con permisos limitados.
Es decir, la clasificación de usuarios en tres categorías, el famoso UGO (User, Group, Others) y el trío de permisos: rwx (read, write y execution).

Pero esa simpleza tiene sus limitaciones, como vimos ya anteriormente, con el paso del tiempo se han ideado maneras de hacer esos permisos más granulares y que superusuario root pueda delegar atribuciones.

Una herramienta muy importante en este sentido es polkit (antiguamente conocido como PolicyKit). En este post vamos a explorar para develar qué es polkit, como funciona, y como se diferencia de sudo. Además, en el próximo post, veremos la relación que tiene con flatpak.

¿Qué es polkit?

Leer más… (quedan 9 minutos de lectura)

¿Qué significa en Linux que todo es archivo?

sebelk — Mon, 13 May 2024 21:14:03 GMT

En un viejo artículo, hay una presentación en la que mencioné una frase bastante habitual en el mundo Unix/Linux: «Todo es archivo». Vamos a explicar qué significa realmente esa frase.

Todo es archivo

En realidad, ese dicho no es del todo correcto. Sin embargo, proviene de lo que hoy tal vez podríamos llamar la filosofía Unix. Probablemente, nadie dijo esa frase de manera literal en los primeros años de esa familia de sistemas operativos. Aun así, ideas de ese estilo estaban en la mente desde los comienzos y en los trabajos de por ejemplo, Bill Joy (pionero de TCP/IP). Linus Torvalds, no estuvo ausente en esta discusión. Y mucho más cerca en el tiempo, Lennart Poettering, retoma esa idea una vez más para defender el trabajo realizado en systemd. Por si no se dieron cuenta dice Poettering la interfaz de cgroups están expuesta en un pseudo-sistema de archivos...

Sin embargo, es más apropiado decir que todo es un descriptor de archivo o que todo puede tener un descriptor de archivo. En Linux un descriptor de archivo es un identificador único de proceso para un archivo u otro recurso de entrada o salida. Por ejemplo, no existe necesariamente un archivo para una interfaz de red. Sin embargo, existen sockets relacionados con ellas.

En el siguiente ejemplo podemos ver los descriptores de archivos para la dirección ip 127.0.0.1 de la interfaz lo.

sudo lsof -n -i@127.0.0.1
COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd   1337 chrony    5u  IPv4   8171      0t0  UDP 127.0.0.1:323 
cupsd     1538   root    7u  IPv4  14727      0t0  TCP 127.0.0.1:ipp (LISTEN)
qemu-syst 1774   qemu   32u  IPv4  19480      0t0  TCP 127.0.0.1:rfb (LISTEN)
syncthing 2620 sergio   19u  IPv4  22825      0t0  TCP 127.0.0.1:8384 (LISTEN)

En este caso, vemos los descriptores de archivos de lectura y escritura 5u, 7u, 32u y 19u.

Para ver la relación entre descriptores y sockets podemos hacer un ping a una determinada dirección ip:

ping -c 10000 9.9.9.9 &> /dev/null

Si buscamos los descriptores de archivos con lsfd, mostrará el siguiente resultado:

lsfd -p 914323 -Q '(FD >= 0)' 
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping    914323 sergio     0 rw-D--    CHR  pts:6    36        9 /dev/pts/6 
ping    914323 sergio     1 -w----    CHR  mem:3    34        4 /dev/null
ping    914323 sergio     2 -w----    CHR  mem:3    34        4 /dev/null
ping    914323 sergio     3 rw---m   PING sockfs     9 30437500 state=close id=35 laddr=0.0.0.0
ping    914323 sergio     4 rw---- PINGv6 sockfs     9 30437501 socket:[30437501]

Analicemos cada descriptor de archivo:

0: Es la "standard input" que apunta a una pseudoterminal (dispositivo de caracteres), al tratarlo como un archivo tiene permisos: de lectura y escritura. Usa un sistema de archivos y como tal también maneja inodos.
1: Es la "standard output" que apunta a /dev/null. Solamente tiene permisos de escritura, el sistema de archivos proviene de la memoria principal y tiene permisos solamente de escritura.
2: Es el "standard error" que apunta también a /dev/null.
3: Apunta a un socket de tipo IPv4, y tiene permisos de lectura y además está siendo utilizado por un evento de multiplexación.
4: Finalmente tenemos el descriptor de 5 que apunta a un tipo de socket que usa IPv6.

Dentro del directorio /proc podemos ver que los descriptores 1 (salida estándar) y 2 (error estándar) se redirigen al archivo /dev/null, mientras tanto, 3 y 4 apuntan a sockets:

ls -l /proc/914323/fd
total 0
lrwx------ 1 sergio sergio 64 may 19 17:33 0 -> '/dev/pts/6 (deleted)'
l-wx------ 1 sergio sergio 64 may 19 17:33 1 -> /dev/null
l-wx------ 1 sergio sergio 64 may 19 17:33 2 -> /dev/null
lrwx------ 1 sergio sergio 64 may 19 17:33 3 -> 'socket:[30437500]'
lrwx------ 1 sergio sergio 64 may 19 17:33 4 -> 'socket:[30437501]'

Podemos hacer otra prueba, en este caso usaremos solamente ping sobre ipv6 y en lugar de redireccionar a /dev/null, lo haremos redirigiendo stdin y stderr a archivos regulares distintos:

ping6 -c 10000 ::1 > out.txt 2> errors.txt &

Aquí solamente usará un socket (ya que no usa ipv4):

lsfd -p 926928 -Q '(FD >= 0)'
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping6   926928 sergio     0 rw----    CHR  pts:7    36       10 /dev/pts/7
ping6   926928 sergio     1 -w----    REG   0:34    52 38207299 /tmp/out.txt
ping6   926928 sergio     2 -w----    REG   0:34    52 38207300 /tmp/errors.txt
ping6   926928 sergio     3 rw---- PINGv6 sockfs     9 31193485 state=close id=44 laddr=::

¿Qué sucede si se borra /tmp/errors.txt?

lsfd -p 926928 -Q '(FD >= 0)'
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping6   926928 sergio     0 rw----    CHR  pts:7    36       10 /dev/pts/7
ping6   926928 sergio     1 -w----    REG   0:34    52 38207299 /tmp/out.txt
ping6   926928 sergio     2 -w-D--    REG   0:34    52 38207300 /tmp/errors.txt
ping6   926928 sergio     3 rw---- PINGv6 sockfs     9 31193485 state=close id=44 laddr=::

Bueno, veremos que el archivo aparece con el flag D indicando que borró del respectivo sistema de archivos.

Por lo tanto, si bien literalmente no todo es archivo, podemos afirmar que en general podríamos mediante los descriptores de archivos establecer un puente entre un proceso y los recursos a los que está accediendo. En definitiva, un descriptor de archivos, permite al proceso comunicarse con el recurso subyacente de manera eficiente y uniforme, independientemente de si el recurso es un archivo en el sistema de archivos, un dispositivo de hardware o un socket de red.