Arch Linux User Repository

Eu adotei o pacote e o atualizei para incluir as alterações feitas pelo @esauvisky e outros usuários uma vez que elas corrigiram as falhas para mim.

No entanto eu recomendo VEEMENTEMENTE que vocês utilizem o pacote warsaw-bin ao invés deste aqui, pois o processo de instalação, configuração e atualização são muito menos complexos e muito mais estáveis.

@esauvisky Existe uma maneira de o warsaw não sobrescrever as nossas mudanças, mas devemos criar uma pasta com um nome qualquer, movemos o conteúdo do /usr/lib/warsaw para ela e em seguida montamos a pasta que fizemos como read-only no /usr/lib/warsaw, então fica assim:

mkdir /PATH/DIRNAME

sudo mv /usr/lib/warsaw/* /PATH/DIRNAME

sudo mount --bind /PATH/DIRNAME /usr/lib/warsaw/

sudo mount -o remount,ro,bind /usr/lib/warsaw/

As duas últimas linhas podem fazer parte de um script(como aquele que eu mencionei no post anterior) para automatizar o processo.

@mesmer Talvez seja preferível ao invés de criar um link simbólico no /usr/local/lib/warsaw para o /usr/lib/warsaw você pode mover as bibliotecas do warsaw para /usr/lib/warsaw e depois montá-la como read-only em /usr/local/lib/warsaw durante o boot(serviço).

Eu também posso confirmar que o warsaw eventualmente sobrescreve os links simbólicos para as bibliotecas nativas com as suas próprias bibliotecas, efetivamente se auto-sabotando pois as bibliotecas embutidas causam o coredump e impedem a inicialização do core.

Infelizmente pelo que tenho entendido, não é possível mudar as permissões ou atributos de link simbólicos seja com chmod ou chattr, pois estaríamos mudando as permissões dos arquivos adjacentes. Alguém saberia como poderíamos tornar o workaround imutável mantendo os links simbólicos?

@espinafre Também notei isso, por isso eu fiz um script em bash para não ter que fazer isso manualmente. De fato ele se atualiza sozinho, já tinha lido na web que ele é "espião", mas não tinha tanta certeza até agora. O que me preocupa é que esse processo core tem privilégios de root e pode fazer praticamente o que quiser com sua máquina.

Talvez uma possível solução seja usar o comando chattr para impedir que o warsaw altere os nossos workarounds, mas a insegurança dos nossos arquivos permanecem. Uma boa solução que vi na web é criar um live cd com o warsaw ou até mesmo uma máquina virtual. Mas é possível que pelo menos por equanto nós não estejamos sendo espiados porque ele não usa cpu fora das transações bancárias e o processo core é morto quanto o usuário sai da sua conta, embora o consumo de memória é bastante elevado chegando até 700MB, então talvez não seja interessante que ele fique ativo por muito tempo.

Então acho melhor executar esses comandos em um script quando quiser usar o warsaw com o warsaw.service desabilitado:

sudo sh - c /usr/bin/warsaw/core

sh -c /usr/bin/warsaw/core

@ArchHero, @nubiocicarini, @mesmer: pessoal, acabei de notar uma coisa: me parece que o spyware... quer dizer, o warsaw se auto-atualiza, reescreve as tranqueiras que ficam em /usr/lib/warsaw por conta própria. A correção dos .so que o @ArchHero mostrou foi sobrescrita com bibliotecas do spyware mesmo, sem que eu tenha feito nenhuma ação.

Para tirar a prova, reinstalei o pacote, apliquei novamente a correção dos links simbólicos e reiniciei a máquina. O core subiu, consegui acessar o BB. Fiz um cd para /usr/lib/warsaw e fui olhar os arquivos: no primeiro ls -l, aparentemente tudo normal, mas depois, vi que os links foram sumindo, e as datas de alguns .so foram mudadas, indicando que o spyware se "auto-atualizou".

@ArchHero deu certinho. Warsaw funcionando! Grato pela ajuda.

Estou lendo tudo e compilando um post install com testphase para os fix