Você pode ser um programador cuidadoso. Usa Linux. Criptografa o disco. Tem senha forte e única em todo lugar. Ativa two factor authentication sempre que pode. Não baixa software pirata. Só instala coisa de repositório oficial. Usa firewall. Acesso por chave. Ambiente bem configurado. Tudo bonito.

E ainda assim pode tomar uma pancada feia.

Porque basta um npm install, um uv add, um pip install, um cargo add, um composer install, um go get, um mvn install para você baixar e executar código de terceiros dentro do seu ambiente. E não estou falando só de bibliotecas obscuras. Estou falando de ecossistemas inteiros baseados nisso.

Ataque de supply chain é isso: em vez de invadir diretamente o seu sistema, o atacante contamina algo em que você confia para chegar até você pela porta da frente.

Ano passado já tivemos vários casos chamando atenção no ecossistema JavaScript. E, agora, no fim de março, veio um dos mais assustadores: o caso do Axios. As versões comprometidas foram 1.14.1 e 0.30.4, publicadas em 31 de março de 2026. O pacote malicioso puxava uma dependência falsa e executava um postinstall capaz de instalar um RAT em Linux, macOS e Windows. Não era “só uma biblioteca vulnerável”. Era malware sendo entregue por uma ferramenta que milhões de programadores usam normalmente. O Axios, como pacote, passa de 70 milhões de downloads semanais. E, até onde consegui apurar, ninguém publicou o número exato de downloads das versões comprometidas.

E isso não é exclusividade de Node.js. O mesmo tipo de problema aparece em outros ecossistemas. Há poucos dias, o próprio PyPI publicou um relatório sobre os ataques envolvendo LiteLLM e Telnyx, com orientações práticas para reduzir risco. (Blog do PyPI)

O ponto mais importante aqui é o seguinte: ambiente de desenvolvimento e pipeline de CI também são alvo.

Muita gente pensa em segurança de dependência como se o risco estivesse só em produção. Não está. No caso do Axios, o momento crítico era o npm install rodando em máquina de desenvolvedor e em pipeline automatizada, com potencial de capturar segredos, tokens e credenciais. No caso recente do LiteLLM, os relatos públicos falam em roubo de variáveis de ambiente, chaves SSH, credenciais de cloud, tokens e segredos de infraestrutura. (Microsoft)

E se você foi comprometido?

Aí atualizar a versão não basta.

Você deve assumir comprometimento. Isso normalmente significa isolar a máquina, investigar o host, rotacionar senhas, certificados, chaves SSH, tokens e outras credenciais. Em muitos casos, a medida mais prudente é recriar completamente o ambiente. Sim, “recriar completamente” significa formatar e reinstalar o sistema operacional. Supply chain não é bugzinho. Pode ser cavalo de troia dentro da sua estação de trabalho.

A comunidade está procurando soluções, e algumas coisas boas realmente avançaram. Desde 1º de janeiro de 2024, o PyPI passou a exigir 2FA para todos os usuários que fazem ações de gerenciamento ou upload. Também temos iniciativas como Trusted Publishers, SBOM, verificação de integridade e outras melhorias importantes. Mas não dá para sentar e esperar que o ecossistema resolva tudo sozinho. A responsabilidade pelos seus projetos continua sendo sua.

E aí vem a pergunta inevitável: então o que você vai fazer? Parar de usar open source? Reescrever tudo do zero?

Claro que não.

Usar bibliotecas de terceiros é inevitável. O problema não é esse. O problema é usar sem critério nenhum.

O fato de esse risco ser inevitável não significa que ele seja incombatível. Dá para reduzir muito a superfície de ataque. E, em segurança, reduzir risco já muda completamente o jogo.

Na prática, eu colocaria isso em três frentes.

1. Use menos dependências

Programadores adoram regra absoluta. A vida quase nunca funciona assim.

Você provavelmente come açúcar, mas não vive de colheradas de açúcar. Com dependências é a mesma coisa. Não é questão de abolir. É questão de moderação.

Tem uma galera que se lambuza.

Instala biblioteca para fazer coisa que a linguagem já faz. Puxa pacote para resolver detalhe minúsculo. Aceita árvore de dependências gigantesca em troca de uma conveniência ridícula.

Olha o caso do Axios. É uma biblioteca excelente. Não tenho nada contra. Mas, se a sua aplicação faz três requisições HTTP em meia dúzia de pontos, o fetch resolve. Você realmente precisa de mais uma dependência?

