Linux Sin Humo (Publicaciones sobre seguridad)

Gestión de Contraseñas Usando Contenedores Podman (Update 2025)

sebelk — Mon, 25 Aug 2025 22:27:46 GMT

En 2023, publiqué un post sobre cómo usar pass con un contenedor Git administrado por Podman. Esa guía fue muy útil como demo inicial, pero desde entonces cambiaron algunas cosas: nuevas versiones de Podman, la aparición de Quadlet, la deprecación de podman generate systemd, y la conveniencia de usar imágenes más estables.

Este post es una actualización 2025 del artículo original, incorporando:

Imagen base UBI9 minimal (más liviana y con soporte extendido). Esta imagen, desarrollada por Red Hat, es de tamaño relativamente pequeño, usa una versión reduccida de dnf, llamada microdnf con soporte de módulos y usa software de repositorios - también - de Red Hat.
Rootless limpio con UserNS=keep-id.
Quadlet para integrar con systemd --user.
Volúmenes persistentes para no perder datos ni claves al actualizar la imagen.
Endurecimiento SSH (solo claves públicas, nada de contraseñas).

1. Construcción de la imagen

Dockerfile (Dockerfile):

FROM registry.access.redhat.com/ubi9/ubi-minimal

RUN microdnf -y install openssh-server git shadow-utils \
    && microdnf clean all \
    && useradd -ms /bin/bash git \
    && chsh -s /usr/bin/git-shell git

EXPOSE 2222
CMD ["/usr/sbin/sshd", "-D", "-e"]

Construcción:

podman build -t localhost/passteiner-ubi9:1 .

2. Crear volúmenes persistentes

podman volume create git-home
podman volume create ssh-etc

VHOME=$(podman volume inspect -f '{{.Mountpoint}}' git-home)
mkdir -p "$VHOME/.ssh" "$VHOME/.password-store"
cp ~/.ssh/id_ed25519.pub "$VHOME/.ssh/authorized_keys"
chmod 700 "$VHOME/.ssh"
chmod 600 "$VHOME/.ssh/authorized_keys"

Repositorio bare:

podman unshare chown -R 1000:1000 "$VHOME"
podman run --rm -v git-home:/home/git localhost/passteiner-ubi9:1 \
  git init --bare /home/git/.password-store

3. Quadlet (systemd integration)

Archivo ~/.config/containers/systemd/pass_git.container:

[Unit]
Description=pass git over SSH (podman quadlet)
Wants=network-online.target
After=network-online.target

[Container]
Image=containers-storage:localhost/passteiner-ubi9:1
Pull=never

ContainerName=pass_git
Network=pasta
PublishPort=60003:2222

Volume=git-home:/home/git:Z,U
Volume=ssh-etc:/etc/ssh:Z

UserNS=keep-id
LogDriver=journald
Exec=/usr/sbin/sshd -D -e -p 2222 -o PidFile=/tmp/sshd.pid

[Service]
Restart=on-failure

[Install]
WantedBy=default.target

Activación:

systemctl --user daemon-reload
systemctl --user enable --now pass_git.service

4. Probar conexión SSH

ssh -p 60003 git@<IP_DEL_HOST> \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  'git --version && echo OK'

Debe autenticar con tu clave pública y responder git version ....

5. Probar pass con git

Inicializar pass en tu host y configurar el remoto:

export PASSWORD_STORE_DIR=~/.local/share/pass
pass init "tu_clave_gpg"
cd "$PASSWORD_STORE_DIR"
git remote add origin ssh://git@<IP_DEL_HOST>:60003/home/git/.password-store
git push origin master

Y luego:

pass git push
pass git pull

Diferencias clave respecto al artículo original

Imagen: antes Fedora, ahora UBI9 minimal (más estable, soporte hasta 2032).
Systemd: antes podman generate systemd, ahora Quadlet (futuro estándar, más limpio).
Rootless: antes root dentro del contenedor, ahora UserNS=keep-id.
Volúmenes: ahora explícitos (git-home, ssh-etc), evitando pérdidas de datos.
Seguridad SSH: solo claves, sin password, PidFile movido a /tmp.

Conclusión

Este enfoque actualizado:

Evita perder el repositorio y las claves al recrear el contenedor.
Asegura compatibilidad a futuro con Podman + systemd.
Se apoya en una base más segura (UBI9 minimal).

👉 Si ya usás el setup original, podés migrar en pocas horas y quedarte tranquilo de que tu gestor de contraseñas pass seguirá funcionando a largo plazo.

