Existe algum mecanismo correspondente para proteger o apt para o FreeBSD?

Question

Vindo de mais de um background linux eu olhei para o FreeBSD e li a maior parte do Manual do FreeBSD , que é bom e fornece muitos insights sobre Segurança (Capítulo 13) . Mesmo que muitas informações relacionadas à segurança tenham sido estabelecidas, não consigo entender como a integridade das fontes para o FreeBSD é realizada (e também para os sistemas de pacotes binários e de portas).

Como dito antes, eu estou acostumado a usar algumas distribuições linux, Debian mais especificamente, onde um mecanismo ou ferramenta chamada secure apt é usado onde a raiz de confiança original é através de uma chave pública ("Chave de Assinatura Automática do Arquivo Debian") que gpg assina uma cascata de listas de Hash que cobrem todos os arquivos em pacotes.

Ao lidar com a forma de adquirir o FreeBSD securily, ele menciona a opção de usar o repositório de subversão do FreeBSD, onde afirma então

HTTPS is the preferred protocol, providing protection against another computer pretending to be the FreeBSD mirror (commonly known as a “man in the middle” attack) or otherwise trying to send bad content to the end user. ( Source: https://www.freebsd.org/doc/handbook/svn.html )

e embora eu concorde completamente com a utilidade do TLS / SSL, eu queria saber se essa é toda a proteção disponível? A comunidade FreeBSD além de um HTTPS de "canal seguro" (algumas CAs parecem atores estatais), usa algum tipo de alternativa de WOT para verificar a integridade das fontes adquiridas?

O que eu peço, portanto, é algo similar ao secure-apt do Debian?

atualização:

Eu verifiquei a assinatura do pacote via uma abordagem web of trust (WOT) de algum outro Linux Distro, o Arch Linux é tão jovem quanto 2012 (veja link ), enquanto para o gentoo similar parece existir, ainda não sei dizer quando foi introduzido. link

De alguma forma, parece que tem havido esforços em distribuições Linux para endereçar a integridade de pacotes / fontes, então estou muito certo de que algo similar existe no domínio da segurança dos BSDs, certo?

    

Answer 1

Pacotes

Publico um repositório de pacotes assinado e veja como isso funciona.

O administrador do sistema configura os repositórios adicionando um arquivo de configuração como /usr/local/etc/pkg/repos/JdeBP.conf . Como parte disso, xe informa ao gerenciador de pacotes a chave pública que deve ser usada para verificar as assinaturas no repositório. Xe obtém essa chave de alguma forma confiável e a salva em um arquivo como /usr/local/etc/pkg/keys/JdeBP.pub . Xe então nomeia isso como o arquivo de chave pública em /usr/local/etc/pkg/repos/JdeBP.conf .

Eu assino o repositório de pacotes com a chave privada que só eu tenho usando o comando pkg repo . /elsewhere/package_signing_key . Isso cria informações assinadas sobre o repositório e os pacotes em três arquivos, meta.txz , digests.txz e packagesite.txz . Cada um desses arquivos tem dois arquivos, sendo um deles um arquivo signature para o outro. Os arquivos digests e packagesite contêm hashes de cada um dos arquivos do pacote. O meta-arquivo contém apenas os nomes dos outros dois e algumas versões das informações da ferramenta pkg-ng.

Então, isso é muito parecido com o APT seguro. Existem algumas diferenças:

• Em vez de Release dar as somas de verificação para Packages e Packages , em seguida, dando os hashes para os arquivos reais do pacote, o pkg-ng tem apenas um nível. packagesite.yaml fornece os hashes dos arquivos de pacotes reais diretamente.
• Em vez de as coisas serem divididas em arquivos Release e Release.gpg carregáveis separadamente e, em seguida, mais arquivos Packages e Sources , o arquivo packagesite.yaml (cobrindo todo o repositório) e seu signature são baixados como uma unidade em uma operação fetch (e uma transação HTTP / FTP) como o arquivo packagesite.txz .

Mas a ideia é a mesma. Um administrador do sistema confia que o arquivo packagesite.yaml veio de mim porque sua signature acompanhante pode ser verificada em relação à cópia armazenada localmente, confiável, da minha chave pública. Um administrador do sistema confia que o arquivo redo-1.3.txz veio de mim porque seu hash corresponde aos hashes da (agora) confiável packagesite.yaml .

Portas

As portas são uma chaleira muito diferente de peixe. O APT Seguro do Debian trata os pacotes de origem como apenas mais pacotes. As portas FreeBSD / TrueOS não são pacotes fonte no sentido Debian, mas são formas bastante automatizadas de obter e construir pacotes fonte que são publicados por outra pessoa. Uma porta é essencialmente um makefile com algumas instruções sobre onde fetch source. Ele tem uma lista dos hash (es) do que quer que seja buscado.

A porta em si vem do repositório FreeBSD ou TrueOS, usando o Subversion (se o FreeBSD) ou o git (se for TrueOS ou FreeNAS). As idéias padrão para confiar no Subversion ou no git se aplicam. No TrueOS, por exemplo, a URL "remota" usada ao buscar as portas (próprias) com o git é uma url HTTPS para um repositório do GitHub que o iXsystems atua (no TrueOS Handbook ) é aquela que possui .

Assim, um administrador de sistema confia em uma porta porque xe a obteve usando uma busca do Subversion ou git que xe confia. Xe confia no arquivo de origem buscado pela porta porque corresponde ao hash listado na (agora) porta confiável.

Notas

O Release.gz e o Packages.gz do Debian são praticamente apenas formas de comprimir o transporte HTTP. Eu descrevi algumas outras coisas que não têm a ver com segurança, como diferenças em como se espera lidar com várias versões de sistemas operacionais.

O Debian mudou para a forma como o FreeBSD funciona ao longo dos anos, e não funciona mais do que isso. Hoje em dia um tem os hashes e a assinatura em um, mais como um repositório do FreeBSD, em um arquivo InRelease . Isso evita um problema de "rasgo" que ocorre quando alguém faz o download de Release e, em seguida, Release.gpg , e o proprietário do repositório atualizou o repositório entre os dois downloads, causando uma correspondência incorreta da assinatura.

(O Debian só fez as coisas desta forma originalmente porque elas cresceram em etapas ao longo dos anos, cada uma baseada nos mecanismos anteriores sem alterá-las: primeiro o sistema Package , depois o mecanismo Release acima disso, então o mecanismo Release.gpg em cima disso.)

Além disso, o FreeBSD tem outra maneira diferente de fazer isso, que envolve "impressões digitais" e um arquivo digests (no arquivo digests.txz ).

Também refiz as considerações de segurança para a chave de assinatura, já que isso não é realmente relevante para uma resposta que está discutindo como isso é diferente do APT seguro. Os requisitos de segurança da chave privada são gerais para toda a noção de assinar coisas com chaves públicas / privadas e são independentes das estruturas do repositório.

Leitura adicional

• Jonathan de Boyne Pollard (2016). Repositórios de pacotes . Softwares.
• Colin Watson (2016-04-08). Não há mais erros "Incompatibilidade de soma de hash" .