Em Python acontece o mesmo. requests e httpx são ótimos. Mas não existe nada de errado com urllib quando ela basta para o que você precisa.

Quer um exemplo didático do exagero?

Tem pacote no npm para verificar se um número é ímpar. Sim, isso existe. Chama-se is-odd. Você pode olhar e rir. Mas o ponto é sério: cada dependência adicionada é mais uma cadeia de confiança, mais um pedaço de código de terceiros, mais uma oportunidade de compromisso.

Não estou dizendo para nunca usar dependência. Estou dizendo para tratá-la como custo, não como brinde.

Cada pacote precisa se justificar.

2. Congele dependências

A segunda medida é congelar dependências.

Isso reduz muito a janela de exposição a publicações futuras maliciosas e ainda te dá reprodutibilidade. Em outras palavras, evita que seu projeto mude de comportamento sozinho só porque alguém publicou uma nova versão de um pacote ontem à noite.

Vamos demonstrar.

Eu uso mise-en-place porque trabalho com várias linguagens. Em Python temos pyenv e uv. Em Node temos nvm, volta, pnpm, fnm. O mise-en-place me permite ter uma ferramenta só para gerenciar ambientes e versões de linguagem. Este artigo não é sobre mise-en-place, mas, se você quiser, eu posso escrever outro só sobre isso.

Vou criar uma pasta nova e inicializar um ambiente com Python e Node:

mkdir teste1339
cd teste1339/
misemodel python="3.14" node="24.14" -f

Pronto. Agora, nessa pasta, eu tenho Python 3.14 e Node 24.14 disponíveis para programar.

Vamos instalar um pacote super útil no npm:

npm install is-odd

E um pacote super útil no Python:

uv add requests

Perceba que usei uv, não pip. Fiz isso porque quero trabalhar com locking de dependências de forma mais séria. Depois disso, executo:

uv lock

E agora um ls:

main.py              package-lock.json  pyproject.toml  uv.lock
node_modules         package.json       README.md

Em Node, temos package.json e package-lock.json. Em Python, temos pyproject.toml e uv.lock.

Esses arquivos registram a árvore resolvida de dependências e mecanismos de integridade usados na reinstalação. Se, em algum momento, a integridade esperada não bater, a instalação falha. Isso é exatamente o tipo de atrito que você quer quando a alternativa é executar código adulterado.

Agora imagine que eu edite um lockfile e troque manualmente o hash de algum artefato. Depois disso, simulo uma instalação nova do projeto.

Esse detalhe é muito importante: quando você trava corretamente a árvore de dependências, seu projeto não passa automaticamente a usar uma nova publicação que apareceu no registro depois. Se amanhã alguém comprometer uma nova versão daquele pacote, meu projeto não vai sair correndo para baixá-la sozinho. O lockfile reduz muito essa superfície de ataque de supply chain, desde que eu não atualize cegamente.

E, de brinde, você ganha estabilidade funcional. O mesmo projeto instala do mesmo jeito hoje, amanhã e no mês que vem.

Vale um aviso importante: lockfile não é escudo mágico. Ele não salva você se a primeira instalação já aconteceu numa versão comprometida. Mas ele reduz muito o risco de contaminação por atualizações futuras inesperadas.

3. Desacelere atualizações

Aqui está um ponto que quase ninguém gosta de ouvir.

Você não deve atualizar dependência automaticamente sem revisão humana.

Isso não é produtividade. Isso é risco operacional travestido de conveniência.

Claro que você também não vai ficar congelado para sempre na mesma versão de tudo. Bibliotecas recebem correções de segurança, correções funcionais e melhorias legítimas. O problema não é atualizar. O problema é atualizar no susto, sem contexto e sem tempo de observação.

O ideal é separar as atualizações em dois grupos.

O primeiro grupo são as atualizações críticas de segurança. Essas devem ser avaliadas e aplicadas o quanto antes. Normalmente elas vêm acompanhadas de boletins, advisories, CVEs, discussão pública e muita atenção em cima do problema. Nesses casos, o risco de não atualizar costuma ser maior do que o risco da mudança.

O segundo grupo são as atualizações regulares. Nessas, eu prefiro uma regra simples: não adote automaticamente uma versão recém-lançada.