3 Power Tips + 1 Power Link I1

sebelk — Tue, 17 Jun 2025 19:25:26 GMT

Power Tip #1

El comando cd - sirve para ir rápidamente al directorio anterior

cd /usr/local/bin
cd /tmp
cd -
pwd
/usr/local/bin

Power Tip #2

La variable HISTTIMEFORMAT agrega una marca de tiempo en el hi:storial de bash

Agegar en ~/.bashrc

HISTTIMEFORMAT="%F %T"

También se puede usar bash-it para realizar la configuración.

Al recargar la configuración, se agregará la marca de tiempo:

234475  2025-06-03 21:54:27 vim  ~/Documentos/Arts/nikola-env/sebelkfloss/files/assets/css/custom.css 
234476  2025-06-02 08:18:37 vim  ~/.config/nvim/lua/core/lazy.lua 
234477  2025-06-04 18:27:09 nohup nikola serve &> /dev/null &
234478  2025-06-04 18:29:38 vim  ~/.config/nvim/lua/core/lazy.lua 
234479  2025-06-04 18:29:57 loadnikola

Power Tip #3

Usar una herramienta de monitoreo local como wallpaper

El emulador de terminal kitty posee herramientas pequeñas que amplian su funcionalidad. Una de ellas permite mostrar usar la terminal como wallpaper:

Este comando mostrará el panel de la herramienta glances en un entorno Wayland

kitty +kitten panel --edge=background --focus-policy exclusive --detach  glances

Power Link

Sencillamente un link: Stop disabling SELinux

¡Hasta la próxima!

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é 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)

Gestión de Contraseñas Usando Contenedores Podman

sebelk — Tue, 29 Aug 2023 22:06:14 GMT

Podemos administrar nuestros datos personales también con estándares profesionales. En este contexto, vamos a explorar cómo llevar la gestión de contraseñas usando utilizando herramientas viejas y confiables como pass, gpg, git combinada con la potente solución de contenedores Podman. Será una experiencia desafiante.

Almacenamiento de Contraseñas Elevado

Para gestionar nuestras passwords usaremos pass. La herramienta pass no estra cosa que un potente script de bash de algo más de 720 líneas de wrapper principalemente para gpg y git.

Ahora, lo realmente interesante: configuraremos un repositorio dentro de un contenedor Podman. Este repositorio, administrado con git, puede ser compartido de manera segura y efectiva en todos tus dispositivos.

Acceso Simplificado desde Cualquier Lugar

La accesibilidad es clave en tu entorno profesional. Ya sea trabajando en sistemas Windows o Linux, puedes aprovechar QtPass, una interfaz gráfica para pass. Para usuarios de iPhone, passforios es una excelente opción, mientras que los dispositivos Android pueden beneficiarse de Password-Store, disponible en Google Play Store y F-Droid para mantener tus contraseñas siempre sincronizadas.

Características Clave para Profesionales

Control Total: Somos nosotros quienes gestionan nuestros repositorios. Los datos sensibles están en tus dispositivos, evitando intermediarios y asegurando la confidencialidad.
Portabilidad Sin Esfuerzo: Se puede cambiar de dispositivos o realiza copias de seguridad con facilidad. Tu repositorio te seguirá sin problemas.
Seguridad de Alto Nivel: tus credenciales seguras con estándares de confiabilidad, integridad y disponibilidad.
Compartir con Confianza: Podrás compartirlo fácilmente en círculos de confianza.

Configuración Inicial y Uso Avanzado

En esta primera fase, te guiaremos a través de la configuración de tu repositorio en un contenedor Podman y las opciones para interactuar con él desde distintos dispositivos.

Nota 1:

El enfoque primordial es establecer un almacén personal de contraseñas. Además de utilizarlo en tus dispositivos, podrás extender su uso a usuarios de confianza. Aunque podría requerirse alguna asistencia técnica inicial para la configuración, las acciones esenciales son "actualizar desde el repositorio (pull)" y "enviar cambios al repositorio (push)".

Esta idea es adaptable a ambientes profesionales con para grupos reducidos de usuarios en una red corporativa, donde cada miembro tiene su copia del repositorio principal. El repositorio podría estar incluso en algún contenedor que esté disponible 24x7. Esto facilita la consulta, creación, modificación y eliminación colaborativa de contraseñas, consolidando luego los cambios en un repositorio compartido.

Nota 2:

Para aprovechar plenamente esta guía, asumimos que poseés conocimientos de:

Gestión de claves públicas ssh
Gestión de claves gpg
Uso básico de git
Uso básico de Podman
Conocimientos generales de Linux: bash, systemd, firewalld (iptables/nftables), etc.

¿Qué usaremos para lograr todo esto?

OS: Fedora 38
podman
pass

Se podría usar otra distribución, sin embargo es importante que cuente con una versión relativamente reciente de podman.

¿Por qué usamos podman? Porque tiene una gran similitud con docker, y además, posee la capacidad de correr contenedores de manera mucho más segura y sencilla. En este caso particular, crearemos un contenedor que alojará el repositorio compartido de passwords.

No será necesario crear servicios web y/o de bases de datos.

Instalación de paquetes

dnf install -y git pass

Inicialización de repositorio de passwords

En este ejemplo le pasamos los identificadores de las clave públicas gpg en el siguiente usamos 3 direcciones de mail correspondientes a la clave del host, la del celular y la de otra persona respectivamente.

pass init jkm@example.com fxi@example.com pyn@example.net

pass git init

pass generate puertablanca

Preparación del container

Creamos el siguiente Dockerfile

FROM fedora:38
RUN dnf update -y && dnf install -y git openssh-server
RUN useradd -ms /bin/bash git
RUN mkdir /home/git/.ssh
RUN ssh-keygen -A
COPY  ssh-pks /home/git/.ssh/authorized_keys
RUN echo "git ALL=(ALL:ALL) NOPASSWD: /usr/sbin/sshd" >> /etc/sudoers && git clone --bare /mnt/.password-store /home/git/.password-store && chown -R git:git /home/git  && chmod 700 /home/git/.ssh && chmod 600 /home/git/.ssh/authorized_keys
EXPOSE 22
CMD ["sudo","/usr/sbin/sshd", "-D"]

Esto nos permitirá crear un repositorio con las siguientes características:

Basado en Fedora 38
Un usuario llamado git que tendrá el único privilegio de correr el servicio ssh
Obtendrá una copia del repositorio git antes creado con pass

Crear la imagen de podman

podman build -v /home/sergio/.password-store:/mnt/.password-store -t passteiner .

Crear el container

podman run -d --name container-pass_git --user git -p 60003:22 passteiner

En este punto, ya estamos en condiciones de crear, editar, modificar nuestras passwords y subirlas al repo del contenedor de manera que esté disponible para otros dispostivos y/o usuarios.

Cabe aclarar que para usar Password Store en Android hace falta instalar OpenKeychain. Esa aplicación nos permitirá crear un el par de clave privada + clave pública GnuPG, como así también importar la clave pública del resto de los usuarios con quien compartiremos el llavero. Tener en cuenta que es muy importante la passphrase que usemos para cifrar nuestra clave privada: debe ser fácil de memorizar y a la vez robusta. Esa misma passphrase se nos pedirá cuando necesitamos acceder a las contraseñas:

Y luego con Password Store tendremos que:

Ingresar los parámetros de repositorio que está en el contenedor que hemos creado, tanto la url (por ejemplo ssh://git@10.0.0.10:60003/git/,password-store) y la branch (master).
Generar la clave pública ssh para autenticarse al repositorio. Esta clave tendrá que copiarse al archivo /home/git/.ssh/authorized_keys del contenedor.

podman exec container-pass_git bash -c 'echo "clave_publica_ssh" /home/git/.ssh/authorized_keys'

(Si queremos que este archivo sea persistente, podríamos modiicar el Dockerfile para que use un volumen).

Clonar el repositorio del contenedor.

Una vez que hemos clonado el repositorio, obtendremos el listado de passwords y el menú para operar con él:

Actualizando nuestro repositorio

Hay varias configuraciones posibles, pero la que recomiendo es la siguiente:

pass git config pull.rebase false

Para bajar las actualizaciones del contenedor:

pass git pull

Para subir las propias modificaciones al contenedor:

pass git push

Comentario finales

Al finalizar habrás conseguido que:

El contenedor se ejecuta como un usuario sin privilegios dentro del sistema.
Todo - excepto el proceso sshd - se ejecutará como un usuario sin privilegios aun dentro del container. Salvo que explícitamente uses algo como docker run --user root..... . Pero ¿por qué lo harías?
Por fuera del contenedor en realidad, mapea a nuestro propio usuario.

Enlaces útiles

Tutorial de fscrypt para cifrar archivos

sebelk — Sat, 24 Apr 2021 13:30:29 GMT

Conocimientos previos necesarios:

Instalación de Linux.
Uso habitual de línea de comandos en Linux (incluyendo entre otros manejo de propietarios y permisos).
Instalación y desinstalación de paquetes.
Montaje de sistemas de archivos.

El sistema ext4 proporciona cifrado de bloques de datos y nombres de archivos. Veremos a continuación de algunas reglas generales para cifrar el directorio /home de un usuario.

En el ejemplo en cuestión estoy usando Debian Buster (te recomiendo primero instalarla en una máquina virtual para hacer pruebas), de modo que los pasos a seguir pueden ser un poco diferentes en otras distribuciones, pero los principios generales se mantienen.

¡Manos a la obra!

Los comandos precedidos por sudo indican que necesitan privilegios de root. Si querés usar sudo, sencillamente ejecutá como root:

usermod -aG sudo sergio

Obviamente aquí y en cada caso reemplazalo con tu usuario común.

Preparación del sistema de archivos

Algo que tendremos que hacer es habilitar la funcionalidad de cifrado, suponiendo que la partición de cifrado es /dev/sda1, haríamos:

sudo tune2fs -O encrypt /dev/sda1

Descarga y compilación

sudo apt update && sudo apt build-dep fscrypt

do apt -y install git && go get -d github.com/google/fscrypt/...

cd go/src/github.com/google/fscrypt/

make && sudo make install PREFIX=/usr

Configuración

Tenemos que actualizar la configuración de PAM, que servirán para desbloquear directorios al loguearse, bloquear al desloguearse, y cambiar contraseñas de acceso a los recursos cifrados.

sudo pam-auth-update

Para configurar globalmente:

sudo fscrypt setup

No se puede cifrar un directorio que ya tiene contenido, de manera que hay que crear un nuevo directorio, y luego migrar el contenido del directorio del usuario:

sudo mkdir /home/sergio_temp && sudo chown sergio.sergio /home/sergio_temp

fscrypt encrypt /home/sergio_temp

Allí podríamos elegir entre la contraseña del usuario, una passphrase o bien un archivo con clave 256-bit. En nuestro elegimos la primera opción, siempre teniendo en cuenta lo importante que es contar con una buena contraseña.

Luego chequeamos que esté todo en orden:

fscrypt status /home/sergio_temp

Ahora sí, migramos el contenido:

cp -av -T /home/sergio /home/sergio_temp

Bloqueamos el contenido del directorio

sudo fscrypt lock /home/sergio_temp --user=/home/sergio_temp

Probamos desbloquear

fscrypt unlock /home/sergio_temp

Si funciona podemos reemplazarlo por el nuevo directorio:

sudo su - mv /home/sergio{,_para-borrar}

mv /home/sergio{_temp,}

Luego al reiniciar podemos probar:

reboot

¿Cómo se ven los archivos cifrados?

Más Recursos

Diagrama de netfilter/iptables

sebelk — Thu, 26 Sep 2019 18:11:49 GMT

Claves

Las reglas se organizan en tablas: raw, mangle, nat, filter.
Las tablas tienen cadenas, filter, por ejemplo tiene INPUT, OUTPUT y FORWARD. Y como se puede apreciar las decisiones de routing implican que INPUT y FORWARD son excluyentes. Lo mismo que OUTPUT y FORWARD.
El orden siempre es raw, mangle, nat, filter (si es que están presentes).
Hay 3 lugares en que se decide el ruteo, uno de los cuales es local.
Solamente se filtra en filter, obviamente.

Más?

Iptables Tutorial 1.2.2

Defendiendo la disponibilidad de un servicio con iptables

sebelk — Fri, 08 Jan 2016 11:06:17 GMT

La famosa sigla CID define el trípode en el cual se sustenta la seguridad informática: Confidencialidad, Integridad, Disposnibilidad.

Es decir, al interrumpir la disponibilidad de un servicio se quiebra la seguridad de uno o más servicios.

El famoso ataque de denegación de servicio puede colgar aplicaciones de un servidor o inundarlos de tráfico afectando seriamente el rendimiento. Muchas veces ese tipo de ataque proviene de direcciones IP falsificadas y desde más de un origen. Existen variantes de este tipo de agresiones que pueden incluso aprovechar vulnerabilidades de los dispositivos víctima, de manera tal que los atacantes pueden por ejemplo hacer reemplazar el firmware original por otro malicioso.

El módulo xt_recent

Como vimos, bloquear o limitar el tráfico de una lista estática de direcciones IP no es conveniente. Exige en cambio adoptar una defensa dinámica y proactiva.

El módulo de iptables xt_recent es una de las opciones a las que podemos recurrir en estos casos. Fue creado por Stephen Frost en 2003^{^1} y lo mantiene actualmente el equipo de iptables.^{^2}

El presente artículo intenta mostrar de manera sencilla y clara el funcionamiento del módulo, no es un curso de iptables ni una receta para diseñar una política de firewall. El propósito es mostrar como el propio kernel posee instrumentos para defenderse contra un (D)DOS.

Como funciona y usos

El modulo xt_recent o más comúnmente conocido recent crea una conjunto de direcciones IPs de acuerdo a ciertos criterios que queramos establecer. Por ejemplo podríamos crear un regla que coincida con paquetes de tipo icmp pertenecientes a conexiones nuevas.

Es cierto, tal vez no podamos hablar estrictamente de conexiones nuevas para este tipo de protocolo. Pero recordemos que iptables es un firewall de estado es decir, no solamente analiza y/o filtra paquetes de manera aislada. Sino que además puede examinar su historial: saber si un paquete pertenece a una conexión nueva (NEW), establecida (ESTABLISHED), relacionada (RELATED) o no válida (INVALID).

Por ejemplo al realizar un echo-request con ping y recibir desde el otro host un echo-reply, iptables, o mejor dicho, netfilter considera que se estableció una conexión.

Si queremos contrarrestar un icmp-flood de manera efectiva lo correcto es limitar las paquetes nuevos.

Reglas sencillas para probarlo

Las siguientes reglas permiten aplicar un límite de un paquete nuevo icmp por minuto (es un ejemplo extremo, pero útil para explicar el funcionamiento del módulo)

iptables -A INPUT -p icmp -m state –state NEW -m recent –update –seconds 60 –hitcount 1 –name icmpflood -j DROP
iptables -A INPUT -p icmp -m state –state NEW -m recent –set –name icmpflood

Como siempre es importante el orden de las reglas, podríamos invertirlas pero en la documentación de primera mano^1 está en ese orden (y las cosas cambiarían, podés probarlo vos el resultado).

Pero veamos las cosas tal como están. Supongamos que no han llegado paquetes nuevos icmp: Al arribar uno, no coincidirá con la primer regla. Explicaremos la razón:

El parámetro –seconds– indica el intervalo de tiempo que examinaremos, mientras que –hitcount evalúa la cantidad de paquetes de este tipo desde la misma dirección. Es importante entender que esta regla no incrementa el contador. Solamente examina cantidad de paquetes por unidad de tiempo. Como hasta ahora el contador está en 0, el paquete podrá ingresar (asumimos que la política predeterminada es ACCEPT, lo cual puede – en principio – ser inseguro, pero nuestro propósito es explicar el funcionamiento de recent, de manera que el lector está advertido). Insistimos: esta regla NO penaliza, es decir no incrementa el contador. ¿Quedó claro?

Vayamos a la segunda regla: esta regla crea un conjunto llamado icmpflood e incrementa el contador para los paquetes que cumplan con los requisitos estipulados, es decir: con protocolo icmp y estado NEW. De manera que al llegar el primer paquete se agrega la dirección IP al set icmpflood y el número de hits es ahora 1.

Recién al llegar el segundo paquete en menos de 60 segundos se habrán cumplidos los requisitos de la primer regla y por lo tanto el paquete será descartado.

Método sencillo para testear las reglas

Lo podemos probar sencillamente con los siguientes comandos desde otro host:

pingwait(){ ping -q -c1 $1 & sleep 31; }
IP=192.168.80.148
pingwait $IP; pingwait $IP; ping -q -c1 192.168.80.148

Es decir lo que hacemos es enviar dos paquetes nuevos icmp cada 31 segundos.

El resultado en el host de destino es:

Every 2,0s: iptables -L INPUT -vn  

Chain INPUT (policy ACCEPT 63 packets, 3612 bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   168 DROP       icmp —  *      *       0.0.0.0/0            0.0.0.0/0            state NEW recent: UPDATE seconds:
 60 hit_count: 1 name: icmpflood side: source mask: 255.255.255.255
    1    84            icmp —  *      *       0.0.0.0/0            0.0.0.0/0            state NEW recent: SET name: icmpflood side: source mask: 255.255.255.255

Explicación amigable de rcheck y update

No explicamos en absoluto el significado de UPDATE (–update) hasta ahora y la diferencia con CHECK (–rcheck). No es sorpresa que la mejor explicación esté en la documentación original. Muchos de los sitios que intentan explicarlo en mi modesta opinión no lo hacen de la manera más clara. Así que trataré de hacerme entender, ya que son dos parámetros claves. Pero antes de hacerlo y sin querer eludir la explicación, mostraré el resultado al cambiar UPDATE por CHECK:

iptables -F && iptables -X && iptables -Z
iptables -A INPUT -p icmp -m state –state NEW -m recent –rcheck –seconds 60 –hitcount 1 –name icmpflood -j DROP
iptables -A INPUT -p icmp -m state –state NEW -m recent –set –name icmpflood

Every 2,0s: iptables -L INPUT -vn                                                                       Thu Jan  7 16:49:41 2016

Chain INPUT (policy ACCEPT 57 packets, 3250 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1    84 DROP       icmp —  *      *       0.0.0.0/0            0.0.0.0/0            state NEW recent: CHECK seconds:
60 hit_count: 1 name: icmpflood side: source mask: 255.255.255.255
    2   168            icmp —  *      *       0.0.0.0/0            0.0.0.0/0            state NEW recent: SET name: icmpf
lood side: source mask: 255.255.255.255

Supongamos que tenés una bolsa con 10 caramelos y un nene te pide que se los des. Aceptás con una condición, solamente podrá comer 2 por hora. Entonces, podrías adoptar dos políticas con el pequeño:

Laxa (–rcheck)

Hora 15:00 Viene el nene por primera vez y te pide 2 caramelos. Le das un caramelo.
Hora 15:15: ¡Regresa el niño en busca de más caramelos! Está ok, le regalás el dulce, pero le decís que es el último durante esa hora.
Hora 15:30: Otra vez el simpático nene te pido caramelos, le explicás que ya comió los dos caramelos que corresponden a esa hora, recién a las 16:00 se lo darás.
Hora 16:00: Ahora sí tal lo prometido le podrás dar 1 o 2 caramelos durante las 16:00 hasta las 16:59.

Rígida (–update)

Hora 15:00 Viene el nene por primera vez y te pide 2 caramelos. Le das un caramelo.
Hora 15:15: ¡Regresa el niño en busca de más caramelos! Está ok, le regalás el dulce, pero le decís que es el último durante esa hora.
Hora 15:30: Otra vez el simpático nene te pido caramelos, le explicás que ya comió los dos caramelos que corresponden a esa hora… Pero que durante una hora a partir de ahora no le podrás dar más caramelos.
Hora 15:45: El chico insiste quiere más caramelos. Como disciplina le decís que por no esperás volvés a extender el tiempo de espera. De manera que tendrá que esperar hasta las 16.45 para recibir otro caramelo.
Hora 16:00 El pobre nene insiste, entonces extendés la penalidad una hora más. Y el nino recién ahí comprende la indicación y espera una hora.
Hora 17:00: Ahora sí tal lo prometido le podrás dar 1 o 2 caramelos durante los siguientes 60 minutos.

Así que esas son las diferencias entre –rcheck, –update, cuanto menos respete el atacante el tiempo estipulado en –seconds peor será le penalidad. En el ejemplo que estuvimos viendo –update significa que el otro host deberá esperar sí o sí 1 minuto entre ping y ping. En cambio –rcheck es más permisivo, por cada nuevo minuto nuevo que comience podrá enviar la cantidad estipulada en –hitcounts que en nuestro ejemplo fue 1 paquete.

Archivos de listas en /proc/net/xt_recent

root@raspberrypi:~#  cat  /proc/net/xt_recent/icmpflood src=192.168.80.250 ttl: 64 last_seen: 29694939 oldest_pkt: 3 29688739, 29691839, 29694939

Hay un archivo por lista (set). Vemos en el archivo /proc/net/xt_recent/icmpflood la dirección de origen del paquete y además la última vez que fue vista usando la unidad de tiempo jiffies.

Parámetros del kernel

Además se le pueden pasar parámetros al módulo

ip_list_tot: Número de direcciones IPs que puede recordar por lista
ip_pkt_list_tot: Número de paquetes que puede recordar por IP (el máximo es 255)

Conclusión

Como vemos si bien existen otros métodos para mitigar un DDOS o DOS, este tiene la ventaja de usar directamente netfilter, sin la necesidad de instalar una herramienta adicional.