Ir para o conteúdo
ou

Software livre Brasil

Tela cheia
 Feed RSS

Helio Loureiro

27 de Maio de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Resolvendo a baleiada do docker com exit code 139

21 de Setembro de 2020, 16:11, por Home - helio.loureiro.eng.br - 0sem comentários ainda

Esses dias precisei fazer uma migração de uma mediawiki que usamos na empresa de uma máquina que rodava CentOS 6.8 pra um Ubuntu 18.04.

Para garantir seu funcionamento, primeiro eu queria testar os upgrades necessários em minha máquina.  Nada melhor que copiar os arquivos e rodar a versão exata do site remoto com containers em docker.

Mas ao rodar o container... ele simplesmente saia com código de erro 139.  Mais nada.  Sem logs, sem describe, sem nada que pudesse ajudar.

~ > docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                        PORTS                  NAMES
8ffcdf12d761        centos:6.8          "bash"              52 minutes ago      Up 52 minutes                 0.0.0.0:8080->80/tcp   elated_ganguly
7bd9374248fd        centos:6.8          "bash"              56 minutes ago      Exited (139) 56 minutes ago                          dreamy_fermat
80ff07e9b84e        centos:6.8          "bash"              10 hours ago        Exited (139) 10 hours ago                            romantic_hertz
3db1d6c1f68b        centos:6            "bash"              10 hours ago        Exited (139) 10 hours ago                            bold_kilby

Olhando pela Internet, descobri em alguns sites pessoas relatando o mesmo problema.  É algo relacionado com a versão da glibc do container com a versão do kernel que estou rodando, que é muito mais novo:

 ~ > uname -a
Linux elxa7r5lmh2 5.9.0-rc5-helio #10 SMP Sat Sep 19 12:04:57 CEST 2020 x86_64 x86_64 x86_64 OSI/Linux

A solução é adicionar um parâmetro a mais no grub a opção "vsyscall=emulate":

~ > grep GRUB_CMDLINE_LINUX /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 pcie_aspm=off pci=nomsi vsyscall=emulate" 

e fazer um update no próprio grub.

~ > sudo update-grub2 && sudo reboot -f

Após um reboot os containers funcionaram sem problemas.

~ > docker run -it --rm=true centos:6.8 bash
[root@224aecaba978 /]# hostname
224aecaba978
[root@224aecaba978 /]# exit
exit
 ~ > docker ps -l
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                   PORTS               NAMES
ca68add255bd        ubuntu:18.04        "bash"              2 hours ago         Exited (1) 2 hours ago                       festive_galois
 ~ > 

Eu tentei configurar diretamente no kernel através da interface em /sys, mas eu só consegui com isso gerar um kernel panic.  O jeito mais fácil e seguro foi mesmo rebootando meu laptop.



A dica mais preciosa de shell scripts dos últimos tempos

19 de Setembro de 2020, 19:34, por Home - helio.loureiro.eng.br - 0sem comentários ainda

Entre os vários grupos do Telegram, um que é muito bom é o de shell, o t.me/shellbr pros mais íntimos.

Um dia desses, entre discussões de como fazer um shell melhor e eu postando sticker pros falantes de língua inglesa de que o grupo é em língua portuguesa, apareceu algo que abriu minha visão em shell pra algo muito maravilhoso.  Não é uma novidade de um comando mágico que faz algo completamente novo, mas a simplicidade da solução que esteve esse tempo todo na minha cara e eu nunca vi foi o que me fascinou.

Pra dar um pouco mais de contexto, o que se referia isso: quem nunca precisou mandar um "ps auxwww | grep firefox" e pegou o próprio comando grep na saída?

 ~> ps auxwww | grep firefox 
