McLayn's questions

Estou tentando executar um podmanquadlet definido por um arquivo YML do kubernetes. Quero que ele seja executado sem root em systemdum webusuário no host: systemctl --user status pod-web.

Dentro do container, o processo PHP está rodando sob o 33:33usuário. Quero que o /home/web/datadiretório no host seja de propriedade do webusuário, mas ao mesmo tempo seja legível e gravável pelo 33:33usuário dentro do container, onde ele é montado em /var/www/html.

Nos comentários, você pode ver algumas coisas que tentei. Infelizmente, não entendo os namespaces de usuário e subuid/subgid o suficiente para conseguir fazer funcionar com a documentação e o Copilot continua alucinando, então qualquer ajuda de pessoas reais será apreciada.

Meu problema é semelhante a este , mas quero usar um podman kubequadlet definido em um arquivo YML.

Ambiente:

• AlmaLinux release 9.4 (Seafoam Ocelot)
• podman version 4.9.4-rhel
• systemd 252 (252-32.el9_4.7)
• SELinux habilitou a aplicação
• chown -R web:web /home/web
• usermod --add-subuids 100000-165535 --add-subgids 100000-165535 web

/home/web/pod-web.yml:

apiVersion: v1
kind: Pod
metadata:
  name: pod-web
#  annotations:
#    io.podman.annotations.userns: "keep-id"
spec:
  containers:
  - name: pod-web
    image: docker.io/library/php:8.3-apache
#    securityContext:
#      runAsUser: 33
#      runAsGroup: 33
#      supplementalGroups: [65536]
#    ports:
#    - containerPort: 80
#      hostPort: 8000
    volumeMounts:
    - mountPath: /var/www/html
      name: web-data
  volumes:
  - name: web-data
    hostPath:
      path: /home/web/data
  restartPolicy: Always

Com runAsUser: 33o container estava logando:

(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80

Com runAsUser: 0o contêiner parece funcionar, mas é uma prática ruim, pois concede muitos privilégios, se entendi corretamente.

/home/web/.config/containers/systemd/pod-web.kube:

[Unit]
Description=Podman Quadlet: %p

[Service]
# ExecStartPre=/usr/bin/podman unshare -- /bin/bash -c 'chown -R 33:33 /home/web/data'

[Kube]
Yaml=/home/web/%p.yml
LogDriver=journald
#UserNS=keep-id:uid=33,gid=33
#UserNS=auto

[Install]
WantedBy=multi-user.target default.target

Temos um servidor com SO Alma Linux 9.3. Por padrão (assim como todos os sistemas operacionais semelhantes ao RHEL atuais) ele está fapolicydhabilitado. Há também um servidor de aplicativos (WildFly/JBoss/Java) em execução nesse servidor. O aplicativo implantado processa alguns arquivos de dados (enviados pelos usuários) e funciona bem na situação padrão.

No entanto, atualmente, há um período em que o aplicativo precisa processar cerca de 1.000 arquivos por minuto. Em tal situação, a fapolicydsobrecarga utiliza aproximadamente 15% da CPU, o que avaliamos como excessivo.

Não consegui encontrar ninguém com problema semelhante na internet.

Também estou surpreso que não haja nenhuma fapolicydtag aqui no ServerFault.

Questões:

• Existe uma maneira de otimizar fapolicyda configuração para que ela possa decidir mais rapidamente se permite ou nega acesso a arquivos?
  • Uma coisa que me vem à mente é a ordenação das regras personalizadas.
  • Talvez usando curinga em vez de regras literais.
• Alguma dica de como avaliar o quanto fapolicydé importante para nós?
  • Se podemos simplesmente desligá-lo ou se é realmente uma boa ideia mantê-lo funcionando apesar da enorme sobrecarga.
  • Se outras distribuições também usam algo parecido fapolicydou se é "apenas segurança adicional" e SELinuxé suficiente. (Eu sei que eles não são iguais.)

Fontes:

• STIG recomenda ter fapolicydhabilitado
• Um artigo da Red Hat sobre os fundamentos dofapolicyd

Estou migrando as senhas do KeyCloak v15 (WildFly v23) do antigo cofre para o armazenamento de credenciais elytron. Funciona bem para o caso de uso padrão. Em standalone.xml, tenho: /server/extensions/extension:

<extension module="org.wildfly.extension.elytron"/>

/server/profile/subsystem:

<subsystem xmlns="urn:wildfly:elytron:13.0" final-providers="elytron" disallowed-providers="OracleUcrypto">
    <providers>
        <provider-loader name="elytron" module="org.wildfly.security.elytron"/>
    </providers>
    <audit-logging>
        <file-audit-log name="local-audit" path="audit-log.log" relative-to="jboss.server.log.dir" format="JSON"/>
    </audit-logging>
    <credential-stores>
        <credential-store name="credStore" location="/data/credStore.jceks">
            <implementation-properties>
                <property name="keyStoreType" value="JCEKS"/>
            </implementation-properties>
            <credential-reference clear-text="MASK-123456789;salt123;42"/>
        </credential-store>
    </credential-stores>
</subsystem>

e eu acesso as senhas usando /server/profile/subsystem[@xmlns="urn:jboss:domain:jgroups:8.0"]/stacks/stack[@name="tcp"]/auth-protocol/digest-token/shared-secret-reference:

<shared-secret-reference store="credStore" alias="myBlock::mySecret"/>

No entanto, há um segredo que preciso passar para um SPI em uma propriedade. Alguma ideia de como fazer? Esta era a maneira antiga do cofre:

/server/system-properties/property:

<property name="secret" value="${VAULT::myBlock::mySecret::1}"/>

/server/profile/subsystem[@xmlns="urn:jboss:domain:keycloak-server:1.1"]/spi:

<spi name="mySpi">
    <provider name="file" enabled="true">
        <properties>
            <property name="password" value="${secret}"/>
        </properties>
    </provider>
</spi>

Eu tenho um arquivo de configuração /etc/tmpfiles.d/test.conf:

z /dir/*         660 -    -    -
z /dir/subdir   2770 -    -    -
z /dir/subdir/*  660 -    -    -
Z /dir             - root test -

Quando eu executo systemd-tmpfiles --prefix=/dir --create /etc/tmpfiles.d/test.conf ; ll /dir, os direitos de acesso /dir/subdirsão aleatoriamente

• às vezes drwxrws---(da /dir/*regra) e
• às vezes drw-rw----(da /dir/subdirregra).

Como torná-lo determinístico?

O ponto é que o diretório /dircontém muitos arquivos e um subdiretório e eu quero definir rwdireitos de acesso aos arquivos e rwxdireitos de acesso ao subdiretório.

Centos 7

man tmpfiles.d

O CentOS imprime o seguinte durante a inicialização

[ ***  ] A stop job is running for Security Auditing Service (9s / 1min 30s)

e, em seguida, alterna para o modo de usuário único.