Se hoje é dia de atualizar e um pacote saiu ontem, eu não quero ser o primeiro da fila. Prefiro instalar a anterior ou esperar um pequeno intervalo. Esse cooldown diminui a chance de eu puxar uma versão publicada às pressas, com erro grave, ou até uma versão maliciosa que ainda não foi detectada. O próprio PyPI recomendou locking e dependency cooldowns depois dos incidentes recentes.

A mesma lógica vale quando você começa um projeto novo.

Vai adicionar uma dependência? Olhe quando aquela versão foi publicada. Se ela é novíssima, dê um passo para trás. Não precisa ser o early adopter de tudo dentro do ambiente que guarda as chaves do seu negócio.

Não existe risco zero em supply chain

Esse talvez seja o ponto mais importante de todos.

Você não vai eliminar ataques de supply chain da sua vida. Isso não existe.

Se você desenvolve software moderno, você depende de código de terceiros. E, se depende de código de terceiros, depende também da segurança dos mantenedores, das contas deles, dos pipelines deles, dos registros, dos mirrors, dos plugins, das ferramentas e do processo inteiro.

Só que entre “não existe risco zero” e “então tanto faz” existe um abismo.

Usar menos dependências, travar a árvore de instalação e desacelerar atualizações já muda bastante o seu perfil de risco. Você para de ser o alvo mais fácil. E, em segurança, isso conta muito.

Ataques de supply chain são perigosos justamente porque exploram confiança. Eles entram no seu ambiente usando a mesma porta pela qual entram as coisas boas. Por isso a defesa não pode ser ingenuidade, nem pânico. Tem que ser critério.

Não é sobre abandonar open source. É sobre parar de tratar dependência como se fosse decoração.

Cada pacote que você adiciona aumenta sua superfície de ataque. Cada instalação é um ato de confiança. E confiança, em computação, precisa ser administrada com muito mais cuidado do que a gente costumava admitir.

O post Evitando ataques de supply chain apareceu primeiro em Elcio Ferreira.

Não há previsão de retorno de funcionamento do Telegram. Isso ocorre porque é preciso, primeiro, que o aplicativo colabore com os órgãos federais para, então, ter ordem emitida desfazendo a sua suspensão.

O que exatamente aconteceu? A Polícia Federal obteve acesso a grupos neonazistas no Telegram que estariam recrutando menores para atos terroristas e, como parte das investigações, a justiça solicitou ao Telegram os números de telefones e outros dados de participantes de dois desses grupos. O Telegram demorou a responder e, quando respondeu, não entregou os dados e recorreu da decisão.

A sequência de eventos que levou ao Telegram bloqueado

Segundo o G1, o primeiro pedido da justiça para obter dados desses grupo aconteceu no dia 19/04, mas só foi encaminhada ao Telegram no dia 20/04, às 13h46. Um desses grupos já havia sido excluído há meses. O Telegram responde solicitando informações adicionais. A justiça envia parte dessas informações às 16h14 e o restante no dia seguinte, 21, às 8h06, momento em que o segundo grupo já havia sido também deletado. É parte da política de privacidade do Telegram a exclusão física real de dados que você mandou excluir. Embora a política de privacidade não fale sobre a exclusão de grupos, para as outras coisas todas, incluindo sua própria conta, o Telegram é claro: excluiu, já era, não temos cópia. Podemos deduzir que o mesmo se aplica também a grupos.

Acontece que esse segundo grupo, excluído no dia 20, havia sido alvo de um outro pedido da justiça ao Telegram, no dia 10. Esse pedido anterior havia sido menos abrangente, solicitava apenas dados do administrador do grupo. Segundo o Telegram, eles só tinham nesse momento informações desse administrador, coletadas para atender ao pedido do dia 10, e de mais ninguém. E não seria mais possível recuperar informações sobre os outros participantes do grupo. O Telegram diz que entregou o que tinha, mas a justiça considerou que não era suficiente e ordenou: Telegram bloqueado.

Veja a resposta publicada por Pavel Durov em seu canal no Telegram:

A missão do Telegram é preservar a privacidade e liberdade de expressão ao redor do mundo.

Em casos onde as leis locais vão contra essa missão ou impõem requerimentos tecnologicamente inviáveis, nós às vezes temos que deixar esses mercados. No passado, países como China, Irã e Rússia baniram Telegram devido a nossa postura baseada em princípios no tema de direitos humanos. Esses eventos, apesar de infelizes, são ainda preferíveis a trair nossos usuários e as crenças sobre as quais nos fundamentamos.

No Brasil, um tribunal requisitou dados que nos são tecnologicamente impossíveis de obter. Estamos apelando da decisão e esperando ansiosos pela solução final. Não importa o custo, vamos defender nossos usuários no Brasil e seu direito à comunicação privada.

Pavel Durov

Isso nos levanta três questões muito importantes:

Juízes lidando com tecnologia

A primeira delas é sobre o conhecimento técnico que deveria embasar decisões judiciais. O judiciário e a polícia precisam de bons assessores técnicos para auxilia-los nas decisões. Por exemplo, do primeiro grupo a ser excluído, mesmo que agisse imediatamente, o Telegram não teria dado algum.

Pior do que isso, veja esse trecho do ofício enviado pela Justiça do Espírito Santo ao Telegram:

… forneça, no prazo de 24 horas, os dados cadastrais com nome, nome de usuários, CPF, foto do perfil, status do perfil, e-mail, endereço, dados bancários e do cartão de crédito cadastrados, contatos fornecidos para recuperação de conta, dispositivos vinculados (incluindo IMEI, se houver), número de confiança
indicado para a autenticação de dois fatores e logs de criação (contendo IP, data, hora, fuso horário GMT/UTC e porta lógica) de todos os usuários do canal …

Você que é usuário de Telegram, me diga, em algum momento você cadastrou seu CPF ou sua conta bancária no aplicativo? Talvez você seja usuário do Premium e tenha cadastrado seu cartão de crédito. Mas, se for o caso, espero que seu cartão de crédito tenha sido tokenizado por um gateway de pagamento e o Telegram também não tenha acesso aos dados do cartão.

Como cumprir uma ordem impossível?

Não sei se Pavel Durov está de má vontade com a justiça brasileira. Ele é um sujeito polêmico e está sempre metido nesse tipo de confusão. Mas uma coisa está clara: mesmo que o Telegram não tivesse solicitado informações adicionais e tivesse agido imediatamente, não teria sido possível atender completamente o pedido da justiça. Veja esse trecho da política de privacidade do Telegram:

Telegram é um serviço de comunicação. Você informa seu número de telefone e dados básicos de conta (o que pode incluir um nome de perfil, foto de perfil e informação sobre você) para criar uma conta Telegram… Nós não queremos saber seu nome real, gênero, idade ou do que você gosta.

É claro que um juiz não tem a menor obrigação ou condições de saber o que é criptografia de ponta-a-ponta, política de retenção de dados, tokenização, etc. Mas deveria ter alguém ao lado dele para dizer: “então, excelência, isso aqui que o senhor está pedindo…”

Talvez, se o judiciário e a polícia estivessem melhor assessorados por técnicos competentes, não tivessem pedido ao Telegram dados que eles obviamente não têm. Talvez isso tivesse eliminado a necessidade de o Telegram responder com novas dúvidas. Nesse cenário em que o tempo foi crucial para o fracasso da iniciativa, talvez isso permitisse coletar os dados que o Telegram obviamente tinha (como número de telefone e IP) antes de o grupo ser apagado.

Sites e aplicativos na internet mundial

A segunda questão muito importante é sobre quanto empresas estrangeiras devem cumprir a legislação brasileira ao operar pela internet.

Por que então estamos com o Telegram bloqueado no Brasil? Se o Telegram não tinha os dados, por que o juiz determinou a suspensão do serviço? Porque no entendimento do juiz:

1. O Telegram tinha os dados e não queria entregá-los. Por isso ele escreve “ante a recalcitrância do Telegram em cumprir…” O que volta para o ponto acima, o juiz não entendeu os detalhes técnicos do que estava pedindo.
2. O Telegram deveria ter esses dados. Porque a legislação brasileira exige. O Marco Civil da Internet, em seu artigo 15°, diz:

O provedor de aplicações de internet constituído na forma de pessoa jurídica e que exerça essa atividade de forma organizada, profissionalmente e com fins econômicos deverá manter os respectivos registros de acesso a aplicações de internet, sob sigilo, em ambiente controlado e de segurança, pelo prazo de 6 (seis) meses, nos termos do regulamento.

Aqui também temos uma complicação ´técnica porque a legislação não diz quais registros de acesso, de quê, devem ser guardados. Absolutamente nenhuma aplicação guarda logs de TUDO o que o usuário faz ou acessa porque, obviamente, esses logs poderiam ser maiores que o próprio banco de dados da aplicação.

Ou seja, o Telegram poderia ter log de acesso dos usuários, com IP, hora de login e atividade, e não ter nenhuma informação sobre de que grupos cada usuário participava, tornando impossível vincular um id de grupo a uma lista de usuários. Tudo isso, sem descumprir a legislação. Acontece que o Telegram nem precisaria cumprir a legislação brasileira.

O Telegram e a lei brasileira

O Telegram não tem escritório no Brasil. Há um tempo alguns portais noticiaram, de uma forma bem sensacionalista, que o Telegram teria um escritório o representando no Brasil. Não é verdade, eles apenas contrataram um escritório de advocacia brasileiro para cuidar do registro da marca deles no Brasil.

Bom, é uma empresa com sede em Dubai e servidores todos fora do Brasil. Eles não estão sujeitos a nossa legislação. Nós deveríamos permitir que usuários brasileiros usassem os serviços deles?

Pense bem antes de responder. É claro que nós queremos que as empresas sejam responsáveis por seus atos, produtos e serviços e a legislação é uma maneira de tentar garantir isso. Mas você realmente quer que brasileiros não possam acessar sites, blogs, jogos, aplicativos e serviços de empresas e entidades que não têm uma sede brasileira? Isso não mataria boa parte da inovação que a internet pode trazer ao nos permitir colaborar em escala global?

Para que serviu o Telegram bloqueado?

O que nos leva ao terceiro ponto: será que o judiciário não deveria pensar duas vezes antes de bloquear serviços usados pela população? É claro que combater o nazismo é uma causa super prioritária e devemos empregar todos os esforços que pudermos nela. Mas o que estamos vendo aqui é uma trapalhada de comunicação entre o judiciário e o Telegram que, como consequência, prejudicou a vida dos 42 milhões de usuários ativos do app no Brasil. Muitos deles que usam o aplicativo para trabalhar e sustentar suas famílias. Se os dados que a justiça quer não existem, manter o Telegram bloqueado não está ajudando ninguém.

O Telegram entregou à Justiça os dados que eles tinham, o número de telefone e IP do administrador do grupo:

Tanto o número de telefone quanto o endereço de IP são de Lima, no Peru:

Faz sentido deixar o Telegram bloqueado para 42 milhões de pessoas por isso? Ainda mais por uma ordem impossível de ser cumprida?

O post Telegram Bloqueado no Brasil: o que exatamente aconteceu apareceu primeiro em Elcio Ferreira.

Essa mensagem aparecia apenas em situações onde o site potencialmente ia coletar dados dos usuários. Basicamente, quando havia um formulário na tela. Principalmente formulários de login, mas a mensagem aparecia para praticamente qualquer formulário. Logo, durante todo o ano passado, você poderia manter um site de conteúdo sem HTTPS, sem problema nenhum, desde que não tivesse formulários.

Recentemente, porém, o Google passou a avisar site não seguro para qualquer site sem HTTPS. Assim, até o Pudim, um site que não tem formulário, nem scripts, nem nada, só uma foto de um pudim, está marcado, veja:

Tenho um site não seguro. Como resolver? Let’s Encrypt!

Essa iniciativa do Google Chrome não está sozinha. Faz parte de um esforço de várias frentes para tornar a web mais segura. O próprio Google anunciou que está privilegiando nas buscas sites com HTTPS. Quer dizer que, ao estar marcado como site não seguro, seu site não apenas vai assustar os usuários que receber, também vai receber menos usuários.

O próprio Google Chrome, junto com empresas como GitHub, Facebook, Cisco e Akamai, patrocinam uma iniciativa chamada Internet Security Research Group, que oferece, através do Let’s Encrypt, chaves SSL grátis e automáticas para qualquer site.

Assim, se o seu provedor dá suporte a Let’s Encrypt, você provavelmente pode ter seu site marcado como seguro em poucos cliques. Meu hosting predileto, por exemplo, é a Dreamhost. Se você hospeda seu site lá, pode ativar SSL em seu site em três cliques, aqui:

Se você mantém seus próprios servidores, dedicados ou VPS, você vai ter que instalar o Let’s Encrypt você mesmo. O processo é bastante simples. Expliquei nesse vídeo:

O post Site não seguro – como resolver de graça com Let’s Encrypt apareceu primeiro em Elcio Ferreira.

