cada sistema precisa de processos em execução para cumprir o seu objectivo principal. Mas às vezes as coisas correm mal e um processo pode falhar. Dependendo da configuração do sistema, um dump do núcleo é criado. Em outras palavras, um instantâneo de memória do processo estoirado é armazenado. O termo núcleo na verdade se refere à memória do núcleo magnético antigo de sistemas mais antigos. Embora este tipo de memória não esteja mais sendo usado, nós ainda usamos este termo em sistemas Linux. O suficiente para a história, vamos configurar o nosso sistema Linux para lidar adequadamente com dumps de núcleo.
Índice
Linux e core dumps
a maioria dos sistemas Linux têm dumps de core ativados por padrão. Como sempre, há uma troca a fazer aqui. Por um lado, queremos recolher dados para melhorar a estabilidade e resolução de problemas. Por outro lado, queremos limitar os dados de depuração e evitar a fuga de dados sensíveis.
a primeira opção é boa para máquinas onde programas instáveis precisam ser investigados, como a estação de trabalho de um desenvolvedor. A segunda opção é mais adequada para sistemas de produção de armazenamento ou processamento de dados sensíveis.
desactiva os dumps de core
faz sentido desactivar qualquer dumps de core no Linux por omissão para todos os seus sistemas. Isto é porque os arquivos ocupam o espaço em disco e podem conter dados sensíveis. Então, se você não precisa do núcleo dumps para propósitos de solução de problemas, desativá-los é uma opção segura.
Opção 1: ulimit através do ficheiro de configuração
para desactivar os ‘dumps’ do core precisamos de definir um valor ulimit. Isto é feito através dos/etc/security / limits.conf file e define algumas restrições específicas da shell.É bom saber que existem limites macios e duros. Um limite rígido é algo que nunca pode ser superado, enquanto um limite suave só pode ser aplicável para usuários específicos. Se quisermos garantir que nenhum processo possa criar um dump Central, podemos definir ambos como zero. Embora possa parecer um booleano (0 = falso, 1 = verdadeiro), ele realmente indica o tamanho permitido.
* núcleo mole 0
* núcleo duro 0
o sinal asterisco significa que se aplica a todos os utilizadores. A segunda coluna indica se queremos usar um limite duro ou suave, seguido pelas colunas indicando a configuração e o valor.
Opção 2: Configurar o ulimit através do perfil
os valores para o ulimit também podem ser definidos via /etc/profile ou um ficheiro personalizado no /etc/profile.d directory. Este último é preferido quando está disponível. Por exemplo, se criar um arquivo chamado /etc/profile.d/disable-coredumps.sh.
echo “ulimit -c 0 > /dev/null 2>&1” > /etc/profile.d / disable-coredumps.sh
este comando adiciona a configuração a um novo ficheiro e define o limite suave e duro como zero. Cada usuário recebe este valor ao entrar.
além das configurações do ulimit, também há configurações do kernel a considerar. Então escolher uma das opções é o primeiro passo.
Opção 3: desactivar via systemd
ao usar systemd e o serviço systemd-coredump, mude o coredump.ficheiro conf. Este ficheiro está provavelmente localizado em /usr/lib / sysctl.D / 50-coredump.conf. Como o systemd tem um conjunto de arquivos, certifique-se de verificar os outros como:
configure a opção de armazenamento como “nenhuma”. Em seguida, configurar ProcessSizeMax para limitar o tamanho máximo a zero.
armazenagem = nenhuma
ProcessSizeMax=0
tipicamente é suficiente apenas recarregar a configuração do systemd.
systemctl daemon-reload
se isto ainda cria um dump do núcleo, então reinicie o sistema.
Disable setuid processes dumping their memory
Processes with elevated permissions( or the setuid bit), might still be able to perform a core dump, depending on your other settings. Como esses processos geralmente têm mais acesso, eles podem conter segmentos de dados mais sensíveis na memória. Então, está na hora de mudar isso também. O comportamento pode ser alterado com uma chave sysctl, ou diretamente através do sistema de arquivos /proc. Para Configurações permanentes, o comando e configuração do sysctl é tipicamente usado. Uma configuração é chamada de “chave”, que tem um valor relacionado ligado a ela (também conhecido como um par de valores-chave).
para desactivar o programa com o bit setuid para despejar, defina o fs.suid_dumpable a zero.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
recarrega a configuração do sysctl com a bandeira-p para activar quaisquer alterações que tenha feito.
sysctl -p
só quer testar sem fazer mudanças permanentes? Use sysctl -w seguido da chave=valor.
dica: usando o sysctl você pode sintonizar o seu sistema e é uma boa maneira de endurecer o kernel Linux.
active core dumps
a principal razão para permitir dumps core é para fins de resolução de problemas. A memória descartada do processo pode ser usada para problemas de depuração, geralmente por desenvolvedores mais experientes. Um fornecedor de software pode pedir para habilitar dumps core. Geralmente para descobrir por que um processo caiu em primeiro lugar e encontrar a rotina relacionada que causou isso.
ativar dumps de núcleo no Linux é semelhante a desativá-los, exceto que alguns detalhes específicos devem ser configurados. Por exemplo, se você só precisa de detalhes de um programa em particular, você pode usar limites suaves. Isto é feito usando -So que indica que é um limite suave. O -c denota o tamanho de uma lixeira do núcleo.
ulimit -S -c 0
o próximo passo é permitir que o ‘my-program-to-troubleshoot’ crie um dump do núcleo.
ulimit -S -c unlimited my-program-to-troubleshoot
Se você quiser permitir que todos os processos de utilizar os despejos de memória, utilize a linha acima sem o programa, ou definir um limite de sistema em /etc/security/limites.conf
* soft core unlimited
Troubleshoot setuid binários
binários que têm um conjunto de bits setuid, podem ser executados com permissões de raiz. Este tipo especial de acesso deve ser restringido tanto quanto possível. Também para a criação de dumps de núcleo, ele precisa ser configurado corretamente. Isto é feito com o sysctl fs.chave suid_dumpable.
- 0 – desactivada
- 1-activada
- 2-activada com restrições
por isso, se quiser resolver os programas com um conjunto de bits setuid, poderá alterar temporariamente a fs.suid_dumpable para 1 ou 2. Configurá-lo para 2 é preferido, uma vez que isso faz com que o core dumps só seja legível para o usuário root. Esta é uma boa alternativa para sistemas com dados sensíveis. Definir a opção para 1 é mais adequado para os sistemas de desenvolvimento pessoal.
criar arquivos de descarga normal
um dos grandes mistérios com sistemas Linux é onde os dumps de núcleo estão localizados. O Linux tem um truque no lugar para capturar dumps de núcleo. Esta configuração em particular é feita através do kernel sysctl.core_pattern setting or/proc/sys/kernel / core_pattern. A maioria dos sistemas terá um pipe (|) nesta configuração para indicar que um programa precisa cuidar dos dados gerados. Por isso, se queres saber para onde vai a tua lixeira, segue o cano!
os dumps de núcleo em sistemas Ubuntu são tipicamente para aportar. Para sistemas baseados em Chapéu Vermelho, ele pode ser redirecionado para a ferramenta automática de relatórios de bugs (ABRT).
pode alterar temporariamente esta configuração, ecoando “core” para esse ficheiro, ou usar o utilitário sysctl.
sysctl -w kernel.core_pattern=core
uma nota importante é que esta mudança pode não ser suficiente. Depende também do teu fs.configuração suid_dumpable. Um aviso será conectado ao seu logger de kernel, se for esse o caso.
Sep 06 15:51:18 núcleo endurecedor: core_ prattern inseguro usado com suid_dumpable=2. Tratamento de tubagens ou localização de dump do core totalmente qualificada necessária.
quando necessário, defina o seu core_pattern para um caminho completo, opcionalmente com variáveis que definem quem estava a executá-lo, o PID, etc.
kernel sysctl-W.core_pattern = /var/crash / core.%U.%E. % p
neste exemplo, os nossos resultados conterão o id do utilizador, o nome do programa e o id do processo.
os dumps de núcleo do Systemd
quando usar uma distribuição Linux moderna, provavelmente terá o systemd activo. Poderá ter de anular a configuração através do /etc/sysctl.D / 50-coredump.conf e definir como e onde você quer armazenar seus resíduos de núcleo.
usando systemd-coredump
o seu núcleo.core_pattern pode ser definido para usar o utilitário systemd-coredump. O caminho padrão onde os dumps do núcleo são armazenados é então em /var/lib/systemd / coredump.
testar a sua configuração
a maioria dos outros tutoriais Apenas lhe dão a configuração a configurar. Mas como é que sabes que as coisas funcionam como esperado? Você vai precisar testá-lo!
Create a core dump
Opção 1: Create an unstable program
Let’s create a simple program. Seu objetivo principal é bater quando está sendo executado e, em seguida, opcionalmente, criar um dump core. Instale o gcc no seu sistema e crie um estoiro de ficheiros.c na sua pasta pessoal.
int main(){ return 1/0;}
este programa irá iniciar a função principal e retornar um valor inteiro (número). No entanto, está dividindo 1 por zero, o que não é permitido e vai cair. O próximo passo é compilar o nosso pequeno programa de buggy.
nosso pequeno programa instável
até mesmo o compilador mostra que nosso programa contém um problema sério e exibe um aviso sobre ele. Vamos ver se é este o caso.
um belo acidente!
a partir desta única linha, podemos realmente aprender algumas coisas. Em primeiro lugar, que ele saiu com uma exceção, especificamente referindo-se a pontos flutuantes. Este é um formato de número decimal para programas, por isso pode indicar que algo aconteceu enquanto fazia alguma matemática. Outra conclusão é que o núcleo é objeto de dumping devido à adição (do núcleo objeto de dumping) no final. Se as lixeiras do núcleo fossem desactivadas, isto não apareceria.Óptimo, então com este acidente por cima temos agora um ficheiro abandonado, certo? Não exactamente. Dependendo de sua distribuição Linux coisas podem não tão simples como parece. Cada distribuição lida de forma diferente com os dumps do core e as configurações padrão. As distribuições Linux mais recentes também usam o systemd agora e as regras foram ligeiramente alteradas com isso também. Dependendo da sua configuração, você pode precisar procurar por seus dumps de núcleo. Então aqui estão algumas dicas para garantir que tudo está configurado corretamente.
Opção 2: matar um processo em execução
em Vez de usar um programa de teste, você também pode encerrar um processo existente. Isto é feito usando o SIGSEGV, que é o diminutivo de violação de segmentação e também conhecido como uma falha de segmentação.
kill -s SIGSEGV PID
se substituir o PID por”$$”, o programa actual (provavelmente a sua linha de comandos) irá estoirar. Tudo pela ciência, certo?
Opção 3: Usar o gdb
se tiver a ferramenta de depuração do programador, o gdb instalado, então anexar a um processo de escolha usando o seu ID de processo (PID).
gdb -p 1234
em seguida, quando na linha de comandos do gdb, gerar o dump core invocando a instrução gerar-core-file. Depois de usar este comando, ele deve devolver a saída.
núcleo do corefile gravado.1234
Verifique a configuração do ulimit
a configuração do ulimit define o que pode acontecer quando UM programa falha. Por isso, é Seguro verificar primeiro isto, tanto para o root como para um utilizador normal não privilegiado.
Verificar o limite rígido para despejos de memória:
ulimit -H -c
Verifique soft limit bem:
ulimit -S -c
Verifique o núcleo padrão
Utilizar o sistema de arquivos /proc, para recolher o valor e mudar temporariamente durante o teste. Se preferir usar o sysctl, então consulte o kernel.core_pattern key.
cat /proc/sys/kernel/core_pattern
Ele pode mostrar algo como isto:
|/usr/share/apport/apport %p %s %c %P
neste caso, um acidente vai ser canalizada para o apport utilitário. Então isso significa que os acidentes vão ser analisados por Apport. Normalmente acidentes são encontrados em /var/crash, mas também pode ser em /var/spool ou /var/lib/systemd/coredump em outras distribuições Linux.
verifique o diário (systemd)
no nosso caso journalctl mostra o nosso acidente, por isso é um começo.
depois de verificar todas estas configurações, você deve ser capaz de criar um bom dump core.
Conclusion
Core dumps can be useful for troubleshooting, but a disaster for leaking sensitive data. Desactivar os ‘dumps’ do núcleo quando possível, e só os activar quando realmente for necessário. Nesse caso, verifique se os arquivos são armazenados com segurança, de modo que os usuários normais não podem ver os dados. E independentemente da escolha que você fez, Sempre teste se sua configuração funciona exatamente como você espera que funcione.