"Segurança Baseada no Processador" em sistemas GNU/Linux

[alexandre.mbm]

Existe o tópico "Segurança Baseada no Processador", de 2005. O moderador global JoseMelo orientou-me a criar este tópico.

Não é fácil encontrar a informação no Google. "Linux gets trial 'NX' security support" é de 2004. Quero saber como as distros atuais estão lidando com o recurso. Se é coisa de kernel, como está com ele, então?

[Édnei Rodrigues]

Interessante você perguntar isso, pois no mundo Linux/Unix é muito raro um vírus aparecer.

Mesmo assim, esse recurso foi incorporado em 2004, desde a versão 2.6.8 do kernel. Porém, isso não vem ativado por default.

O NX bit é um recurso de hardware e, assim, as distribuições desenvolvem pacotes que utilizam deste recurso, dando outros nomes para esse tipo de proteção. Ex.: Exec Shield da Red Hat;

[alexandre.mbm]

Como eu sei se o recurso está ativado?

[Édnei Rodrigues]

Qual é a versão do teu linux ?

[alexandre.mbm]

Ubuntu 12.04.3 LTS, kernel Linux 3.5.0-40-generic.

[furadordesys]

interessante esse recurso até vou acompanhar esse tópico para ver no que vai dar!!!

[Fernando Mercês]

Olá, alexandre.mbm!

O assunto é longo. Tem que haver suporte real no kernel e o BIOS pode desabilitar por padrão (pra kernels antigos). No Ubuntu uma mensagem é emitida quando a máquina inicia, então você, se já estiver com ela ligada, pode testar com:

$ dmesg | grep -Fw NX

Se a reposta for algo como abaixo, o NX real está ativo em seu sistema.

[ 0.000000] NX (Execute Disable) protection: active

O Ubuntu também pode emular o NX para kernels/processadores sem suporte. Tá tudo explicado em https://wiki.ubuntu.com/Security/Features#nx

Para ver se o processador tem suporte, pode usar:

$ grep -Fwm1 nx /proc/cpuinfo

Se ele tiver suporte mas não estiver ativado no sistema, cola a saída do uname -a pra gente saber o kernel que está usando aí (incluindo a arquitetura).

Abraço.

[alexandre.mbm]

No Ubuntu uma mensagem é emitida quando a máquina inicia, então você, se já estiver com ela ligada, pode testar com:

$ dmesg | grep -Fw NX

alexandre$ dmesg | grep -Fw NX

alexandre$

Nada!

Se ele tiver suporte mas não estiver ativado no sistema, cola a saída do uname -a pra gente saber o kernel que está usando aí (incluindo a arquitetura).

alexandre$ grep -Fwm1 nx /proc/cpuinfo

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow vnmi flexpriority

alexandre$

Então:

alexandre$ uname -a

Linux alexandre-desktop 3.5.0-40-generic #62~precise1-Ubuntu SMP Fri Aug 23 17:59:10 UTC 2013 i686 i686 i386 GNU/Linux

alexandre$

[Fernando Mercês]

Opa, bom dia!

Estranho não aparecer nada. Tenta:

$ grep -Fw NX /var/log/kern.log

No link que passei tem um script, test-kernel-security.py, para testar este suporte. Seria legal baixar e rodá-lo.

Abraços!

[alexandre.mbm]

Estranho não aparecer nada. Tenta:

$ grep -Fw NX /var/log/kern.log

alexandre$ grep -Fw NX /var/log/kern.log

Sep 24 08:30:20 alexandre-desktop kernel: [ 0.000000] NX (Execute Disable) protection: active

Sep 24 08:30:20 alexandre-desktop kernel: [ 2.326221] NX-protecting the kernel data: 4180k

alexandre$

No link que passei tem um script, test-kernel-security.py, para testar este suporte. Seria legal baixar e rodá-lo.

test-kernel-security.py (visualizar, download)

Após "passar o olho" em todo o código do script, para ter noção do que ele faz (afinal, é executado com sudo e tem 1547 linhas), executei-o.

alexandre$ sudo python test-kernel-security.py

[sudo] password for alexandre:

Traceback (most recent call last):

File "test-kernel-security.py", line 49, in <module>

import testlib

ImportError: No module named testlib

alexandre$

testlib.py (visualizar, download)

Com esses dois arquivos .py no mesmo diretório, aconteceram 52 erros de execução do script. Começou assim:

alexandre$ sudo python test-kernel-security.py EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

======================================================================

ERROR: test_000_make (__main__.KernelSecurityTest)

Prepare to build helper tools

----------------------------------------------------------------------

Traceback (most recent call last):

File "test-kernel-security.py", line 63, in setUp

os.chdir('kernel-security')

OSError: [Errno 2] No such file or directory: 'kernel-security'

O erro OSError: [Errno 2] No such file or directory: 'kernel-security' se repetiu as 52 vezes, acho. Isso me faz crer que eu teria de instalar todo o código de ~ubuntu-bugcontrol/qa-regression-testing/master.

Vou ver o que faço por aqui e retorno mais tarde.

Editado quinta-feira, 26 de Setembro de 2012, às 16h43:

O comando bzr branch lp:qa-regression-testing estava muito demorado. Algo parecia errado. Não domino o processo. Então eu havia já havia desistido. Mas resolvi tentar novamente:

alexandre$ bzr branch lp:qa-regression-testing

You have not informed bzr of your Launchpad ID, and you must do this to

write to Launchpad or access private data. See "bzr help launchpad-login".

Revisões 1999 ramificadas.

alexandre$

Era por isso que estava demorando:

alexandre$ du -sh qa-regression-testing/

636M qa-regression-testing/

alexandre$

Retorno mais tarde. Devo mover esses arquivos para fora do /home. Estão ocupando espaço demais.

Editado quinta-feira, 26 de Setembro de 2012, às 17h04:

Nota: eu sei que o camando grep -Fw NX /var/log/kern.log já nos respondeu, mas eu quero conhecer o projeto qa-regression-testing.

Editado quinta-feira, 26 de Setembro de 2012, às 17h25:

Agora sim!

alexandre$ pwd

/media/41 GB em ext3/Bazaar/qa-regression-testing/scripts

alexandre$ sudo python test-kernel-security.py

[sudo] password for alexandre:

FF..............F.............F.....................

[a saída aqui foi longa! omiti. concluiu com:]

----------------------------------------------------------------------

Ran 52 tests in 31.660s

FAILED (failures=4)

alexandre$

Uma dessas falhas refere-se ao NX (mas observe o negrito):

======================================================================

FAIL: test_060_nx (__main__.KernelSecurityTest)

NX bit is working

----------------------------------------------------------------------

Traceback (most recent call last):

File "test-kernel-security.py", line 490, in test_060_nx

self.assertShellExitEquals(0, ["make"])

File "/media/41 GB em ext3/Bazaar/qa-regression-testing/scripts/testlib.py", line 970, in assertShellExitEquals

self.assertEquals(expected, rc, msg + result + report)

AssertionError: Got exit code 2, expected 0

Command: 'make'

Output:

cc -g -Wall -Werror -Wformat -Wformat-security -O0 nx-test.c -o nx-test

cc -g -Wall -Werror -Wformat -Wformat-security -O0 -fPIE -pie -o nx-test-pie nx-test.c

cp nx-test nx-test-rie.tmp

execstack -s nx-test-rie.tmp

make: execstack: Comando não encontrado

make: ** [nx-test-rie] Erro 127

======================================================================

Muito obrigado, Fernando Mercês!

[Fernando Mercês]

alexandre$ grep -Fw NX /var/log/kern.log

Sep 24 08:30:20 alexandre-desktop kernel: [ 0.000000] NX (Execute Disable) protection: active

Sep 24 08:30:20 alexandre-desktop kernel: [ 2.326221] NX-protecting the kernel data: 4180k

alexandre$

Tá explicado, hehe. Parece que seu PC tá ligado desde terça-feira, mas tá aí a mensagem do NX bit ativado.

Trabalheira com o script hein? Mas no final deu tudo certo. Abraços!

[alexandre.mbm]

Tá explicado, hehe. Parece que seu PC tá ligado desde terça-feira, mas tá aí a mensagem do NX bit ativado.

Usamos "Suspender" mais frenquentemente do que "Desligar". Ambiente doméstico multiusuário.

Trabalheira com o script hein? Mas no final deu tudo certo. Abraços!

Quero só alertar ao pessoal que usar do conhecimento do tópico:

No final, eu acabei me dando ao luxo — ou melhor: risco! — de executar milhares de linhas de script como administrador, com o sudo, sem checar o que realmente aqueles códigos fazem. Mais do que as 1547 iniciais. Porque resolvi "confiar" no time daquele projeto. Isso não é recomendado em ambientes que exijam mais controle e segurança.

O ideal é que o responsável pela segurança entenda de TUDO que está envolvido.

Aos moderadores:

Eu considero que o tópico não deve ser fechado. Ficaram questões menores pendentes. Outra coisa: a "solução" foi alcançada em ambiente Ubuntu, enquanto o tópico expande o contexto para sistemas GNU/Linux.