Então, se você usa Linux, confira se você tem o Samba instalado. Se tiver, confira a versão menor (aquele terceiro número no código da versão). Se você estiver usando uma das seguintes, você está seguro: 4.6.4, 4.5.10 ou 4.4.14.

Se não. Você pode fazer uma das seguintes coisas:

1. verificar se há atualização do Samba para sua distribuição, e se a versão mais atualizada é uma dessas acima; ou
2. baixar o código fonte e compilar o Samba você mesmo, de preferência da versão 4.6.4; ou
3. desligar o serviço vulnerável, adicionando ao seu smb.conf a linha abaixo:

   nt pipe support = no

   E em seguida reiniciando o Samba; ou

4. desinstalar o Samba

A última alternativa pode parecer a mais preguiçosa, e talvez você simplesmente não possa cogitá-la. Mas eu recomendo que você se pergunte, antes de qualquer outra atitude: eu preciso mesmo desse serviço? Dessa vez foi uma falha no Samba, mas praticamente todo dia saem atualizações de segurança para os diversos softwares e serviços que você pode instalar em seu sistema. Cada software não utilizado que você mantém instalado aumenta suas chances de ter problemas de segurança e suas preocupações com atualizações de versão.

Nesse caso, menos é mais. Reduza os pacotes que você tem instalados aos essenciais, removendo tudo o que você não usa. Principalmente em servidores. Isso vai tornar suas máquinas mais seguras e vai tornar mais fácil para você manter tudo atualizado.

Assine a companhe os boletins de segurança dos softwares que você usa. Você não quer correr o risco de não ficar sabendo de uma atualização crítica e ter seu sistema vulnerável simplesmente por não ter sido avisado, não é?

Por fim, é importante que você saiba que a essa falha de segurança no Samba é especialmente preocupante porque muitos dispositivos NAS e outras soluções de armazenamento de dados usam Samba. Então se você possui um equipamento de armazenamento de dados, é bom investigar se ele usa Samba e está vulnerável a essa falha.

PS: obrigado ao Rodrigo por me avisar.

O post Mantenha seus servidores enxutos apareceu primeiro em Elcio Ferreira.

Hacker Installed a Secret Backdoor On Facebook Server to Steal Passwords

Resumindo, um hacker descobriu um servidor do Facebook (files.fb.com) rodando uma versão desatualizada de um software de compartilhamento de arquivos e conseguiu, através disso, fazer upload de um PHP Web Shell. Ou seja, acesso shell ao servidor.

No post original do cara que descobriu a falha você pode achar uma porção de detalhes técnicos muito interessantes.

O que é esse backdoor secreto?

Backdoor (“porta dos fundos” em inglês) é um software oculto que permite a quem o instalou acesso ao servidor. Um webshell é um backdoor que pode ser acessado em uma interface web. Existem webshells em PHP, ASP, Python, Ruby, C#, Perl e é muito fácil construir um em sua linguagem predileta.

Veja um exemplo de tela de um web shell em PHP:

E seu site, é seguro?

Lição importante que você tirar desse episódio: uma corrente é tão forte quanto seu elo mais fraco. Seu servidor de controle de versão, seu software de gestão de projetos, seu webmail, todas as aplicações web acessórias ao seu site, todos os seus servidores e os computadores da sua equipe precisam estar seguros.

Por exemplo: se seu servidor git tiver o Open SSH desatualizado, se um dos programadores que desenvolve seu site instalar um software malicioso por engano ou se a sua senha do registro de domínios não é forte o suficiente, seu site estará vulnerável, não importa quão bom seja seu código.

O post Hacker instalou um Backdoor secreto em servidores do Facebook para capturar senhas apareceu primeiro em Elcio Ferreira.

ps aux|grep root

Quase tudo em Linux é representado como arquivos. As informações sobre os processos rodando estão em arquivos virtuais dentro de /proc. Você pode remontar /proc, passando uma opção para controlar a visibilidade dos processos, assim:

sudo mount -o remount,rw,hidepid=2 /proc

Em seguida, tente novamente:

ps aux|grep root

Você vai ver que os usuários, com hidepid=2, não poderão ver processos de outros usuários. Para desfazer, execute:

sudo mount -o remount,rw,hidepid=0 /proc

Assim, você pode configurar seu servidor para que um usuário não possa saber o que os outros estão fazendo.

O post Escondendo processos dos outros usuários apareceu primeiro em Elcio Ferreira.

Alguém me explica?

O post What? apareceu primeiro em Elcio Ferreira.