SELinux / PostgresQL “negou {open} para [..] comm =” pg_ctl “caminho =” $ PGDATA / postgresql.conf ”

3

Instalei o PostgresQL em uma caixa do Centos 7 habilitada para o SELinux e alterei seu diretório de dados padrão para / srv / postgres, um grupo de volume LVM / volume lógico criptografado por LUKS separado, por razões de mobilidade, no caso de eu ter que mover o servidor, e confidencialidade, se a mídia de dados for roubada ou exposta enquanto estiver em movimento. Eu acho que a funcionalidade LUKS / LVM envolvida não deve afetar o meu problema, mas mencioná-lo por razões de integridade.

Agora, quando eu inicio o serviço postgresql:

root@fafner:~ # systemctl start postgresql

... eu recebo isso em /var/log/audit/audit.log:

root@fafner:~ # tail -f /var/log/audit/audit.log | grep "postgresql" 
[..]
type=AVC msg=audit(1476614020.689:522): avc: denied  { open } for  pid=2900 comm="pg_ctl" path="/srv/postgres/data/postgresql.conf" dev="dm-4" ino=136 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1476614020.689:522): arch=c000003e syscall=2 success=no exit=-13 a0=7ffc681cc430 a1=0 a2=1b6 a3=24 items=1 ppid=1 pid=2900 auid=4294967295 uid=989 gid=986 euid=989 suid=989 fsuid=989 egid=986 sgid=986 fsgid=986 tty=(none) ses=4294967295 comm="pg_ctl" exe="/usr/bin/pg_ctl" subj=system_u:system_r:postgresql_t:s0 key=(null)
type=PATH msg=audit(1476614020.689:522): item=0 name="/srv/postgres/data/postgresql.conf" inode=136 dev=fd:04 mode=0100600 ouid=989 ogid=986 rdev=00:00 obj=unconfined_u:object_r:var_t:s0 objtype=NORMAL
type=AVC msg=audit(1476614020.725:523): avc: denied  { open } for  pid=2904 comm="postgres" path="/srv/postgres/data/postgresql.conf" dev="dm-4" ino=136 scontext=system_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file type=SYSCALL msg=audit(1476614020.725:523): arch=c000003e syscall=2 success=no exit=-13 a0=befc30 a1=0 a2=1b6 a3=24 items=1 ppid=2900 pid=2904 auid=4294967295 uid=989 gid=986 euid=989 suid=989 fsuid=989 egid=986 sgid=986 fsgid=986 tty=(none) ses=4294967295 comm="postgres" exe="/usr/bin/postgres" subj=system_u:system_r:postgresql_t:s0 key=(null)
type=PATH msg=audit(1476614020.725:523): item=0 name="/srv/postgres/data/postgresql.conf" inode=136 dev=fd:04 mode=0100600 ouid=989 ogid=986 rdev=00:00 obj=unconfined_u:object_r:var_t:s0 objtype=NORMAL
type=SERVICE_START msg=audit(1476614021.712:524): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=postgresql comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

Eu tentei usar o audit2allow para corrigir o problema:

root@fafner:~ # grep "postgresql" /var/log/audit/audit.log | audit2allow -M postgresql_tskjoedt
root@fafner:~ # semodule -i postgresql_tskjoedt.pp

... processando alguma saída em /var/log/audit/audit.log que eu removi do post desde que se mostrou irrelevante. Não resolveu o problema, no entanto, o erro persiste exatamente da mesma forma.

Eu também tentei:

root@fafner:~ # restorecon -Rv /usr/bin/pg_ctl
root@fafner:~ # restorecon -Rv /usr/bin/postgres
root@fafner:~ # restorecon -Rv /srv/postgres/data

... e até mesmo tocando um arquivo '.autorelabel' nos sistemas de arquivos root e postgres, e reinicializando, para re-marcar tudo o que estiver envolvido. Mas ainda recebo o mesmo erro "negado aberto para pg_ctl no postgresql.conf" em audit.log.

Eu fiz essas coisas algumas vezes, presumindo que as alterações não são cumulativas.

De esta resposta e alguns dos links aos quais ela se refere eu concluo que, de alguma forma, esses contextos / rótulos do SELinux não estão alinhados corretamente:

root@fafner:~ # ls -Z /usr/bin/pg_ctl
-rwxr-xr-x. root root system_u:object_r:postgresql_exec_t:s0 /usr/bin/pg_ctl
root@fafner:~ # ls -Z /usr/bin/postgres
-rwxr-xr-x. root root system_u:object_r:postgresql_exec_t:s0 /usr/bin/postgres
root@fafner:~ # ls -Z /srv/postgres/data/postgresql.conf
-rw-------. postgres postgres unconfined_u:object_r:var_t:s0   /srv/postgres/data/postgresql.conf

Eu poderia simplesmente embaralhar os rótulos até que algo possa começar a funcionar, mas eu não quero arbitrariamente definir ou arruinar os rótulos do SELinux apenas para fazer as coisas funcionarem; então eu poderia simplesmente desligar o SELinux.

Além disso, não entendo por que o 'audit2allow' não corrige o problema específico; Esse comando não deveria fazer exatamente isso, em essência, ampliar o contexto do SELinux apenas o suficiente para que a operação específica seja permitida?

Toda esta questão decorre, obviamente, da minha falta de compreensão do SELinux, e grande parte da saída do audit.log é relativamente obscura para mim. Alguém pode identificar a pista que eu deveria estar percebendo?

Atenciosamente,

LANerd

    
por LANerd 16.10.2016 / 13:31

1 resposta

3

Por que mudar o diretório de dados? Isso só faz sua vida complicada. Você poderia ter montado o sistema de arquivos no ponto do diretório de dados padrão, e tudo teria acabado de funcionar. Também seria mais fácil de entender e manter.

Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/volgroup-pgsql  1.1T  128K  1.1T   1% /var/lib/pgsql

Se você realmente quer manter o diretório de dados não-padrão, então você precisa dizer ao SELinux que contextos aplicar a esse diretório e seu conteúdo. Isso é feito com semanage fcontext . Nesse caso, vamos usar a opção --equal para fazer com que seu diretório não padrão tenha os mesmos contextos que o diretório padrão /var/lib/pgsql .

semanage fcontext --add --equal /var/lib/pgsql /srv/postgres

Da página do manual:

       -e EQUAL, --equal EQUAL
              Substitute  target  path with sourcepath when generating default
              label. This is used with fcontext. Requires  source  and  target
              path  arguments.  The context labeling for the target subtree is
              made equivalent to that defined for the source.

Isso é persistente, mas não altera os rótulos existentes. Para terminar, você precisará executar restorecon para redefinir todas as etiquetas.

restorecon -rv /srv/postgres
    
por 16.10.2016 / 18:15