[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: As distro sao inseguras



Henrique,

Agora acho que entendo melhor seu email: quando você procurou
minimizar os efeitos de um pânico entre usuários (que poderia estar
sendo causado por mim, reconheço meu erro nesta lista), você me
pareceu ser do outro extremo (talvez com efeitos tão indesejados
quanto o que me fiz transparecer). E daí você escreveu que o
problema estava bem resolvido, não era necessário se preocupar. O que
agora vejo que você devia estar querendo deixar transparecer é que não
era necessário o pânico, o qual poderia ter efeitos até piores do que
um alerta como o que escrevi; ainda, você devia estar querendo mostrar
que a Debian está resolvendo bem este assunto (concordo, exceto pelo
fato da demora, principalmente considerando que o assunto já vinha
sendo discutido anteriormente, embora sobre outro enfoque, mas todos
precisamos reconhecer que a Debian trata este - como outros assuntos -
com um impressionante nível de seriedade e compromisso com o usuário).

Neste sentido, vejo que eu errei do mesmo que lhe atribuí: espalhar
aos ventos algo com efeitos ruins. E você se explicou muito bem, eu
fui sincero quando disse que não o conhecia ainda, mas agora vejo que
fui injusto e peço desculpas. Até mesmo porque você é um dos
colaboradores do sistema que uso, e lhe devo uma parcela de gratidão.

Como você e o Gustavo bem disseram, as chances são bem pequenas de
estarmos recebendo pacotes adulterados por algum proxy, a não ser que
isto estivesse sendo feito nos provedores de back-bone.

Há um outro ponto que me preocupou no seu email: sua aparente
tranquilidade quanto às assinaturas MD5 dos pacotes. MD5 apenas gera
um checksum, mas isto até mesmo os frames ethernet, os datagramas IP
e pacotes TCP têm, embora utilizando outra técnica (CRC). O MD5 está
muito longe de ser o que precisamos, pelo menos quando usado
isoladamente.

O que precisamos é de assinatura digital que permita ao recebedor
checar a autenticidade da assinatura, e não apenas a integridade: o
PGP nos dá as duas coisas. Já o MD5 nos dá apenas a informação de
integridade, e nem mesmo contém informação de quem assinou: ou seja,
qualquer um pode modificar o pacote .deb e gerar novo MD5 para ele,
e não há como o recebedor descobrir que isto foi feito baseado apenas
no que ele recebeu.

Há uma sugestão na debian-security que é cada desenvolvedor gerar
assinaturas MD5 para os seus pacotes, que seriam acrescentadas também
aos Packages.gz, os quais por sua vez seriam assinados com PGP pelo
servidor da Debian e por algumas pessoas para garantir a autenticidade.
Eu creio ser este o caminho, porque exigir de cada desenvolvedor que
assine seu pacote com PGP é algo que tenho certeza que *não* irá
funcionar: eu mesmo, em 1998, trabalhando no NOC central de uma rede
WAN com cerca de 40 POP's espalhados pelo Estado de SP, cheguei a
escrever um tutorial sobre PGP p/ o Windows que a maioria usava,
http://www.interprov.com.br/download/tutorial-pgp.pdf, mas o pessoal
técnico dos POP's, a despeito do ótimo nível de muitos deles, passou
por várias dificuldades que os desanimaram de utilizar o PGP (tipo
perder a passphrase e daí a gente ter de assinar a nova chave deles,
problemas com Copy&Paste, uso inadequado da web-of-trust, falta de
cuidado ao guardar a chave privada, etc...). Aparentemente estaria
faltando garantir a autenticidade de quem fez upload do pacote, mas
isto pode ser inferido do login via ssh, e a experiência mostra que
até dá para confiar no zelo com que os desenvolvedores guardam sua
senha de login. Há ainda o problema de garantir a autenticidade das
chaves públicas do pacote debian-keyring: utilizar a teoria dos
grafos com seus algoritmos de coloração, best-path, etc, pode ser
muito bonito mas quem garante que o programa que o usuário está
executando é o original? Acho que faltam mais idéias para isto. Se
você for pensar bem, o aplicativo Windows 2000 Update, por exemplo,
autentica automaticamente o web server da Microsoft baseado em
certificados digitais emitidos por entidades reconhecidas pelo
browser: mas quem garante que o browser não foi modificado, ou até
mesmo o Windows Update. Creio ser neste ponto que são necessárias
mais idéias!

Talvez eu esteja sendo simplista por não ter acompanhado as
discussões anteriores, mas não vejo dificuldade em se implementar
o descrito acima no curto-prazo.

Mais uma vez desculpe pelo julgamento precipitado a seu respeito,

Antonio

On Tue, Dec 18, 2001 at 01:15:36AM -0200, Henrique de Moraes Holschuh wrote:
> Date: Tue, 18 Dec 2001 01:15:36 -0200
> From: Henrique de Moraes Holschuh <hmh@debian.org>
> To: debian-user-portuguese@lists.debian.org
> Subject: Re: As distro sao inseguras
> 
> On Mon, 17 Dec 2001, Antonio Augusto de Cintra Batista wrote:
> > até este seu email, mas apesar de me sentir constrangido creio que
> 
> eh? Não deveria se sentir constrangido. Se eu espalhei desinformação, vai
> ser constrangedor pra mim... (bom, os erros estúpidos de português na minha
> mensagem eu já considero constrangedores o suficiente, mas deixa isso pra
> lá).
> 
> > atirar tão levianamente assim sem medir as consequências que a
> > desinformação traz quando lançada aos ventos.
> 
> A situação está longe de ser perfeita, mas não é tão ruim quanto pode
> parecer (pacotes trojanados entrando no Debian desde a fonte, contaminando
> tudo desde a ftp-master até as máquinas dos developers e usuários).  Era
> mostrar isso (pra evitar excesso de pânico) o objetivo da minha email.  Acho
> que o seu comentário sobre "até dos principais mantenedores"  me deixou meio
> preocupado demais.
> 
> No processo, eu dei pouca ênfase ao problema de proxy. Assumo a culpa disso,
> mas esse problema possui solução (MUITO inconveniente) no momento (a qual
> descrevi), e uma solução aceitávelmente desconfortável está a caminho
> (developers assinarem todas as .debs), com um bandaid confortável de
> quebra (apt e repositórios assinados).
> 
> O problema de PKI com as assinaturas é real, e sim, a web-of-trust é parte
> da solução completa e definitiva. Mas a redundância da informação presente
> no Debian keyring (você consegue cópias das chaves dos developers de quase
> todos os keyservers porque as chaves estão em circulação faz um bom tempo
> para a maioria dos developers), e um programa de grafos para encontrar
> caminhos validados (cadê o AT&T Pathserver quando se precisa dele?) ajuda a
> resolver o problema por enquanto.  Fica bem fácil encontrar chaves que não
> dá pra confiar de jeito nenhum usando grafos, e chaves que apesar de você
> não ter caminho direto para validar, são quase garantidamente válidas, pelo
> grande número de caminhos longos e curtos que as validam apartir de outros
> pontos da web-of-trust.
> 
> Quanto a decisão de não consertar o problema na Woody, ela só pode ser
> revogada pelo Release Manager no momento, pois o sistema base já foi
> congelado. E o pessoal diretamente responsável pelo apt, da-katie e dpkg
> concordou bem antes que não iria dar para ter tudo funcionando em tempo para
> a Woody (ou se não concordou, não se fez nada de concreto para mudar a
> situação, nem por parte deles, nem por parte de outros desenvolvedores).
> Quem sabe para a 3.0r2 (Woody, revisão 2) dê para por o bandaid.
> 
> > meu primeiro email, por favor leia antes o archive deste mês
> > da lista debian-security, e daí me avise quando tiver terminado
> 
> Aquela thread não tem nem de perto toda a discursão à respeito. Nem tocou no
> problema dos auto-builders, nem no problema da chave secreta desprotegida
> que vai ser necessária pra da-katie e é o pesadelo do sistema (movemos
> pacotes demais por dia na unstable pra fazer isso manualmente sem deixar os
> ftpmasters malucos, mas talvez nesse ponto a solução bandaid possa
> ajudar)... já passou muita água por baixo dessa ponte.
> 
> Ah, espera. Esse é o lado das assinaturas nos .deb propriamente ditos
> (verificada pelo dpkg, apt nem entra no processo), não a solução bandaid via
> apt (repositório com md5-sum assinadas, que é interessante, segura do ponto
> de vista do usuário, mas não atinge todos os casos, pelo menos não pra
> developers, nem para quem precisa usar repositórios apt que não são do
> Debian).  
> 
> Acho que achei o motivo pelo qual você me acusou de espalhar
> desinformação...  eu desconsiderei o bandaid a maior parte do tempo, e não
> deixei claro do que estava falando.  E eu tenho quase certeza que a solução
> bandaid não está completamente implementada (exceto no apt da Conectiva).
> 
> Culpa minha, não deixei claro que haviam dois caminhos paralelos de
> autenticação (um autentica o pacote propriamente dito, o outro o caminho que
> ele fez desde o repositório ftp-master).  O caminho via dpkg está completo e
> funcional, se eu quisesse, poderia passar a assinar todas as .debs que
> empacoto apartir de agora, e um usuário poderia mandar o dpkg rejeitar todas
> as debs não assinadas.  Funciona tão bem, que teve um dia na unstable que se
> você instalasse o dpkg, ele passava a rejeitar todos os pacotes reclamando
> que eles não estavam assinados... 
> 
> > para que não perca meu tempo quando eu responder ao seu email
> > apontando as devidas correções (ou aponte-as você mesmo, por
> > favor!).
> 
> Faltou alguma?  Eu deixei um bocado de coisa implícita, concentrado como
> estava, querendo mostrar que a situação é um pouco menos grave do que pode
> parecer a princípio (temos alguns meios, por mais cretinos e doloridos que
> sejam, de verificar se as debs foram modificadas ou não).
> 
> Quanto à força-tarefa, bom, se quiser ajudar com o lado do apt, tem algum
> código a ser escrito, e pouca infro-estrutura a ser especificada. Afinal de
> contas, é só uma chave que assina um Packages.gz para tomar conta... ao
> contrário das assinaturas nas .deb propriamente ditas.
> 
> Mas o mais útil seria trabalhar na infra-estrutura necessária para
> assinaturas nos pacotes, e integradas no Debian.
> 
> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-portuguese-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: