Número 59
14 de xuño de 2023

O cortello

A estas alturas do conto, todos estamos afeitos ao modelo de seguridade por identidade, no que cada usuario do sistema ten a súa propia identidade que determina o seu nivel de acceso aos distintos recursos. Por exemplo, nun weblog Amadeo ten permisos de lectura e Gumersinda pode escribir historias, pero Filomeno está bloqueado por chamar pailana a Eusebia, que é unha administradora.

Tres porcos no seu cortello.

Por moi coñecido e habitual que sexa, este modelo non é perfecto. O seu problema principal é que, se alguén rouba unha identidade, ten acceso a todo. Por exemplo, se alguén che hackea a conta do Insta (how do you do, fellow kids), pódeche borrar todas as fotos e enviar mensaxes coma se foras ti.

Os programas de ordenador teñen o mesmo problema. En Unix, por exemplo, todos os programas corren baixo a identidade dun usuario, incluídos os servidores web e outros programas que están conectados á rede. Se alguén rebenta un deses programas e consigue inxectar código nel, tamén pode operar coma se fora ese usuario, con todo o acceso que iso lle dá.

Unha das solucións modernas para ese problema é o uso de “sandboxes” que limitan o acceso que ten un programa a outros recursos.

Imaxinade un porco que anda ceibe pola aldea e pode ir aquí e acolá, remexendo no lixo na busca de comida, deitándose na leira, bebendo do rego e espantando as galiñas de Inés. Se o poñedes nun cortello, porén, o porco non pode ir a ningures e só pode comer e beber o que lle deades.

Cando poñedes un programa no cortello, ese programa só pode acceder aos recursos que lle deades. Por exemplo, non pode abrir un ficheiro, senón que alguén ten que abrirllo para que o programa poida usalo, e non pode conectarse pola rede, senón que alguén lle ten que dar unha conexión xa establecida.

Este é un modelo de seguridade diferente: o modelo de capacidades. Nel, o que determina o acceso non é a identidade do usuario ou do programa, senón as capacidades que ten. Os programas acceden aos distintos recursos usando esas capacidades, e se non teñen unha capacidade determinada, non teñen acceso.

Coma exemplo práctico, en Unix (que usa o modelo de identidade) un programa pode abrir o ficheiro de contrasinais simplemente sabendo o nome, e despois de abrilo recibe un “descritor de ficheiro” (FD) que lle permite ler ese ficheiro.

En cambio, nun sistema que usa un modelo de capacidades, o programa non pode abrir o ficheiro de contrasinais aínda sabendo o nome. De feito, non pode abrir ningún ficheiro directamente: se precisa de acceder a un ficheiro, o sistema dálle o FD xa aberto. Ese FD é a “capacidade” á que se refire o nome do modelo.

Desta maneira, o modelo de capacidades evita o problema do modelo de identidade: os programas só reciben as capacidades das que precisan e, se alguén os hackea, o responsable só ten acceso a esas capacidades e máis nada. Que máis dá se alguén hackea un servidor web se o hack só dá acceso ao ficheiro que estaba a servir e á conexión que xa tiña aberta con si?

O modelo de capacidades non é novo ou experimental: IBM, por exemplo, usouno no AS/400. E, con non ser moi común, hai sistemas novos que o usan: por exemplo, WebAssembly úsao para a interface co sistema, e o sistema operativo Fuchsia tamén usa este modelo.

E se programades en Linux e queredes meter os vosos programas no cortello, botádelle unha ollada a sandboxed-api, que é software libre e permite encortellar tanto unha biblioteca coma un programa completo.

A ilustración desta Folla foi producida mediante IA.