Arch package guidelines (Português)/Security (Português)

From ArchWiki
Jump to navigation Jump to search
Status de tradução: Esse artigo é uma tradução de Arch package guidelines/Security. Data da última tradução: 2020-06-15. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Esta página descreve as diretrizes de empacotamento de segurança para pacotes do Arch Linux. Para projetos C/C++, o compilador e o vinculador podem aplicar opções de proteção de segurança. O Arch Linux, por padrão, aplica PIE, fonte Fortify, protetor de pilha, nx e relro. As proteções hardening podem ser revisadas executando checksec.

$ checksec --file=/usr/bin/cat

RELRO

O RELRO é uma técnica genérica de mitigação para proteger as seções de dados de um processo/binário ELF. Quando um programa é carregado, várias seções da memória ELF precisam ser gravadas pelo vinculador. mas pode ser ativado como somente leitura antes de passar o controle para o programa. Isso evita que os invasores substituam algumas seções da ELF. Existem dois modos RELRO diferentes:

  • Partial RELRO (-Wl,-z,relro): algumas seções são marcadas como somente leitura após o carregamento do programa, exceto que o GOT (.got.plt) ainda pode ser gravado.
  • Full RELRO (-Wl,-z,now) durante o carregamento do programa, todos os símbolos dinâmicos são resolvidos, permitindo que o GOT completo seja marcado como somente leitura.

Se um aplicativo relatar relro parcial, investigue se a cadeia de ferramentas de compilação passa nossos LDFLAGS ou permite substituir LDFLAGS. Para os pacotes Go, investigue se o método de compilação usa "build.go" como uma substituição pura do Makefile golang, que não permite a passagem de LDFLAGS.

Haskell

Para Haskell, não está claro como alcançar o Full RELRO no momento.

Stack Canary

Um stack canary é adicionado pelo compilador entre o buffer e os dados de controle na pilha. Se esse valor conhecido estiver corrompido, ocorreu um estouro de buffer e o programa em execução é segmentado para impedir uma possível execução arbitrária do código.

O pacote gcc ativou a proteção de pilha por padrão com o --enable-default-ssp opção de compilação.

NX

C/C++

A proteção do espaço executável marca as regiões da memória como não executáveis, de modo que uma tentativa de executar o código da máquina nessas regiões causará uma exceção. Ele utiliza recursos de hardware como o bit NX (bit sem execução) ou, em alguns casos, emulação de software desses recursos.

PIE

C/C++

O pacote gcc o tem habilitado por padrão para C/C++ com --enable-default-pie.

Golang

Passe os seguintes sinalizadores para go build

export GOFLAGS='-buildmode=pie'
export CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2"
export CGO_LDFLAGS="-Wl,-z,relro,-z,now"

Haskell

Passe o seguinte sinalizador para a configuração de runhaskell Setup:

--ghc-option='-pie'

RPATH/RUNPATH

RUNPATH/RPATH fornece outros caminhos de pesquisa para o objeto em que está listado (pode ser usado para objetos executáveis e compartilhados).

$ objdump -x /usr/bin/perl | egrep 'RPATH|RUNPATH'

Se o valor RPATH contiver um caminho dentro do controle de um invasor, ele poderá executar o código instalando uma biblioteca maliciosa nesse diretório. Por exemplo, CVE-2006-1566 e CVE-2005-4280.

A entrada RPATH é configurada pelo vinculador, passando, por exemplo, a seguinte string para LDFLAGS -Wl, -rpath -Wl,/usr/local/lib. Para fazer uma entrada de RUNPATH, anexe --enable-new-dtags aos sinalizadores do vinculador.

FORTIFY

A fonte Fortify é uma macro que adiciona proteção contra estouro de buffer (buffer overflow) em várias funções que executam operações na memória e nas strings. Ele verifica se um invasor tenta copiar mais bytes para estourar um buffer e interrompe a execução do programa. Essa proteção é ativada com o CPPFLAGS padrão em makepkg.conf:

CPPFLAGS="-D_FORTIFY_SOURCE=2"

Serviços systemd

Se um arquivo de serviço do systemd for enviado com o pacote devido à falta de fornecimento do upstream, aplique os seguintes recursos de proteção de serviço do systemd. O systemd fornece uma maneira de analisar os recursos de segurança habilitados para um serviço.

$ systemd-analyze security pacman.service

Acesso de arquivos

Um serviço pode ser protegido restringindo o acesso ao sistema de arquivos.

Configure um novo espaço de nomes do sistema fiel para o processo executado e que monta os diretórios /tmp e /var/tmp privados dentro dele que não são compartilhados pelos processos

PrivateTmp=true

O ProtectSystem possui três variedades diferentes de diretórios de montagem como somente leitura para o processo executado. A opção full monta /usr, /boot e /etc como somente leitura. O ProtectHome torna /home, /root e /run/user\ inacessíveis ao processo executado.

ProtectSystem=strict
ProtectHome=true

Configure um novo espaço de nomes /dev para o processo executado e adiciona apenas pseudodispositivos API como /dev/null, /dev/zero ou /dev/random, mas não para dispositivos físicos ou memória do sistema, portas do sistema e outros. Isso é útil para impedir que o processo de execução seja gravado diretamente em dispositivos físicos, o systemd também adiciona um filtro de chamadas do sistema para chamadas dentro do conjunto @raw-io.

PrivateDevices=true

Essas opções impendem o processo executado de alterar as variáveis do kernel acessíveis por meio de /proc/sys, /sys etc. ProtectControlGroups torna a hierarquia de /sys/fs/cgroup somente leitura.

ProtectKernelTunables=true
ProtectControlGroups=true

Informações mais detalhadas podem ser encontradas em systemd.exec(5).

Usuário

Certifique-se que o processo executado e seus filhos nunca possam obter novos privilégios por meio do execve().

NoNewPrivileges=true

Memória

Proíba tentativas de criar mapeamentos de memória que sejam graváveis e executáveis, alterar os mapeamentos para executáveis ou criar memória compartilhada executável. Isso protege um processo contra a permissão de um invasor na memória, que também é executada. Observe que ativar isso não é compatível com todos os aplicativos que dependem de JIT.

MemoryDenyWriteExecute=true

Chamadas de sistema

Bloqueia a chamada de sistema personality(2) para que o domínio de execução do kernel não possa ser alterado.

LockPersonality=true

As chamadas de sistema também podem ser restritas em um serviço, o systemd pode exibir chamadas de sistema para filtrar:

$ systemd-analyze syscall-filter

Grupos predefinidos estão disponíveis, por exemplo, para usar o ponto de partida recomendado para chamadas de sistema na lista de permissões para serviços do sistema:

SystemCallFilter=@system-service

Rede

Se o processo em execução não exigir acesso à rede, este acesso pode ser totalmente desativado, configurando um novo espaço de nomes de rede para o processo e configurando apenas uma interface de loopback.

PrivateNetwork=true

Se a rede for necessária, o tipo de família de endereços usado pode ser restrito para a chamada de sistema socket(2), permitindo, por exemplo, apenas soquetes UNIX.

RestrictAddressFamilies=AF_UNIX

Quando é necessária apenas a rede para o localhost ou intervalos de IP específicos, um processo pode ser restringido, permitindo apenas o acesso da rede ao localhost.

IPAddressAllow=localhost
IPAddressDeny=any

Mais informações sobre filtragem de rede pode ser encontrada em systemd.resource-control(5).

Várias

Configura um novo espaço de nomes UTS para o processo de execução e não permite alterar o nome de host ou o nome de domínio.

ProtectHostname=true