Avaliação de código¶

Como avaliar determinada aplicação:

Se devemos ou não executá-la.
Em qual ambiente e grau de isolamento ela deve ser executada.
Como verificar a integridade de código fonte e binário.
O que fazer caso ela seja proprietária e mesmo assim precisarmos executá-la ou utilizá-la?

Malícia ou erro¶

Pela Navalha de Hanlon, não temos como afirmar se um bug num software é intencional ou resultado de um erro de programação. Na verdade, essa questão não importa contanto que se descubra o bug.

Assumimos então as necessidades de:

Auditoria de padrões, protocolos e implementações (código).
Verificação de software obtido quanto à garantia de origem (sem alterações durante download ou alterações à revelia do time de desenvolvimento).
Estabelecer vínculos de confiança com times de desenvolvimentos.

A realidade, no entanto, é desoladora:

Auditoria é cara e impraticável em vastas quantidades de código.
Times de desenvolvimento são anônimos ou inexistem laços de confiança entre os próprios/as desenvolvedores e seus usuários/as; mesmo se existirem, é difícil saber se o time de desenvolvimento está colaborando com implantadores de backdoors (via gag orders, etc).
A maior parte dos softwares não é assinada digitalmente.

A segurança num mundo complexo que ainda permite a interação social se dá pela redução de danos. A seguir são delineados diversos níveis de execução de software.

Padronização¶

A seguir há uma simples padronização de níveis de verificação e execução de código cujo objetivo é estabelecer um nível de proteção de dados. Adicione um tempero de conexão, armazenamento ou processamento criptografado (e nos conte como você fez!) para aumentar ainda mais sua segurança!

Verificação de código¶

Em níveis decrescentes de confiabilidade:

V1. O código é auditado por quem o executa. Viável para uma pequena porção de código sensível, inviável para todo um sistema ou infraestrutura.
V2. O código é auditado por um grupo confiável. Maior abrangência de código, porém ainda inviável para cobrir qualquer aplicação prática.
V3. A integridade do código é verificada por procedimento criptográfico (assinatura digital) em que existe algum caminho de verificação («web of trust» ou similar) e procedimento de confiabilidade (mentoring, etc) dos/as mantenedores/desenvolvedores do software.
V4. A integridade do código é verificada por procedimento criptográfico (assinatura digital) independente de haver caminho de verificação ou atestação de mantenedores e desenvolvedores/as.
V5. Checagem básica de integridade de código (obtenção via conexão criptografada verificada ou checagem simples de hash para evitar alterações de código em trânsito (QUANTUMINSERT e afins).
V6: TOFU (Trust on First Use).
V7. Sem checagem de integridade.

Execução de código¶

Em níveis decrescentes de isolamento:

R1. O código roda numa máquina física específica (alto isolamento).
R2. O código roda numa máquina virtual específica (médio isolamento).
R3. O código roda numa máquina virtual compartilhada (baixo isolamento).
R4. O código roda numa máquina física compartilhada (sem isolamento).

Dados¶

Níveis de proteção por dados fornecidos apenas a aplicações:

D1. Confiáveis executadas em primeira pessoa (infra-estrutura própria) e dependendo dos níveis de verificação e execução de código): a. Que não compartilham dados com outras aplicações. b. Que compartilham dados com aplicações do mesmo nível. c. Que compartilham dados com aplicações de nível abaixo (degradação de nível).
D2. Confiáveis executadas por terceiros confiáveis e dependendo dos níveis de verificação e execução de código: a. Que não compartilham dados com outras aplicações. b. Que compartilham dados com aplicações do mesmo nível. c. Que compartilham dados com aplicações de nível abaixo (degradação de nível).
D3. Não confiáveis executadas em primeira pessoa: a. Que não compartilham dados com outras aplicações. b. Que compartilham dados com aplicações do mesmo nível. c. Que compartilham dados com aplicações de nível abaixo (degradação de nível).
D4. Não confiáveis executadas por terceiros: a. Que não compartilham dados com outras aplicações. b. Que compartilham dados com aplicações do mesmo nível. c. Que compartilham dados com aplicações (degradação total de segurança e privacidade).

Exemplo: TPC¶

O TPC é o instrumento básico de trabalho do/a desenvolvedor e administrador de sistema (DevOp), sendo importante estabelecer um nível de confiabilidade para o código executado. Por exemplo:

Nível do host: V3:R3:D1a, V3:R3:D1b e V3:R3:D1c são até certo ponto aceitáveis.
Máquinas virtuais: para cada máquina virtualizada, adotar um nível.

É importante lembrar, contudo, que apesar do bom isolamento de diversas soluções de virtualização em software livre e aberto, falhas de segurança podem existir e permitir que uma aplicação «vaze» para fora do ambiente virtual.

Status¶

Estado da verificação de autenticidade e integridade em diversas distribuições.

Git¶

O git supporta tags e commits assinados. No caso de tags:

tag="`git describe --abbrev=0 --tags`"
git tag -v $tag && git checkout $tag

Há uma implementação desta checagem no plugin git-check-tags (e que também pode ser checada).

Como avançar a agenda?¶

Criar um template padrão de mensagem para:

Advogar a adoção de checagens por padrão nas plataformas de distribuição.
Advogar releases assinados e obtenção via https para softwares.

Homologação¶

Em ambiente isolado:

Download.
Verificação de integridade.
Compilação.
Teste.
Empacotamento.