helio   5719 15.5  2.9 3994484 475156 ?      Rl   20:57   4:38 /usr/lib/firefox/firefox --ProfileManger --no-remote
helio   5815  6.0  1.6 3021712 259472 ?      Sl   20:58   1:47 /usr/lib/firefox/firefox -contentproc -childID 1 
helio   5876  1.0  1.2 2687192 201516 ?      Sl   20:58   0:18 /usr/lib/firefox/firefox -contentproc -childID 2 
helio   5916  0.5  1.0 2646492 161856 ?      Sl   20:58   0:10 /usr/lib/firefox/firefox -contentproc -childID 3 
helio   5939  5.8  2.0 3008700 325944 ?      Rl   20:58   1:44 /usr/lib/firefox/firefox -contentproc -childID 4 
helio   9210  1.0  1.5 2875692 241532 ?      Sl   21:08   0:12 /usr/lib/firefox/firefox -contentproc -childID 9 
helio  10161  1.5  1.1 2676620 179336 ?      Rl   21:11   0:15 /usr/lib/firefox/firefox -contentproc -childID 10 
helio  10394  0.2  0.7 2583360 120484 ?      Sl   21:12   0:02 /usr/lib/firefox/firefox -contentproc -childID 11 
helio  11818  0.0  0.4 2549948 77524 ?       Sl   21:18   0:00 /usr/lib/firefox/firefox -contentproc -childID 13 
helio  14368  0.0  0.0  18056  1052 pts/2    S+   21:27   0:00 grep --color=auto firefox

Comecei com Linux em 1997, quando aprendi a usar as Sparc stations da universidade.  Mais de 20 anos nessa indústria vital e eu sempre, sempre, usei desse jeito:

 ~ > ps auxwww | grep firefox | grep -v grep 
helio   5719 14.6  3.0 3991196 481364 ?      Sl   20:57   4:56 /usr/lib/firefox/firefox --ProfileManger --no-remote
helio   5815  6.2  1.7 3019784 279384 ?      Sl   20:58   2:05 /usr/lib/firefox/firefox -contentproc -childID 1 
helio   5876  0.9  1.2 2687192 202532 ?      Sl   20:58   0:19 /usr/lib/firefox/firefox -contentproc -childID 2 
helio   5916  0.5  1.0 2646492 164072 ?      Sl   20:58   0:10 /usr/lib/firefox/firefox -contentproc -childID 3 
helio   5939  5.4  2.0 3008700 330532 ?      Sl   20:58   1:49 /usr/lib/firefox/firefox -contentproc -childID 4 
helio   9210  0.9  1.5 2875692 241876 ?      Sl   21:08   0:13 /usr/lib/firefox/firefox -contentproc -childID 9 
helio  10161  1.3  1.1 2676620 179336 ?      Sl   21:11   0:16 /usr/lib/firefox/firefox -contentproc -childID 10 
helio  10394  0.2  0.7 2583360 120588 ?      Sl   21:12   0:02 /usr/lib/firefox/firefox -contentproc -childID 11 
helio  11818  0.0  0.4 2549948 77524 ?       Sl   21:18   0:00 /usr/lib/firefox/firefox -contentproc -childID 13 

Com essa maravilhosa dica do Hélio Campos, basta fazer assim:

 ~ > ps auxwww | grep [f]irefox
helio   5719 14.5  3.1 4005676 500088 ?      Sl   20:57   5:01 /usr/lib/firefox/firefox --ProfileManger --no-remote
helio   5815  6.7  1.8 3034264 293864 ?      Rl   20:58   2:18 /usr/lib/firefox/firefox -contentproc -childID 1 
helio   5876  0.9  1.2 2687192 203656 ?      Sl   20:58   0:19 /usr/lib/firefox/firefox -contentproc -childID 2 
helio   5916  0.5  1.0 2646492 164072 ?      Sl   20:58   0:10 /usr/lib/firefox/firefox -contentproc -childID 3 
helio   5939  5.3  2.0 3008700 331836 ?      Sl   20:58   1:51 /usr/lib/firefox/firefox -contentproc -childID 4 
helio   9210  0.9  1.5 2875692 241876 ?      Sl   21:08   0:14 /usr/lib/firefox/firefox -contentproc -childID 9 
helio  10161  1.3  1.1 2676620 179336 ?      Sl   21:11   0:17 /usr/lib/firefox/firefox -contentproc -childID 10 
helio  10394  0.2  0.7 2583360 120588 ?      Sl   21:12   0:02 /usr/lib/firefox/firefox -contentproc -childID 11 
helio  11818  0.0  0.4 2549948 77524 ?       Sl   21:18   0:00 /usr/lib/firefox/firefox -contentproc -childID 13

Eu achei espetácular.  Pode ser que eu esteja exagerando, mas achei mesmo.  Uma dica muito simples e acabou com décadas usando um extra "grep" pra resolver as coisas. 

Muito obrigado Hélio Campos e grupo shellbr!

 



Falhas de segurança em CPU nas distros com linux-libre

18 de Maio de 2020, 19:27, por Home - 0sem comentários ainda
By Rafael Bonifaz - Alexandre Oliva, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=8939097Desde que assisti a palestra do Alexandre Oliva intitulada "quem tem medo de spectre & meltdown?" onde ele afirma que o kernel GNU Linux Libre está seguro em relação aos ataques de CPU que surgiram por ser software livre, eu sempre tive minhas dúvidas.  Sempre.  Uma vez que a correção de CPU era entregue através de firmware, como poderia estar livre.

 

Esses dias eu dei uma boa arrumada na minha estante e encontrei um laptop que estava parado desde 2014.  Quando liguei, estava ainda com o Ubuntu 14.04 instalado e rodando.  Pensei no mesmo momento que seria perfeito pra verificar o estado da proteção que as distros ditas livres e que são baseadas no GNU Linux Libre possuem.

 

Eu entrei na página da FSF eu fui seguindo as distros recomendadas como 100% livres.  Peguei pra testar as seguintes: Trisquel, Parabola e Guix.  Eu ia tentar também a Gnewsense mas a página principal mostra que depois de anos parada seu desenvolvimento foi simplesmente abandonado.  Mas ainda está listada na página da FSF.

 

(Foto By Rafael Bonifaz - Alexandre Oliva, CC BY-SA 2.0,https://commons.wikimedia.org/w/index.php?curid=8939097)

 

Pra ter alguma comparação eu também testei Debian puro, sem nada a parte de firmwares, e também um Ubuntu.  Vou descrever cada um em separado.

Guix 1.1.0

Esse morreu na praia pra mim.  Como essas distribuições não usam firmwares, não consigo ativar o wifi do laptop.  O Guix exige que a instalação siga por rede pra terminar.  Eu deixei o laptop numa mesa longe da rede cabeada.  Entre mexer o laptop pra minha mesa ou puxar um cabo até o outro quarto eu preferi simplesmente deixar de lado.  Tentei procurar por um livecd ou algo do gênero mas não encontrei.

 Trisquel 8.0

O Trisquel teve a instalação relativamente tranquila.  Uma voz robotizada ficava falando tudo o que eu teclava mas deu tudo certo.  Como esperado não funcionou com o wifi mas teve o touchpad do laptop funcionado desde a instalação.

uname:

Linux triquel 4.4.0-119-generic #143+8.0trisquel2 SMP Thu Apr 5 16:24:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

 

cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz
stepping        : 3
microcode       : 0x16
cpu MHz         : 2222.578
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
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 syscall nx pdpe1gb rdtscp lm constant_tsc arch_
perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movb
e popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb invpcid_single retpoline kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 e
rms invpcid rtm xsaveopt dtherm ida arat pln pts
bugs            : cpu_meltdown spectre_v1 spectre_v2
bogomips        : 5786.73
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

 

vulnerabilidades:

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: OSB (observable speculation barrier, Intel v6)
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

 

Parabola 2019.06

uname:

Linux parabolaiso 5.1.6-gnu-1 #1 SMP PREEMPT Sat Jun 1 21:40:45 UTC 2019 x86_64 GNU/Linux

 

cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz
stepping        : 3
microcode       : 0x16
cpu MHz         : 1069.269
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
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 syscall nx pdpe1gb rdtscp lm constant_tsc arch_
perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe p
opcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm 
xsaveopt dtherm ida arat pln pts
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
bogomips        : 5788.69
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

 

vulnerabilidades:

/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling

 

Debian Buster

uname:

Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux

 

cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz
stepping        : 3
microcode       : 0x16
cpu MHz         : 1903.637
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
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 syscall nx pdpe1gb rdtscp lm constant_tsc arch_
perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe p
opcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm 
xsaveopt dtherm ida arat pln pts
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit
bogomips        : 5786.32
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

 

vulnerabilidades:

/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: Split huge pages
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable

 

Ubuntu 18.04

uname:

Linux ubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

 

cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 60
model name      : Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz
stepping        : 3
microcode       : 0x16
cpu MHz         : 2047.970
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
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 syscall nx pdpe1gb rdtscp lm constant_tsc arch_
perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe p
opcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveop
t dtherm ida arat pln pts
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 5786.49
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

 

vulnerabilidades:

/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline

 

Sobre os resultados

A comparação é difícil porque cada um dos sistemas operacionais roda com uma versão de kernel diferente.  Todas baseadas em Linux.

Todas mostram em cpuinfo que detectam as falhas de spectre_v[1,2] e meltdown, além das demais.

Como mostrado pelas distros com kernels mais recentes, várias vulnerabilidades estão ainda abertas.  O sistema continua vulnerável aos ataques de especulação mas não aos spectre v1 e v2, nem meltdown.  Realmente sobre essas duas vulnerabilidades o Oliva está certo.  Só errou que o restante continua vulnerável e inseguro sem as correções de firmware.

Não imagino que possam ser corrigidas em versões mais recentes pois precisam do firmware da Intel pra mudar o microcode direto na CPU.

Quem continuar utilizando algumas dessas distros é interessante ficar de olho qual bug de CPU foi corrigido e qual ainda está pendente.  E ter cuidado ao usar o computador, pois o mesmo continua vulnerável a ataques de especulação mesmo rodando somente software livre.



Script python pra verificar se hosts e portas estão disponíveis

29 de Abril de 2020, 19:02, por Home - 0sem comentários ainda

door

Hoje chegou um mail pedindo pra testar uma mudança de máquinas que saíram da empresa pra irem habitar o cloud.  A tarefa era testar máquina e porta.  Algumas máquinas com uma porta somente, outras com várias.  E todas TCP.

Pra fazer isso rapidamente eu escrevi um script em python3 que basicamente estabelece uma conexão TCP e mostra OK se conectar ou FAIL se não conseguir.  Bem básico, mas resolveu meu problema muito mais rápido que se eu fosse testar máquina por máquina, porta por porta provavelmente com o comando telnet.

#! /usr/bin/python3

import socket

servers = [ 
        "helio.loureiro.eng.br:443", 
        "helio.loureiro.eng.br:389", 
        "helio.loureiro.eng.br:8081", 
        "helio.loureiro.eng.br:80", 
        "helio.loureiro.eng.br:22" 
        ]

for server in servers:
    try:
        host, port = server.split(":")
        port = int(port)
        socket.create_connection((host, port), 3)
        print(server, "OK")
    except:
        print(server, "FAIL")

O resultado:

helio.loureiro.eng.br:443 OK
helio.loureiro.eng.br:389 FAIL
helio.loureiro.eng.br:8081 FAIL
helio.loureiro.eng.br:80 OK
helio.loureiro.eng.br:22 OK

Boa diversão!



Gerando certificados auto assinados com openssl

22 de Abril de 2020, 9:47, por Home - 0sem comentários ainda

Tenho feito muitos testes para utilizar TLS e mTLS.  TLS é uma camada de criptografia assimétrica para garantir a comunicação segura entre dois pontos.

Em geral temos o model parecido com os sites web onde o servidor tem uma conexão segura assinada por uma autoridade certificadora e nos conectamos a ele.  No caso de mTLS, mutual TLS, é preciso validar quem conecta também.

Pra gerar os testes que venho fazendo, gero um certificado de 1 dia usando openssl da seguinte forma:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 1 -nodes \
          -subj "/C=SE/ST=Stockholm/L=STHLM/O=Company/OU=ADP/CN=localhost

Esse comando gera para mim a chave do servidor (key.pem) e a chave da autoridade certificadora, que assina a chave.

Em geral carrego isso no meu programa que utiliza TLS.

Pra testar (assumindo que seu serviço seja http e esteja usando a porta 9091):

curl --cacert cert.pem --key key.pem --cert cert.pem "https://localhost:9091/

Eu poderia gerar um chave pro client, que no caso é o comando curl, mas como é pra ambiente de testes, re-uso o mesmo. 

Boa diversão!



Tags deste artigo: #debian #debianbr #debianse #softwarelivre #freesoftware #linux #python