https://smcv.pseudorandom.co.

uk/2015/why_polkit/

Porqu polkit (o, cmo montar un disco moderno en Linux)

Recientemente me he encontrado explicando a polkit (antes PolicyKit) a uno de los

clientes de colaboracin, y pens que bloguear sobre el mismo tema podra ser til
para otras personas que estn confundidos por ella; por lo tanto, aqu es por qu
udisks2 y polkit son como son.

Como siempre, las opiniones en este blog son las propias, no las de colaboracin.

Acciones privilegiadas

En trminos generales, hay dos formas en que un proceso puede hacer algo: puede
hacerlo directamente (es decir, preguntar directamente al kernel), o puede utilizar
la comunicacin entre procesos para pedir a un servicio que haga esa operacin en
su nombre. Si lo hace directamente, los componentes que dicen si puede tener xito
son las comprobaciones de permisos normales del kernel de Linux (DAC), y si estn
configurados, AppArmor, SELinux o una capa similar de Mac. Todo muy simple hasta
ahora.

Desafortunadamente, los controles relativamente gruesos del kernel no son

suficientes para expresar el tipo de polticas que existen en un sistema de
escritorio/porttil/mvil. Mi ejemplo favorito para este tipo de cosas es el
montaje de sistemas de archivos. Si enchufo una memoria USB con un sistema de
archivos FAT, es razonable esperar que mi interfaz de usuario elegida lo monte
automticamente o me permita presionar un botn para montarlo. Del mismo modo, para
evitar la prdida de datos, debera ser capaz de desmontarlo cuando haya terminado
con l. Sin embargo, montar y desmontar una memoria USB es fundamentalmente la
misma llamada de sistema que montar y desmontar cualquier otro sistema de archivos
y si los usuarios comunes pueden hacer llamadas de sistema de montaje arbitrarias,
pueden causar todo tipo de caos, por ejemplo montando un sistema de archivos que
contiene setuid Ejecutables (escalamiento de privilegios), o montar un sistema de
archivos OS crtico como /usr (denegacin de servicio). Algo necesita arbitrar:
"puede montar sistemas de archivos, pero slo bajo ciertas condiciones".

El lema del desarrollador del kernel para este tipo de cosas es "mecanismo, no
poltica": estn muy interesados en evitar la codificacin de polticas de entornos
particulares (el tipo de cosas que se podra considerar como "reglas de negocio")
en el ncleo, porque eso hace que sea no genrica y difcil de mantener. Como
resultado, las acciones directas de montaje/desmontaje slo estn permitidas por
procesos privilegiados, y corresponde a los procesos de espacio de usuario
organizar un proceso privilegiado para crear el syscall de montaje deseado.

Estas son algunas otras acciones privilegiadas que los usuarios de computadoras
porttiles / computadoras de escritorio pueden razonablemente esperar que
"funcionen", con o sin necesidad de un usuario similar a un administrador de
sistema (equivalente a root):

* La reconfiguracin de redes (privilegiada porque, en el caso general, es una

cuestin de disponibilidad y potencialmente de integridad)
* Instalar, actualizar o quitar paquetes (privilegiado porque, en el caso
general, puede resultar en la ejecucin de arbitraria de cdigo raz)
* Suspender o cerrar el sistema (privilegiado porque no querras que las
personas al azar lo hicieran en tu servidor, pero normalmente debera estar
permitido en, por ejemplo, computadoras porttiles para personas con acceso fsico,
porque podran simplemente desconectar la alimentacin de todos modos)

En entornos que utilizan un marco MAC como AppArmor, las acciones que normalmente
se permitirn pueden convertirse en privilegiados: por ejemplo, en un marco para
aplicaciones de espacio aislado, la mayora de las aplicaciones no deben permitir
grabar audio. Esto impide llevar a cabo estas acciones directamente, resultando de
nuevo que la nica manera de lograrlas es pedir a un servicio que lleve a cabo la
accin.

Solicite un servicio del sistema para hacerlo

En el siguiente diseo, entonces: puedo enviar una solicitud a un proceso

privilegiado, que hace algunos chequeos para asegurarse de que no estoy tratando de
romper el sistema (o, alternativamente, que tengo suficientes derechos de
administrador que se me permite romper el sistema si quiero), y luego hace la
accin privilegiada para m.

Usted podra pensar que estoy a punto de empezar a discutir D-Bus y demonios, pero
en realidad, una prominente implementacin anterior de esto fue Mount (8), que
normalmente es setuid root:

% ls -l /bin/mount
-rwsr-xr-x 1 root root 40000 May 22 11:37 /bin/mount

Si lo mira desde un ngulo extrao, se trata de comunicacin entre procesos a

