[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
O Debian tem um Security Team (Time de Segurança), composto por cinco membros e duas secretárias que manipulam a segurança na distribuição stable (estável). Manipular a segurança significa que eles acompanham as vulnerabilidades que aparecem nos software (vendo foruns como bugtraq o vuln-dev) e determinam se a distribuição stable é afetada por eles.
O Debian Segurity Team também é o contato para problemas que são coordenados
pelos desenvolvedores ou organizações como CERT
que podem afetar muitos vendedores.
Isto é, quando os problemas não são específicos do Debian. Existem dois
contatos com o Security Team:
team@security.debian.org
o
qual só é lido pelos membros do security team .
security@debian.org
o
qual é lido por todos os desenvolvedores Debian (incluindo o security team).
Emails enviados para esta lista não são publicados na internet (esta não é uma
lista de email pública).
Informações sensíveis devem ser enviadas para o primeiro email e, em alguns casos, deve ser encriptada com a Debian Security Contact key (key ID 363CCD95).
Quando um provável problema for recebido pelo Security Team, ele investigará se
a distribuição stable foi afetada e, caso positivo, uma correção será
feita no código fonte base. Esta correção algumas vezes incluirá algum patch
(que normalmente é mais recente que a versão distribuída pelo Debian). Após o
teste da correção, novos pacotes são preparados e publicados em security.debian.org
e podem ser baixados
com o apt
(veja Executar uma atualização de segurança,
Seção 4.2). Ao mesmo tempo um Debian Security Advisory (DSA) é
publicado no web site e enviado para a listas de email incluindo debian-security-announce
e bugtraq.
Outras perguntas frequentes do Debian Security Team podems er encontradas em Questões relacionadas ao time de segurança da Debian, Seção 11.3.
Debian Security Advisories são avisos emitidos quandos uma vulnerabilidade de segurança que afeta um pacote Debian é descoberta. Estes avisos, assinados por um membro do Security Team, inclui informação das versões afetadas assim como a localização das atualizações e seus MD5sums. Esta informação consiste de:
número da versão para correção.
tipo de problema.
se ele é remoto ou localmente explorável.
pequena descriçãod do pacote.
descrição do problema.
descrição da exploração.
descrição da correção.
DSAs são publicados em Debian's
mainserver frontpage
e em Debian security pages
.
Normalmente isto não é feito até a reconstrução diária do website, então eles
podem não estar presentes imediatamente, o canal preferido é a
debian-security-announce mailing list.
Usuários interessados podem, porém, usar o canal RDF para baixar
automaticamente as DSAs para seu computador. Algumas aplicações, como o
Evolution
(um cliente de email e assistente de informações
pessoais) e o Multiticker
(um applet do GNOME), podem ser usados
para baixar os avisos automaticamente. O canal RDF está disponível em http://www.debian.org/security/dsa.rdf
.
Os DSAs publicados no website podem ser atualizados após enviados para as listas de email. Uma atualização comum é adicionada através de referências ao banco de dados de vulnerabilidades de segurança. Além disso, traduções [33] dos DSAs não são enviadas para as listas de email mas são diretamente incluídas no site.
Debian fornece uma referência completa em crossreferenced
table
incluindo todas as remomendações publicadas desde 1998. Esta
tabela é fornecida em complemento a reference map
available at CVE
.
Você notará que esta tabela fornece referências aos bancos de dados como
Bugtraq
, CERT/CC Advisories
and
US-CERT Vulnerability Notes
Database
assim como aos nomes CVE (veja abaixo). Estas referências
são fornecidas para uso, porém apenas referências CVE são periodicamente
revisadas e incluídas. Este recurso foi adicionado ao website em junho de
2002.
Uma das vantagens de adicionar referências ao banco de dados de vulnerabilidades é que:
torna fácil aos usuários Debian ver e tratar com recomendações publicadas que já tenham sido resolvidas pelo Debian.
administradores de sistema podem aprender mais sobre vulnerabilidades e seu impacto através das referências.
esta informação pode ser usada para a checagem de vulnerabilidades referentes ao CVE e detectar avisos falsos. (veja O scanner de vulnerabilidade X diz que meu sistema Debian é vulnerável!, Seção 11.2.1).
As recomendações de segurança, Debian Security Advisories eram declared
CVE-Compatible
[34] em fevereiro de 2004.
Desenvolvedores Debian entendeream que precisavam fornecer precisas e
atualizadas informações de segurança para a distribuição, permitindo aos
usuários gerenciar o risco associado com novas vulnerabilidades. CVE fornece
referências padronizadas que permitem aos usuários desenvolver um CVE-enabled security
management process
.
O projeto Common Vulnerabilities and
Exposures (CVE)
é mantido pela MITRE Corporation e fornece uma lista
de nomes padronizados para vulnerabilidades e exposições de segurança.
Debian acredita que fornecer aos usuários informações relacionadas a segurança que afetem a distribuição é extremamente importante. A inclusão dos nomes CVE em avisos ajudam os usuários a associar vulnerabilidades genéricas com atualizações específicas, com redução do tempo gasto para manusear as vulnerabilidades. Além disso, é fácil o gerenciamento da segurança em um ambiente onde já existem ferramentas que utilizam o CVE, como redes ou sistemas de deteccão de invasão, ou ferramentas de avalição de vulnerabilidades, mesmo que elas não sejam baseadas em uma distribuição Debian.
Debian iniciou adicionando nomes CVE aos DSAs em junho de 2002 e agora fornecer
para todos os DSAs lançados desde setembro de 1998 após a revisão iniciada em
agosto de 2002. Todos os avisos podem ser recuperados do website do Debian e
notícias relacionadas a novas vulnerabilidades incluindo nomes CVE se
disponíveis na época de seu lançamento. Avisos associados com um dado nome CVE
pode ser procurado diretamente através do search engine
.
Usuários que querem procurar por um nome CVE em particular podem usar o sistema
de busca disponível em debian.org para recuperar avisos disponíveis (em inglês
e traduzidos para outros idiomas). Uma busca pode ser feita para um nome
específico (como aviso CAN-2002-0001
)
ou para nomes parciais (como todos os avisos de 2002 para CAN-2002
).
Observe que você precisa entrar com a palavra advisory junto com o nome CVE
para recuperar apenas avisos de segurança.
Em alguns casos você pode nãO encontrar um CVE em avisos publicados porque:
No Debian os produtos não são afetados pela vulnerabilidades.
Ainda não existe uma viso abordando a vulnerabilidade (ele pode ter sido
informado para a security
bug
mas uma correção ainda não ter sido testada a atualizada)
Um aviso foi publicado antes que um CVE fosse assinado para a vulnerabilidade em questão (procure por uma atualização no web site)
Uma vez que o Debian é normalmente suportado em um grande número de arquiteturas, administradores algumas ficam admirados se uma dada arquitetura levar mais tempo para receber atualizações de segurança. De fato, exceto em raras circunstâncias, atualizações estão disponíveis para todas as arquiteturas ao mesmo tempo.
Enquanto antigamente a tarefa de construir atualizações de segurança era feita
a mão, hoje não é mais (como Anthony Towns descreve em a
mail
, enviado para a lista debian-devel-announce em 6 de junho de
2002.)
Pacotes atualizados pelo time de segurança (para security.debian.org:/org/security.debian.org/queue/unchecked
ou ftp://security.debian.org/pub/SecurityUploadQueue
)
tem suas assinaturas checada com um patch adequado dentro de quinze minutos,
uma vez isto feito eles são adicionados a lista de auto construtores. Então,
os pacotes podem ser disponibilizados para todas as arquiteturas num
tempo de trinta minutos a uma hora do momento em que foram atualizados. Porém,
atualizações de segurança são um pouco diferentes da atualização normal
envidada pelos mantenedores de pacotes, uma vez que, em alguns casos, antes de
ser publicadas, elas precisam esperar até serem testadas, um aviso ser escrito
ou, ainda, precisam esperar uma semana ou mais para evitar publicação da falhar
até que todos os vendedores tenham chance de corrigí-la.
Assim, a atualização de segurança trabalha da seguinte maneira (chamada "Accepted-Autobuilding"):
Alguém encontra um problema de segurança.
Alguém corrige o problema e atualiza security.debian.org (este alguém normalmente é um membro do Time de Segurança mas pode ser também um mantenedor de pacote com uma correção apropriada que contactou o time de segurança previamente). O Changelog inclui uma indicação testing-security ou stable-security.
Ocorre o upload checado e processado por um sistema Debian e movido para queue/accepted, e buildds são notificados. Arquivos aqui podem ser acessados pelo time de segurança e (indiretamente) pelos buildds.
O Security-enable buildds pega o pacote fonte (que tem prioridade sobre os builds normais), o constrói, e envia logs para o time de segurança.
O time de segurança reproduz os logs, e novos pacotes construídos são enviados para queue/unchecked, onde são processados pelo sistema Debian, e movidos para queue/accepted.
Quando o time de segurança verifica que o pacote fonte está aceitável (isto é, ele foi corretamente construído para todas as arquiteturas, corrigiu os problemas de segurança e não introduziu novos problemas) eles rodam um script que:
instala o pacote em um arquivo de segurança.
atualiza os pacotes, fontes e release files de security.debian.org de uma
maneira normal (dpkg-scanpackages
,
dpkg-scansources
...)
configura um aviso modelo que o time de seguranaça pode encerrar os trabalhos.
(opcionalmente) envia os pacotes para as atualizações adequadas e eles podem ser incluídos assim que for possível.
Este procedimento, antes feito a mão, foi testado e usado completamente durante o estágio freeze do Debian 3.0 Woody (Julho de 2002). Graças a esta infraestrutura do Security Team foi possível ter pacotes atualizados prontos para o apache e OpenSSH para todas as arquiteturas suportadas (quase vinte) em menos de um dia.
Este email foi enviado por Wichert Akkerman para Debian-devel-announce
mailing list
a fim de descrever o comportamento do desenvolvedor
Debian para manipulação de problemas de segurança em seus pacotes. Ele está
publicado aqui tanto para os desenvolvedores quanto os usuários entenderem
melhor como a segurança é manipulada no Debian.
Por favor observe que a última referência para esta informação é Debian
Developer's Reference
, esta seção será removida em futuro próximo.
Se um desenvolvedor tem conhecimento de um problema de segurança, seja em seu pacote seja em outro, ele deve sempre contactar o time de segurança (através de team@security.debian.org). Eles mantém controle dos problemas de segurança, podem ajudar mantenedores, corrigir os problemas, são responsáveis por enviar os avisos e manter o security.debian.org.
Observe que os avisos de segurança não são feitos apenas para releases, não apenas para testing, unstable (veja Como a segurança é tratada na testing e unstable?, Seção 11.3.7) ou distribuições antigas (veja Eu uso uma versão antiga da Debian, ela é suportada pelo time de segurança?, Seção 11.3.8).
Como um desenvolvedor toma conhecimento de um problema de segurança:
ele observa em um fórum público (mailing list, website, etc.):
alguém arquiva um bugreport (um tag Security deve ser usada, ou adicionada)
alguém o informa via email.
Nos dois primeiros casos a informação é pública e é importante ter uma correção o mais rápido possível. Em último caso porém ela pode não ser uma informação pública. Neste caso existem poucas opções para tratar o problema:
Se é um problema trivial (como arquivos inseguros temporários) não há necessidade de manter o problema secreto e a correção deve ser feita e lançada.
se o problema é grave (exploração remota, possibilitando adquirir privilégios de root) é preferível compartilhar a informação com outros vendedores e coordenar o lançamento. O time de segurança mantém contato com várias organizações e indivíduos e é cuidadoso com isto.
Em todos os casos, se a pessoa que reporta o problema pede para não divulgar a informação, deve ser respeitada, com execeção óbviade informar ao time de segurança (o desenvolvedor deve estar certo que ele disse ao time de segurança que a informação não deve ser divulgada).
Por favor observe que se o segredo é necessário o desenvolvedor pode também não atualizar uma correção para a unstable (ou qualquer outra), uma vez que o chagelog para a unstable é uma informação pública.
Existem duas razões para o lançamento da informação mesmo se o segredo é solicitado: o problema torna-se conhecido por muitos, ou a informação torna-se pública.
A mais importante guideline quando fazendo um novo pacote que corrige um problema de segurança é mazer o mínimo de alterações necessário. As pessoas sabem exatamente o comportamento de um lançamento, assim qualquer alteração feita pode quebrar o sistema de alguém. Isto é especialmente verdade para bibliotecas: o desenvolvedor deve estar certo de nunca alterar a API ou a ABI, mesmo que seja uma pequena mudança.
Isto significa que mudar para uma nova versão não é uma boa solução, em vez disto só as alterações relevantes devem ser feitas. Geralmente os mantenedores estão dispostos a ajudar que precisa, se não, o time de segurança da Debian pode.
Em alguns casos não é possível fazer o backport de uma correção de segurança, por exemplo quando uma grande quantidade do código fonte precisa ser modificado ou reescrito. Se isto acontece pode ser necessário mover para uma nova versão, mas isto deve sempre ser coordenado com o time de segurança.
Relacionado a isto existe outro importante aspecto: desenvolvedores devem sempre testar suas alterações. Se existe uma falha que permita exploração, o desenvolvedor deve testar e verificar se ela aconteceu em um pacote não corrigido ou em um pacote corrigido. O desenvolvedor deve tentar o uso normal também, algumas vezes uma correção de segurança pode quebrar o uso normal sutilmente.
Finalmente algumas coisas que os desenvolvedores devem ter em mente:
Esteja certo que você assinalou a distribuição correta em seu debian/changelog. Para a distrituição estável (stable) você deve assinalar como stable-security e para a distribuição em teste, testing-security. Não assinale <codename>-proposed-updates.
Verifique o número da versão. Ele deve ser maior que o pacote atual, mas menor que versões do pacote em distribuições anteriores. Para a distribuição testing isto sigfinifica que deve haver uma versão maior na distribuição unstable. Se ainda não existe (testing e unstable tem a mesma versão por exemplo) atualize a nova versão para a unstable primeiro.
Não faça atualizações source-only se seu pacote tem alguns pacotes binary-all. A infraestrutura de construção não construirá aqueles.
Quando compilar um pacote faço isto em um sistema limpo, o qual tem só tem
instalados pacotes da distribuição para a qual você está construindo. Se você
não tem um sistema assim pode tentar a debian.org machine (veja
http://db.debian.org/machines.cgi) ou configurar um chroot (os pacotes
pbuilder
e debootstrap
podem ajudar neste caso).
Após o desenvolvedor ter criado e testado um novo pacote ele precisa realizar o upload pois assim a correçaõ será instalada nos archives. Por segurança os arquivos para upload devem ser colocados em ftp://security.debian.org/pub/SecurityUploadQueue/ .
Uma vez que o upload foi aceito o pacote será automaticamente reconstruído para todas as arquiteturas e armazenado para verifiração pelo time de segurança.
Uploads aguardando por aceitação e verificação só são acessíveis pelo time de segurança. Isto é necessãrio uma vez que podem ser correções para problemas de segurança que ainda não foram descobertos.
SE um mebro do time de segurança aceita um pacote ele será instalado em security.debian.org assim como o apropriado <codename>-proposed-updates em ftp-master ou non-US archive.
Os avisos de segurança são escritos e postados pelo time de segurança. Porém, eles certamente não pensam se um mantenedor pode fornecer o texto para eles (pelo menos uma parte). As informações que devem fazer parte de um aviso são descritas em Debian Security Advisories, Seção 7.2.
Esta seção também pode ser chamada "como atualizar seu sistema Debian GNU/Linux em segurança" e mereçe sua própria seção basicamente porque é uma parte importante da infraestrutura de segurança. Assinatura de pacote é uma coisa importante porque evita alterações de pacotes distribuídos em mirros. Atualização automatica de software é um recurso importante mas também é importante remover ameaças de segurança que poderiam ajudar a distribuir cavalos de tróia e comprometer os sistemas durante as atualizações. [35].
Atualmente (maio de 2005) o Debian não fornece assinatura de pacotes para as distribuições lançadas woody ou sarge (3.0 ou 3.1). Elas não possuem este recurso. Existe uma solução para isto que será fornecida na próxima distribuição (codename etch). Este novo recurso estará disponível no apt 0.6 (atualmente disponível numa distribuição experimental, veja Pacotes experimentais apt, Seção 7.4.4).
Isto é melhor descrito em Strong
Distribution HOWTO
por V. Alex Brennen.
O esquema atual para checagem da assinatura dos pacotes usando apt
é:
o arquivo lançado incluirá o md5sum do Packages.gz (que contém os md5sum dos pacotes) e será assinado. A assinatura é de uma fonte certificada.
A arquivo assinado é baixado pelo 'apt-get update' a armazenado com o Packages.gz.
Quando o pacote está sendo instalado, ele primeiro é baixado, então o md5sum é gerado.
A assinatura é checada (assinatura ok) e extraído o md5sum do arquivo Pakages.gz, este por sua vez é gerado e (se ok) o md5sum do pacote baixado é extraído.
Se o md5sum do pacote baixado é o mesmo que o do Packages.gz, o pacote será instalado. Caso contrário o administrador será alertado e o pacote será colocado num cache (e o administrador pode decidir se instalará o pacote ou não). Se o pacote não estiver no Packages.gz e o administrador tiver configurado o sistema para só instalar pacotes checados, o pacote não será instalado.
A sequência seguinte de checagens MD5 do apt
é capaz de verificar
se o pacote origina de um release específico. Isto é menos flexível que a
assinatura de cada pacote, mas pode ser combinada com este esquema também (veja
abaixo).
Atualmente, este esquema é fully
implemented
no apt 0.6 par mais informações veja Pacotes experimentais apt, Seção 7.4.4. Pacotes que
fornecem um front-end para o apt precisam ser modificados para adaptar este
novo recurso, isto é o caso do aptitude
o qual tem feito modified
para adaptar-se a este esquema.
Assinatura de pacotes foi discutido no Debian por um bom tempo, para mais
informações leia: http://www.debian.org/News/weekly/2001/8/
e http://www.debian.org/News/weekly/2000/11/
.
Caso você queira adicionar os novos recursos de checagem de segurança e não queira rodar a versão experimental do apt (embora nõs realmente apreciemos o teste dele) você pode usar o script abaixo, fornecido por Anthony Towns. Este script pode automaticamente fazer algumas novas checagens de segurança para permitir ao usuário certificar-se que o software que está baixando corresponde aquele distribuído pelo Debian. Isto é para desenvolvedores Debian usarem em sistemas sem a funcionalidade de uploading dos sistemas tradicionais, ou mirrors que tem quase tudo mas não como o Debian, ou mirrors que fornecem dados da versão unstable sem conhecimento dos problemas de segurança.
Este código, renomeado como apt-check-sigs
, deve ser usado da
seguinte maneira:
# apt-get update # apt-check-sigs (...resultados...) # apt-get dist-upgrade
Primeiro você precisa:
pagar as chaves para assinar os Release files, http://ftp-master.debian.org/ziyi_key_2003.asc
e adicioná-las a ~/.gnupg/trustedkeys.gpg
(que gpgv
usa por padrão).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2003.asc
remover qualquer linha do /etc/apt/sources.list
que não usa a
estrutura normal de "dist", ou alterar o script para ele trabalhe com
elas.
estar preparado para ignorar o fato que o Debian security updates não assinou os Release files, e que os Sources files não tem os checksums apropriados no Release file (ainda).
estar preparado para checar se as fontes estão assinadas com as chaves apropriadas.
Este é o código de exemplo do apt-check-sigs
, a última versão pode
ser conseguida de http://people.debian.org/~ajt/apt-check-sigs
.
Este código atualmente está em beta, para mais informações leia http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html
.
#!/bin/bash # Copyright (c) 2001 Anthony Towns <ajt@debian.org> # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. rm -rf /tmp/apt-release-check mkdir /tmp/apt-release-check || exit 1 cd /tmp/apt-release-check >OK >MISSING >NOCHECK >BAD arch=`dpkg --print-installation-architecture` am_root () { [ `id -u` -eq 0 ] } get_md5sumsize () { cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { print "$f[1] $f[2]\n"; exit(0); }' } checkit () { local FILE="$1" local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then # No file, but not needed anyway echo "OK" return fi echo "$FILE" >>MISSING echo "MISSING $Y" return fi if [ "$Y" = "" ]; then echo "$FILE" >>NOCHECK echo "NOCHECK" return fi X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\ -f1` `wc -c < /var/lib /apt/lists/$FILE`" X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD" return fi echo "$FILE" >>OK echo "OK" } echo echo "Checking sources in /etc/apt/sources.list:" echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" echo (echo "You should take care to ensure that the distributions you're downloading " echo "are the ones you think you are downloading, and that they are as up to" echo "date as you would expect (testing and unstable should be no more than" echo "two or three days out of date, stable-updates no more than a few weeks" echo "or a month)." ) | fmt echo cat /etc/apt/sources.list | sed 's/^ *//' | grep '^[^#]' | while read ty url dist comps; do if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then baseurl="${url#*://}" else continue fi echo "Source: ${ty} ${url} ${dist} ${comps}" rm -f Release Release.gpg lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1 wget -q -O Release "${url}/dists/${dist}/Release" if ! grep -q '^' Release; then echo " * NO TOP-LEVEL Release FILE" >Release else origline=`sed -n 's/^Origin: *//p' Release | head -1` lablline=`sed -n 's/^Label: *//p' Release | head -1` suitline=`sed -n 's/^Suite: *//p' Release | head -1` codeline=`sed -n 's/^Codename: *//p' Release | head -1` dateline=`grep "^Date:" Release | head -1` dscrline=`grep "^Description:" Release | head -1` echo " o Origin: $origline/$lablline" echo " o Suite: $suitline/$codeline" echo " o $dateline" echo " o $dscrline" if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then echo " * WARNING: asked for $dist, got $suitline/$codeline" fi lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1 wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg" gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do if [ "$gpgcode" = "GOODSIG" ]; then if [ "$err" != "" ]; then echo " * Signed by ${err# } key: ${rest#* }" else echo " o Signed by: ${rest#* }" okay=1 fi err="" elif [ "$gpgcode" = "BADSIG" ]; then echo " * BAD SIGNATURE BY: ${rest#* }" err="" elif [ "$gpgcode" = "ERRSIG" ]; then echo " * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}" err="" elif [ "$gpgcode" = "SIGREVOKED" ]; then err="$err REVOKED" elif [ "$gpgcode" = "SIGEXPIRED" ]; then err="$err EXPIRED" fi done if [ "$okay" != 1 ]; then echo " * NO VALID SIGNATURE" >Release fi) fi okaycomps="" for comp in $comps; do if [ "$ty" = "deb" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH $comp ($X, $Y)" fi elif [ "$ty" = "deb-src" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH component $comp ($X, $Y)" fi fi done [ "$okaycomps" = "" ] || echo " o Okay:$okaycomps" echo done echo "Results" echo "~~~~~~~" echo allokay=true cd /tmp/apt-release-check diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED cd /tmp/apt-release-check if grep -q ^ UNVALIDATED; then allokay=false (echo "The following files in /var/lib/apt/lists have not been validated." echo "This could turn out to be a harmless indication that this script" echo "is buggy or out of date, or it could let trojaned packages get onto" echo "your system." ) | fmt echo sed 's/^/ /' < UNVALIDATED echo fi if grep -q ^ BAD; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists does not" echo "match what was expected. This may mean these sources are out of date," echo "that the archive is having problems, or that someone is actively" echo "using your mirror to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat BAD | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < BAD echo fi if grep -q ^ MISSING; then allokay=false (echo "The following files from /var/lib/apt/lists were missing. This" echo "may cause you to miss out on updates to some vulnerable packages." ) | fmt echo sed 's/^/ /' < MISSING echo fi if grep -q ^ NOCHECK; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists could not" echo "be validated due to the lack of a signed Release file, or the lack" echo "of an appropriate entry in a signed Release file. This probably" echo "means that the maintainers of these sources are slack, but may mean" echo "these sources are being actively used to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat NOCHECK | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < NOCHECK echo fi if $allokay; then echo 'Everything seems okay!' echo fi rm -rf /tmp/apt-release-check
Você pode precisar aplicar o seguinte patch para sid uma vez que
md5sum
adiciona um '-' após o sum quando a entrada é stdin:
@@ -37,7 +37,7 @@ local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" - Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" + Y="`echo "$Y" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then @@ -55,7 +55,7 @@ return fi X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`" - X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" + X="`echo "$X" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD"
The additional scheme of signing each and every packages allows packages to be checked when they are no longer referenced by an existing Packages file, and also third-party packages where no Packages ever existed for them can be also used in Debian but will not be default scheme.
Este esquema de assinatura pode ser implementado usando
debsig-verify
e debsigs
. Estes dois pacotes podem
assinar e verificar assinaturas embutidas em pacotes .deb. Debian já tem a
capacidade de fazer sito, mas a implementação de policiamento e ferramentas não
será iniciada até as releases posteriores ao woody.
As últimas versões do dpkg (a partir de 1.9.21) incorporam um patch
que fornece esta funcionalidade tão logo debsig-verify
seja
instalado.
NOTA: Atualmente /etc/dpkg/dpkg.cfg
trabalha com
"no-debsig" como padrão.
NOTA 2: Signatures from developers are currently stripped when they enter off the package archive since the currently preferred method is release checks as described previously.
O release do apt 0.6 inclui apt-secure que é uma ferramenta que
permitirá a um administrador de sistema testar a integridade dos pacotes
baixados através do esquema acima. Esta release inclui a ferramenta
apt-key
para adicionar novas chaves ao chaveiro do apt, o qual por
padrão inclui apenas o arquivo de assinatura de chaves atual do Debian.
Se quer testar este recurso você precisa adicionar a distribuição experimental
ao seu sources.list
e rodar
# apt-get -t experimental install apt
Estas alterações são baseadas no patch para apt
(disponível em
Bug
#203741
) o qual fornece esta implementação.
Este recurso ainda está em desenvolvimento, se você acredita que pode encontrar
bugs nele por favor tenha certeza que está usando a última versão e, se estiver
rodando a última versão, envie o bug para o pacote apt
package
usando a tag experimental.
Observe que, usar esta versão experimental do apt não exige nada mais de sua
parte a menos que você não use sources Debian, neste caso um passo extra de
confirmação será requerido pelo apt-get. Isto é evitado fornecendo Release e
Release.gpg em non-Debian sources. O arquivo Release pode ser gerado com
apt-ftparchive
(disponível em apt-utils 0.5.0 e posteriores), o
Release.gpg é apenas uma assinatura destacada. Para gerar ambos siga este
simples procedimento:
$ rm -f dists/unstable/Release $ apt-ftparchive release dists/unstable > dists/unstable/Release $ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Securing Debian Manual
v3.1,mailto:jfs@debian.org