[ 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
Capítulo 7 - Infraestrutura do Debian Security


7.1 O time Debian Security

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:

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.


7.2 Debian Security Advisories

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:

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.


7.2.1 Referências sobre vulnerabilidades

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:


7.2.2 Compatibilidade CVE

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:


7.3 Infraestrutura da segurança Debian

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"):

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.


7.3.1 Guia dos desenvolvedores de atualizações de seguranaça

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.


7.3.1.1 Coordenando com o time de segurança

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).


7.3.1.2 Tomando conhecimento dos problemas de segurança

Como um desenvolvedor toma conhecimento de um problema de segurança:

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:

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.


7.3.1.3 Construindo um pacote

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:


7.3.1.4 Realizando o uplaod com as correções de segurança

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.


7.3.1.5 O aviso de segurança

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.


7.4 Assinatura de pacote no Debian

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.


7.4.1 O esquema proposto para checagem de assinatura dos pacotes

O esquema atual para checagem da assinatura dos pacotes usando apt é:

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/.


7.4.2 Checando releases das distribuições

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:

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"

7.4.3 Esquema alternativo de assinatura per-package

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.


7.4.4 Pacotes experimentais apt

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, Mon, 10 Feb 2014 17:06:00 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Autores, Seção 1.1