travs de un lmite de privilegios: ejecuto el archivo ejecutable setuid, creando
un proceso. Debido a que el ejecutable tiene configurado el bit setuid, el kernel
hace que el proceso sea altamente privilegiado: su UID efectivo es root, y tiene
todas las capacidades necesarias para montar sistemas de ficheros. Presento la
solicitud pasndola en los argumentos de la lnea de comandos. mount hace algunos
chequeos-especficamente, busca en /etc/fstab para ver si el sistema de ficheros
que estoy tratando de montar tiene la bandera "user" o "users" -luego lleva a cabo
la llamada al sistema mount.

Hay algunos problemas obvios con esto:

* Cuando las mquinas tenan un conjunto esttico de dispositivos de hardware (y

un administrador de sistemas que saba cmo configurarlos), podra haber tenido
sentido enumerarlos todos en /etc/fstab; pero esto no es una solucin til si puede
conectar cualquier nmero de unidades USB, o si usted es un usuario no experto con
Linux en su porttil. La decisin debe basarse en los atributos generales de
dispositivos, tales como "es extrable?", y sobre la funcin de la mquina.
* Los ejecutables de setuid son alarmantemente fciles de equivocarse, por lo
que no es necesariamente prudente asumir que mount (8) es seguro para hacer setuid.
* Un hecho que una poltica de seguridad razonable podra incluir es que "los
usuarios que estn conectados de forma remota deben tener menos control sobre los
dispositivos fsicamente presentes que aquellos que estn fsicamente presentes" -
pero este tipo de cosas no pueden ser verificadas por mount (8) sin especficamente
ensear el binario de montaje sobre ella.

Pida un servicio del sistema que lo haga, va D-Bus u otro IPC

Para evitar los problemas de setuid, podramos usar la comunicacin interprocesos

en el sentido tradicional: ejecutar un daemon privilegiado (en el arranque o bajo
demanda), hacer que escuche peticiones y utilizar el canal IPC como nuestro lmite
de privilegios.

udisks2 es uno de estos daemon privilegiado, que utiliza el D-Bus como su canal
IPC. El D-Bus es un sistema de interprocesos comnmente utilizado; uno de sus usos
previstos/diseados es permitir que los procesos del usuario y los servicios del
sistema se comuniquen, especialmente este tipo de comunicacin entre un daemon
privilegiado y sus clientes menos privilegiados.
La gente a veces critica a D-Bus por no hacer nada que no pueda hacer usted mismo
con algunos sockets AF_UNIX. Bueno, no, por supuesto que no - la parte importante
de la implementacin de referencia y las diversas reimplementaciones interoperables
consiste en un daemon y algunos sockets AF_UNIX, y el resto es una simple cuestin
de programacin. Sin embargo, es suficiente para la mayora de los usos en su
espacio del problema, y es generalmente mejor que inventare los suyos.

La ventaja de D-bus sobre hacer su propia cosa es precisamente que usted no est
haciendo su propia cosa: el buen diseo de IPC es difcil, y D-bus toma algunas
decisiones estructurales de modo que menos autores de la aplicacin tienen que
pensar en ellos. Por ejemplo, tiene un daemon central "hub" (el dbus-daemon, o
"message bus") para que n aplicaciones comunicandose no necesiten O(n ) sockets ;
utiliza el dbus-daemon para proporcionar un pedido total de mensajes por lo que no
tiene que pensar en el reordenamiento de mensajes; tiene un modelo de denominacin
distribuida (que tambin puede utilizarse como mutex distribuido) para que no tenga
que disearlo; tiene un formato de serializacin y un sistema de tipo para que no
tenga que disear uno de esos; tiene un marco para "activar" los daemons de
ejecucin a peticin para que no tengan que utilizar los recursos inicialmente,
implementados utilizando un ayudante de setuid y/o sistema; y as sucesivamente.

Si tiene objeciones religiosas a D-bus, puede reemplazar mentalmente "D-Bus" por

"AF_UNIX o algo" y la mayor parte de este artculo seguir siendo cierto.

Est bin?

En cualquier caso, ejecutar un ayudante privilegiado o enviar una solicitud a un

daemon privilegiado a travs de IPC, el proceso privilegiado tiene dos preguntas
que debe responder antes de realizar su trabajo:

Qu se me pide que haga?

debera hacerlo?

Tiene que tomar algn tipo de decisin sobre este ltima basndose en la
informacin disponible. Sin embargo, antes de llegar hasta all, hay otra capa:

Hizo llegar la peticin a todos?

En el modelo setuid, hay una simple comprobacin de seguridad que puede aplicar:
puede hacer que /bin/Mount slo sea ejecutable por un grupo determinado, o slo
ejecutable por ciertos perfiles AppArmor, o similar. Esto funciona hasta un punto,
pero no puede distinguir entre usuarios fsicamente presentes y no fsicamente
presentes, u otros hechos que podran ser interesantes para su poltica de
seguridad local. Del mismo modo, en el modelo IPC, puede hacer imposibles ciertos
canales de comunicacin, por ejemplo, utilizando la capacidad del daemon de dbus
para decidir qu mensajes entregar, o los permisos del sistema de archivos de
sockets AF_UNIX, o un marco MAC como AppArmor.

Ambos son bastante "asperos" comprueba que realmente no entienden los detalles ms
finos de lo que est pasando. Si la respuesta a "esto es seguro?" Es algo de la
forma "tal vez, depende de ...", entonces no pueden hacer lo correcto: deben
dejarlo pasar y dejar que el dominio del proceso privilegiado haga la comprobacin,
o negarlo y perder la funcionalidad potencialmente til.

Por ejemplo, en un entorno AppArmor, algunas aplicaciones no tienen absolutamente

ninguna razn legtima para hablar con udisks2, por lo que la poltica de AppArmor
puede simplemente bloquearla por completo. Sin embargo, una vez ms, esto es una
comprobacin imprecisa: el ncleo tiene mecanismo, no la poltica, y no sabe lo que
el servicio hace o por qu. Si la aplicacin necesita poder hablar con el servicio
en absoluto, entonces el control de acceso de mayor presicin (que obedece a
algunas solicitudes, pero no todas) tiene que ser el trabajo del servicio.

dbus-daemon tiene la capacidad de hacer coincidir los mensajes de una manera

relativamente fina, basndose en la ruta del objeto, la interfaz y el miembro en el
mensaje, as como la informacin de enrutamiento que se utiliza (es decir, la
fuente y el destino). Sin embargo, no est claro que esto tenga mucho sentido
conceptualmente: Estos son hechos sobre la mecnica de la IPC, no hechos sobre la
peticin especfica del dominio (porque la mecnica del IPC es todo lo que dbus-
daemon entiende). Por ejemplo, tomando el ejemplo de udisks2 de nuevo, dbus-daemon
puede distinguir entre un intento de ajustar las opciones de montaje para una
memoria USB (probablemente bien) y un intento de ajustar las opciones de montaje
para /usr (no es bueno).

Para tener una poltica de seguridad especfica del dominio, necesitamos un

componente especfico del dominio, por ejemplo udisks2, para involucrarse. A
diferencia de dbus-daemon, udisks2 sabe que no todos los discos son iguales, sabe
qu categoras tienen sentido distinguir, y pueden identificar en qu categoras se
encuentra un disco en particular. As que udisks2 puede tomar una decisin ms
informada.

Por lo tanto, un enfoque ingenuo podra ser escribir una funcin en udisks2 que se
parece a algo como este seudocdigo:

puedo_montar_este_disco (user, disk, opciones mount) boolean

{
if (user es root || user es equivalente-root)
return true;

if (disk no es extraible)
return false;

if (opciones mount son dainas)

return false;

if (user is in manipulate non-local disks group)

return true;

if (user is not logged-in locally)

return false;

# https://en.wikipedia.org/wiki/Multiseat_configuration
if (user is not logged-in on the same seat where the disk is
plugged in)
return false;

return true;
}

Delegar la poltica de seguridad en algo central

La poltica de seguridad pseudocdigo esbozado anteriormente es bastante complicada

ya, y no necesariamente cubre todo lo que es posible que desee considerar.

Mientras tanto, no todos los sistemas son iguales. Una distribucin Linux de
propsito general como Debian podra funcionar en sistemas de servidor/mainframe
con slo usuarios remotos, ordenadores personales portatiles/de-escritorio con un
usuario equivalente a root, ordenadores corporativos bloqueados portatiles/de-
escritorio, dispositivos mviles y as sucesivamente; Estos sistemas no deberan
necesariamente tener la misma poltica de seguridad.

Otro factor interesante es que para algunas operaciones privilegiadas, es posible

que desee realizar una autorizacin interactiva: pdale al usuario que solicite que
confirme que la accin (que podra haber provenido de un proceso de fondo) debe
realizarse (como la UAC de Windows), o para probar que la persona que actualmente
se encuentra en el teclado es la misma que la persona que inici la sesin dando su
contrasea (como sudo).

Podramos en principio escribir cdigo para todo esto en udisks2, y en

NetworkManager, y en systemd, ...-pero eso claramente no escala, particularmente si
usted desea que la poltica de seguridad sea configurable. Introduzca polkit
(anteriormente PolicyKit), un servicio de sistema para aplicar polticas de
seguridad a las acciones

La forma en que funciona polkit es que la aplicacin hace su anlisis especfico

