← RHCE in Ansible: automação e operação
14 / 15 · 55 MIN

SELinux: mapeamento e estado efetivo

Corrige labels persistentes e distingue política, permissões e acesso observado.

Investigar a negação

Um serviço httpd fictício deve ler conteúdo estático em /srv/dr-status. O ficheiro tem modo 0644, mas o pedido recebe 403 e existe uma negação AVC associada. O modo Unix não descreve toda a decisão: o domínio do processo, o tipo do objeto e a política SELinux também interessam. Confirma a identidade do processo e os diretórios atravessados antes de atribuir toda a falha a uma única camada. Não transformes o sintoma num pedido para desligar SELinux ou abrir escrita a todos. O objetivo é permitir a operação necessária mantendo o controlo sobre operações que não são necessárias.

Mapear e aplicar

O exemplo destina-se a uma VM RHEL 10 descartável com SELinux enforcing. sefcontext mantém a associação persistente entre /srv/dr-status(/.*)? e httpd_sys_content_t. O padrão inclui a diretoria e os descendentes; não altera todo /srv. A escolha representa conteúdo estático para leitura, não uma área de uploads. A tarefa seguinte aplica restorecon aos objetos existentes. São ações distintas: uma regra correta pode coexistir com ficheiros ainda etiquetados incorretamente. chcon altera labels de objetos, mas não substitui a regra persistente usada numa futura reconciliação.

O handler que não trata drift

Imagina que a regra já está correta e um operador mudou o label de index.html. Se restorecon só correr como handler notificado por sefcontext changed, a execução seguinte pode não corrigir esse drift. O exemplo invoca a reconciliação depois de criar o conteúdo, mesmo sem alteração da regra. O comando pode ser executado em todas as passagens sem que todas precisem de mudar labels. O changed_when baseado na saída é apenas uma convenção de relato do exemplo; a aceitação deve comparar o contexto efetivo e o comportamento de acesso. Evita tornar a decisão funcional dependente de texto localizado no terminal.

Aceitar com a política ativa

Inspeciona a regra local, compara o contexto esperado com o observado e testa leitura através do processo httpd enquanto SELinux continua enforcing. Um pedido que funciona apenas em permissive é evidência de diagnóstico, não cumprimento do controlo. Se o conteúdo precisar de escrita, separa a área escrevível e analisa o tipo adequado em vez de aplicar um label amplo à árvore inteira. Uma nova negação não justifica gerar automaticamente uma política permissiva com base em todo o audit log; primeiro procura caminhos, labels, portas e configurações incorretos.

Limites do exemplo

A sintaxe foi validada com community.general 10.7.6, mas não houve relabel nem ensaio de acesso em RHEL nesta revisão. O playbook cria conteúdo e regra; não configura DocumentRoot, VirtualHost, TLS ou listeners httpd. Na VM, prepara essa integração separadamente e conserva a política enforcing durante os testes. Depois de uma reconciliação adicional e de reboot, repete a leitura e confirma que a associação persistente continua válida.

# Exercise for a disposable enforcing RHEL 10 VM.
# Syntax checked only; actual labels and httpd access remain unverified.
- name: Maintain a narrow read-only web content label
  hosts: rhel_lab
  become: true
  gather_facts: true
  pre_tasks:
    - name: Require the intended lab and enforcing policy
      ansible.builtin.assert:
        that:
          - lab_confirmed | default(false) | bool
          - ansible_distribution == 'RedHat'
          - ansible_distribution_major_version == '10'
          - ansible_selinux.status == 'enabled'
          - ansible_selinux.mode == 'enforcing'
  tasks:
    - name: Install the policy management dependency
      ansible.builtin.package:
        name: policycoreutils-python-utils
        state: present
    - name: Create the dedicated content directory
      ansible.builtin.file:
        path: /srv/dr-status
        state: directory
        owner: root
        group: root
        mode: '0755'
    - name: Maintain the persistent path-to-type mapping
      community.general.sefcontext:
        target: '/srv/dr-status(/.*)?'
        setype: httpd_sys_content_t
        state: present
    - name: Install synthetic read-only content
      ansible.builtin.copy:
        content: "DR synthetic status page\n"
        dest: /srv/dr-status/index.html
        owner: root
        group: root
        mode: '0644'
    - name: Reconcile labels on existing files even if mapping did not change
      ansible.builtin.command:
        argv: [restorecon, -Rv, /srv/dr-status]
      register: relabel
      changed_when: relabel.stdout | length > 0
NA PRÁTICA

A regra é unchanged mas o label está errado; reconciliar o objeto continua necessário.

Armadilhas comuns

Confundir regra com label; depender apenas de notificação; permissive como aceitação; permissões Unix como explicação completa.

Tópicos relacionados: LVM, filesystem e montagem persistente · Serviços, firewall e validação externa

Leva esta ideia contigo

Verifica regra persistente, label efetivo e operação autorizada com a política ativa.

Criar conta

Referência: SELinux path mapping module · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned

Red Hat®, RHCE e Ansible são marcas comerciais ou marcas registadas de Red Hat, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Red Hat. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.