CGroups

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Se você quer ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
Adquira o material oficial PEASS & HackTricks
Descubra A Família PEASS, nossa coleção de NFTs exclusivos
Junte-se ao grupo 💬 Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para os repositórios do GitHub HackTricks e HackTricks Cloud.

Informações Básicas

Grupos de controle do Linux, também conhecidos como cgroups, são um recurso do kernel do Linux que permite limitar, fiscalizar e priorizar recursos do sistema para um conjunto de processos. Cgroups oferecem uma maneira de gerenciar e isolar o uso de recursos (CPU, memória, E/S de disco, rede, etc.) de grupos de processos em um sistema. Isso pode ser útil para muitos propósitos, como limitar os recursos disponíveis para um grupo específico de processos, isolar certos tipos de cargas de trabalho de outros, ou priorizar o uso de recursos do sistema entre diferentes grupos de processos.

Existem duas versões de cgroups, 1 e 2, e ambas estão atualmente em uso e podem ser configuradas simultaneamente em um sistema. A diferença mais significativa entre a versão 1 dos cgroups e a versão 2 é que a última introduziu uma nova organização hierárquica para os cgroups, onde os grupos podem ser organizados em uma estrutura em árvore com relações de pai-filho. Isso permite um controle mais flexível e detalhado sobre a alocação de recursos entre diferentes grupos de processos.

Além da nova organização hierárquica, a versão 2 dos cgroups também introduziu várias outras mudanças e melhorias, como suporte para novos controladores de recursos, melhor suporte para aplicações legadas e desempenho aprimorado.

No geral, a versão 2 dos cgroups oferece mais recursos e melhor desempenho do que a versão 1, mas a última ainda pode ser usada em certos cenários onde a compatibilidade com sistemas mais antigos é uma preocupação.

Você pode listar os cgroups v1 e v2 para qualquer processo olhando para o arquivo cgroup em /proc/<pid>. Você pode começar olhando para os cgroups do seu shell com este comando:

$ cat /proc/self/cgroup
12:rdma:/
11:net_cls,net_prio:/
10:perf_event:/
9:cpuset:/
8:cpu,cpuacct:/user.slice
7:blkio:/user.slice
6:memory:/user.slice 5:pids:/user.slice/user-1000.slice/session-2.scope 4:devices:/user.slice
3:freezer:/
2:hugetlb:/testcgroup
1:name=systemd:/user.slice/user-1000.slice/session-2.scope
0::/user.slice/user-1000.slice/session-2.scope

Não se alarme se o output for significativamente mais curto no seu sistema; isso apenas significa que você provavelmente tem apenas cgroups v2. Cada linha de output aqui começa com um número e é um cgroup diferente. Aqui estão algumas dicas sobre como lê-lo:

Números 2–12 são para cgroups v1. Os controladores para esses estão listados ao lado do número.
Número 1 também é para versão 1, mas não tem um controlador. Este cgroup é apenas para fins de gestão (neste caso, systemd configurou-o).
A última linha, número 0, é para cgroups v2. Não há controladores visíveis aqui. Em um sistema que não tem cgroups v1, esta será a única linha de output.
Nomes são hierárquicos e parecem partes de caminhos de arquivos. Você pode ver neste exemplo que alguns dos cgroups são nomeados /user.slice e outros /user.slice/user-1000.slice/session-2.scope.
O nome /testcgroup foi criado para mostrar que em cgroups v1, os cgroups para um processo podem ser completamente independentes.
Nomes sob user.slice que incluem session são sessões de login, atribuídas pelo systemd. Você os verá quando estiver olhando para os cgroups de um shell. Os cgroups para os seus serviços do sistema estarão sob system.slice.

Visualizando cgroups

Cgroups são tipicamente acessados através do sistema de arquivos. Isso contrasta com a interface tradicional de chamada de sistema Unix para interagir com o kernel.
Para explorar a configuração de cgroup de um shell, você pode olhar no arquivo /proc/self/cgroup para encontrar o cgroup do shell, e então navegar até o diretório /sys/fs/cgroup (ou /sys/fs/cgroup/unified) e procurar por um diretório com o mesmo nome do cgroup. Mudar para este diretório e olhar ao redor permitirá que você veja as várias configurações e informações de uso de recursos para o cgroup.

Entre os muitos arquivos que podem estar aqui, os principais arquivos de interface cgroup começam com cgroup. Comece olhando para cgroup.procs (usar cat está bem), que lista os processos no cgroup. Um arquivo semelhante, cgroup.threads, também inclui threads.

A maioria dos cgroups usados para shells têm esses dois controladores, que podem controlar a quantidade de memória usada e o número total de processos no cgroup. Para interagir com um controlador, procure pelos arquivos que correspondem ao prefixo do controlador. Por exemplo, se você quiser ver o número de threads rodando no cgroup, consulte pids.current:

Um valor de max significa que este cgroup não tem um limite específico, mas como os cgroups são hierárquicos, um cgroup mais abaixo na cadeia de subdiretórios pode limitá-lo.

Manipulando e Criando cgroups

Para colocar um processo em um cgroup, escreva seu PID no arquivo cgroup.procs como root:

# echo pid > cgroup.procs

Assim é como muitas alterações em cgroups funcionam. Por exemplo, se você quiser limitar o número máximo de PIDs de um cgroup (para, digamos, 3.000 PIDs), faça da seguinte forma:

# echo 3000 > pids.max

Criar cgroups é mais complicado. Tecnicamente, é tão fácil quanto criar um subdiretório em algum lugar na árvore de cgroup; ao fazer isso, o kernel cria automaticamente os arquivos de interface. Se um cgroup não tem processos, você pode remover o cgroup com rmdir mesmo com os arquivos de interface presentes. O que pode confundir são as regras que regem os cgroups, incluindo:

Você só pode colocar processos em cgroups de nível externo ("folha"). Por exemplo, se você tem cgroups chamados /my-cgroup e /my-cgroup/my-subgroup, você não pode colocar processos em /my-cgroup, mas /my-cgroup/my-subgroup está ok. (Uma exceção é se os cgroups não têm controladores, mas não vamos aprofundar.)
Um cgroup não pode ter um controlador que não esteja em seu cgroup pai.
Você deve especificar explicitamente controladores para cgroups filhos. Você faz isso através do arquivo cgroup.subtree_control; por exemplo, se você quer que um cgroup filho tenha os controladores cpu e pids, escreva +cpu +pids neste arquivo.

Uma exceção a essas regras é o cgroup raiz encontrado na base da hierarquia. Você pode colocar processos neste cgroup. Uma razão pela qual você pode querer fazer isso é para desvincular um processo do controle do systemd.

Mesmo sem controladores ativados, você pode ver o uso de CPU de um cgroup olhando para o seu arquivo cpu.stat:

Como este é o uso acumulado de CPU durante toda a vida útil do cgroup, você pode ver como um serviço consome tempo de processador mesmo que ele crie muitos subprocessos que eventualmente terminam.