del dominio de la solicitud, en el caso de udisks2, si el dispositivo se monta es
extrable, si las opciones de montaje son razonables, etc. - y lo convierte en una
accin. La accin da a polkit una manera de distinguir entre cosas que son
conceptualmente diferentes, sin necesidad de conocer los detalles. Por ejemplo,
udisks2 actualmente divide el montaje del sistema de archivos en
org.freedesktop.udisks2.filesystem-mount, org.freedesktop.udisks2.filesystem-mount-
fstab, org.freedesktop.udisks2.filesystem-mount-system and
org.freedesktop.udisks2.filesystem-mount-other-seat.

La aplicacin tambin encuentra la identidad del usuario que hace la solicitud. A

continuacin, la aplicacin enva la accin, la identidad del usuario solicitante,
y cualquier otro dato interesante a polkit. Como se implementa actualmente, polkit
es un servicio de d-bus, por lo que esta es una solicitud de IPC a travs de d-bus.
polkit consulta su base de datos de polticas para elegir uno de los varios
resultados

* s, djalo
* no, no lo permitas
* pedir al usuario autenticarse como ellos mismos o como un usuario
privilegiado (administrador del sistema) para permitirlo, o cancelar la
autenticacin para no permitirlo
* pedir al usuario autenticar la primera vez, pero si lo hace, recuerde durante
un tiempo y no preguntar de nuevo

Entonces, cmo decide polkit esto? Lo primero es que lee la descripcin legible de
la mquina de las acciones, en /usr/share/polkit-1/actions, que especifica una
poltica predeterminada. A continuacin, evala una poltica de seguridad local
para ver lo que dice. En la versin actual de polkit, la poltica de seguridad
local se configura escribiendo JavaScript en /etc/polkit-1/rules.d (poltica local)
y /usr/share/polkit-1/rules.d (valores predeterminados del proveedor del OS). En
las versiones anteriores como la actualmente embarcadas en la rama inestable de
Debian, hubo una arquitectura de plugin; pero en la prctica nadie escribi plugins
para ella, y, en su lugar, todos utilizan el ejemplo de autoridad local despachada
con polkit, configurado a travs de los archivos en /etc/polkit-1/localauthority
y /etc/polkit-1/localauthority.d.

Estas polticas pueden tener en cuenta hechos tiles como:

Cul es la accin de la que estamos hablando?

Esta el usuario conectado localmente? Estn activos, es decir, no se
encuentran slo en una consola virtual no actual?
Esta el usuario en grupos particulares?
Por ejemplo, gnome-control-center en Debian instala este fragmento:

polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.locale1.set-locale" ||
action.id == "org.freedesktop.locale1.set-keyboard" ||
action.id == "org.freedesktop.hostname1.set-static-hostname" ||
action.id == "org.freedesktop.hostname1.set-hostname" ||
action.id == "org.gnome.controlcenter.datetime.configure") &&
subject.local &&
subject.active &&
subject.isInGroup ("sudo")) {
return polkit.Result.YES;
}
});

Que est razonablemente cerca de ser pseudocdigo para "usuarios locales activos en
el grupo de sudo puede establecer la configuracin regional del sistema, el diseo
del teclado, el nombre de la mquina y la hora, sin necesidad de autenticarse". Por
supuesto, un administrador del sistema podra anularlo al eliminar una poltica de
mayor prioridad para algunas o todas estas acciones en /etc/polkit-1/rules.d.

Resumen

Las verificaciones de permisos basadas en el ncleo no son suficientemente

finas para poder expresar algunas polticas de seguridad bastante razonables
El control de acceso de gran precisin requiere una comprensin especfica del
dominio
El kernel no tiene esa informacin (y tampoco lo hace dbus-daemon )
El servicio privilegiado que hace la cosa especfica del dominio puede
proporcionar la comprensin especfica del dominio para convertir la solicitud en
una accin
polkit evala una poltica configurable para determinar si los servicios
privilegiados deben llevar a cabo las acciones solicitadas

muy informativo

Gracias! Ms publicaciones como esta !!

Por lo general la gente que mejor entender es la gente que menos necesidad de tener
para la documentacin y por lo que no te molestes ... pero esto fue genial!

Siguiente sobre cmo depurarlo!

Comentario de albertodebian - Vie 05 jun 2015 20:35:18 BST

Estupendo!
Me alegro de ver finalmente alguna informacin escrita sobre esto. Alguna
posibilidad de que esto sea puesto en una pgina de manual o un doc de texinfo o
algo similar? La objecin # 1 que tengo sobre casi cada proyecto libre de
desktop.org es su absoluta falta de documentacin de cmo funcionan las cosas. La
objecin # 2 no es religiosa como usted asume, sino tcnica, pero no me inclinar
contra ese molino de viento aqu.
Comentarios de June - Jue 18 jun 2015 15:23:45 BST