problemas com stunnel systemd unit file

0

Gostaria de criar um arquivo de unidade para stunnel e não consigo entender por que ele está falhando.

Meu stunnel.conf é este:

#Provide the full path to your certificate-key pair file

cert = /etc/pki/tls/certs/stunnel.pem

#lock the process into a chroot jail

chroot = /var/run/stunnel

# and create the PID file in this jail

pid = /stunnel.pid

#change the UID and GID of the process for security reasons
setuid = nobody
setgid = nobody

#enable client mode
client = yes


socket = l:TCP_NODELAY=1
#socket = r:TCP:NODELAY=1

[mysqls]
accept = 127.0.0.1:3306
connect = 10.0.0.3:3307

Quando executo stunnel /etc/stunnel/stunnel.conf , funciona.

Aqui está meu arquivo de unidade do sistema para stunnel:

[Unit]
;Description=SSL tunnel for network daemons
;Documentation=man:stunnel https://www.stunnel.org/docs.html
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=stunnel.target

[Service]
Type=forking
User=nobody
Group=nobody
RuntimeDirectory=stunnel
ExecStartPre=-/usr/bin/mkdir /var/run/stunnel
ExecStartPre=-/user/bin/chown nobody:nobody /var/run/stunnel
ExecStart=/bin/stunnel /etc/stunnel/stunnel.conf
ExecStop=/bin/killall -9 stunnel

Quando eu tento iniciá-lo, systemctl start mystunnel.service falha com

Job for mystunnel.service failed because the control process exited with error code. See "systemctl status mystunnel.service" and "journalctl -xe" for details.

Executando journalctl -xe :

Feb 20 19:26:07 otrs1 polkitd[610]: Registered Authentication Agent for unix-process:14179:2643087 (system bus name :1.62 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, loc
Feb 20 19:26:07 otrs1 systemd[1]: Starting mystunnel.service...
-- Subject: Unit stunnel-otrs.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mystunnel.service has begun starting up.
Feb 20 19:26:07 otrs1 mkdir[14185]: /usr/bin/mkdir: cannot create directory ‘/var/run/stunnel’: File exists
Feb 20 19:26:07 otrs1 systemd[14186]: Failed at step EXEC spawning /user/bin/chown: No such file or directory
-- Subject: Process /user/bin/chown could not be executed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The process /user/bin/chown could not be executed and failed.
--
-- The error number returned by this process is 2.
Feb 20 19:26:08 otrs1 stunnel[14188]: Clients allowed=500
Feb 20 19:26:08 otrs1 stunnel[14188]: stunnel 4.56 on x86_64-redhat-linux-gnu platform
Feb 20 19:26:08 otrs1 stunnel[14188]: Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013
Feb 20 19:26:08 otrs1 stunnel[14188]: Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
Feb 20 19:26:08 otrs1 stunnel[14188]: Reading configuration from file /etc/stunnel/stunnel.conf
Feb 20 19:26:08 otrs1 stunnel[14188]: FIPS mode is enabled
Feb 20 19:26:08 otrs1 stunnel[14188]: Compression not enabled
Feb 20 19:26:08 otrs1 stunnel[14188]: PRNG seeded successfully
Feb 20 19:26:08 otrs1 stunnel[14188]: Initializing service [mysqls]
Feb 20 19:26:08 otrs1 stunnel[14188]: Certificate: /etc/pki/tls/certs/stunnel.pem
Feb 20 19:26:08 otrs1 stunnel[14188]: Error reading certificate file: /etc/pki/tls/certs/stunnel.pem
Feb 20 19:26:08 otrs1 stunnel[14188]: error queue: 140DC002: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib
Feb 20 19:26:08 otrs1 stunnel[14188]: error queue: 20074002: error:20074002:BIO routines:FILE_CTRL:system lib
Feb 20 19:26:08 otrs1 stunnel[14188]: SSL_CTX_use_certificate_chain_file: 200100D: error:0200100D:system library:fopen:Permission denied
Feb 20 19:26:08 otrs1 stunnel[14188]: Service [mysqls]: Failed to initialize SSL context
Feb 20 19:26:08 otrs1 stunnel[14188]: str_stats: 12 block(s), 1050 data byte(s), 696 control byte(s)
Feb 20 19:26:08 otrs1 polkitd[610]: Unregistered Authentication Agent for unix-process:14179:2643087 (system bus name :1.62, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Feb 20 19:26:08 otrs1 systemd[1]: stunnel-otrs.service: control process exited, code=exited status=1
Feb 20 19:26:08 otrs1 systemd[1]: Failed to start stunnel-otrs.service.
-- Subject: Unit stunnel-otrs.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit stunnel-otrs.service has failed.
--
-- The result is failed.
Feb 20 19:26:08 otrs1 systemd[1]: Unit mystunnel.service entered failed state.
Feb 20 19:26:08 otrs1 systemd[1]: mystunnel.service failed.

Eu não sei porque dá o erro que ele não pode criar o diretório (aparentemente porque existe) mas não é! Além disso, por que não está lendo o certificado? Por que rodar manualmente funciona. O SELinux está desativado.

EDITAR:

df -h

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/cl-root   14G  1.9G   13G  14% /
devtmpfs             234M     0  234M   0% /dev
tmpfs                245M   54M  191M  22% /dev/shm
tmpfs                245M  4.4M  240M   2% /run
tmpfs                245M     0  245M   0% /sys/fs/cgroup
/dev/sda1           1014M  138M  877M  14% /boot
tmpfs                 49M     0   49M   0% /run/user/0

EDIT2:

Depois de aplicar as sugestões do ErikF, o diretório existe problema desapareceu, mas ainda está falhando ao ler o certificado:

   Feb 20 20:42:59 otrs1 polkitd[610]: Registered Authentication Agent for unix-process:16232:3104221 (system bus name :1.73 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, loc
    Feb 20 20:42:59 otrs1 systemd[1]: Starting stunnel-otrs.service...
    -- Subject: Unit stunnel-otrs.service has begun start-up
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- Unit stunnel-otrs.service has begun starting up.
    Feb 20 20:42:59 otrs1 stunnel[16239]: Clients allowed=500
    Feb 20 20:42:59 otrs1 stunnel[16239]: stunnel 4.56 on x86_64-redhat-linux-gnu platform
    Feb 20 20:42:59 otrs1 stunnel[16239]: Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013
    Feb 20 20:42:59 otrs1 stunnel[16239]: Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
    Feb 20 20:42:59 otrs1 stunnel[16239]: Reading configuration from file /etc/stunnel/stunnel.conf
    Feb 20 20:42:59 otrs1 stunnel[16239]: FIPS mode is enabled
    Feb 20 20:42:59 otrs1 stunnel[16239]: Compression not enabled
    Feb 20 20:42:59 otrs1 stunnel[16239]: PRNG seeded successfully
    Feb 20 20:42:59 otrs1 stunnel[16239]: Initializing service [mysqls]
    Feb 20 20:42:59 otrs1 stunnel[16239]: Certificate: /etc/pki/tls/certs/stunnel.pem
    Feb 20 20:42:59 otrs1 stunnel[16239]: Error reading certificate file: /etc/pki/tls/certs/stunnel.pem
    Feb 20 20:42:59 otrs1 stunnel[16239]: error queue: 140DC002: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib
    Feb 20 20:42:59 otrs1 stunnel[16239]: error queue: 20074002: error:20074002:BIO routines:FILE_CTRL:system lib
    Feb 20 20:42:59 otrs1 stunnel[16239]: SSL_CTX_use_certificate_chain_file: 200100D: error:0200100D:system library:fopen:Permission denied
    Feb 20 20:42:59 otrs1 stunnel[16239]: Service [mysqls]: Failed to initialize SSL context
    Feb 20 20:42:59 otrs1 stunnel[16239]: str_stats: 12 block(s), 1050 data byte(s), 696 control byte(s)
    Feb 20 20:42:59 otrs1 polkitd[610]: Unregistered Authentication Agent for unix-process:16232:3104221 (system bus name :1.73, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
    Feb 20 20:42:59 otrs1 systemd[1]: stunnel-otrs.service: control process exited, code=exited status=1
    Feb 20 20:42:59 otrs1 systemd[1]: Failed to start stunnel-otrs.service.
    -- Subject: Unit stunnel-otrs.service has failed
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    --
    -- Unit stunnel-otrs.service has failed.
    --
    -- The result is failed.
    Feb 20 20:42:59 otrs1 systemd[1]: Unit stunnel-otrs.service entered failed state.
    Feb 20 20:42:59 otrs1 systemd[1]: stunnel-otrs.service failed.

Any ideas or hints please? 

Appreciate or help! 
    
por yesOrMaybeWhatever 06.03.2018 / 22:36

3 respostas

1

Você tem um erro de ortografia:

ExecStartPre=-/user/bin/chown nobody:nobody /var/run/stunnel

Você provavelmente quis dizer /usr/bin/chown , não /user/bin/chown .

Além disso, se /var/run for um link simbólico para /run , você provavelmente poderá substituir os comandos de criação de diretório por RuntimeDirectory=

RuntimeDirectory=stunnel
    
por 07.03.2018 / 04:36
0

Como visto em man systemd.service sob PermissionStartOnly= , por padrão, o comando ExecStartPre= será executado como o usuário fornecido em User= .

No seu exemplo, parece que você pretende que eles sejam executados como root , portanto, você deve definir:

 PermissionStartOnly=true
    
por 06.03.2018 / 22:50
0

Como abordar isso

Um serviço que deve ser executado em um gerenciador de serviços não deve tentar se auto-daemonizar, não deve usar o mecanismo de arquivo PID instável e perigoso e não deve (no caso muito comum) descartar privilégios em si. Tudo isso será feito pelo sistema de gerenciamento de serviços, adequadamente.

Então, quando você executou o stunnel na linha de comando, deveria ter feito o shell esperar até você terminar / parar o processo.

Toda a execução sob a égide de uma conta de usuário sem privilégios, configurando acesso reduzido ao sistema de arquivos e, na verdade (para aqueles programas capazes de herdar e usar descritores de arquivo de soquete aberto) abrindo o soquete de escuta é o domínio do gerenciamento de serviços .

É isso que as pessoas do sistema chamam ingenuamente de "estilo novo" de executar daemons. De fato, é exatamente assim que os usuários do daemontools vêm dizendo para administrar daemons nas últimas duas décadas, e que a IBM vem dizendo há um quarto de século.

Essa conta de usuário não privilegiada não deve ser nobody , que pode ser listada como proprietária dos arquivos. O serviço em questão não precisa de permissão de propriedade em qualquer arquivos ou diretórios , , então a conta de usuário sem privilégios deve ser criada expressamente para esse propósito, com algo como:

useradd --shell /usr/bin/true mysql-stunnel-d

Um ambiente chroot() para isso é realmente não-trivial para configurar no systemd, porque /bin/stunnel e todos os arquivos que ele lê (que, de acordo com seu doco, além do arquivo de certificado e arquivo de configuração também inclui bastante material do sistema, com coisas como /dev/zero , o sistema de configuração NSS e o banco de dados de fuso horário) precisam ser configurados com BindReadOnlyPaths . Uma abordagem mais simples é o mecanismo Protect… .

Arquivos de configuração

O soquete é descrito por uma unidade de soquete. stunnel não entende o protocolo LISTEN_FDS , mas é compatível com UCSPI-TCP. Portanto, a unidade de soquete tem que descrever um soquete de aceitação:

; /etc/systemd/service/mysql-stunnel.socket
[Unit]
Description=SSL wrapper for MySQL
Documentation=

[Socket]
ListenStream=127.0.0.1:mysql
ListenStream=[::1]:mysql
Accept=yes
NoDelay=yes

[Install]
WantedBy=multi-user.target

Observe que é o soquete que é ativado / desativado / iniciado / interrompido aqui, com systemctl . O serviço , descrito por uma unidade de serviço, é iniciado automaticamente sob demanda pelo soquete . Porque é uma tomada de aceitação, é uma unidade de serviço de modelo. Ele descreve todo o privilégio de descartar e configurar o gerenciamento de serviços:

; /etc/systemd/service/[email protected]
[Unit]
Description=SSL wrapper for MySQL
Documentation=

[Service]
Type=simple
User=mysql-stunnel-d
ProtectHome=yes
ProtectSystem=strict
PrivateTmp=yes
StandardInput=socket
StandardOutput=socket
StandardError=journal
ExecStart=/bin/stunnel /etc/stunnel/mysql-stunnel.conf

O arquivo de configuração stunnel não lida com qualquer das coisas que o gerenciamento de serviços faz por ele :

# /etc/stunnel/mysql-stunnel.conf
cert = /etc/pki/tls/certs/stunnel.pem
client = yes
foreground = yes
connect = 10.0.0.3:3307

Conteúdo de bônus

Sim, esta é a maneira dos daemontools. Passe esses dois arquivos de unidade por meio do convert-systemd-units do conjunto de ferramentas de dados e receba um programa run e service (entre vários outros) que exemplificam como isso é feito da maneira do daemontools, com um conjunto adequado de UCSPI de carregamento de corrente e outras ferramentas:

% system-control convert-systemd-units ./mysql-stunnel.socket
convert-systemd-units: WARNING: ./[email protected]: Forcing setting: [Service] StandardError = log
convert-systemd-units: WARNING: ./mysql-stunnel.socket: Unused setting: [unit] documentation = 
convert-systemd-units: WARNING: ./[email protected]: Unused setting: [service] standarderror = journal
convert-systemd-units: WARNING: ./[email protected]: Unused setting: [unit] documentation = 
% system-control cat ./mysql-stunnel
start:#!/bin/nosh                
start:#Start file generated from ./mysql-stunnel.socket
start:true
stop:#!/bin/nosh
stop:#Stop file generated from ./mysql-stunnel.socket
stop:true
run:#!/bin/nosh
run:#Run file generated from ./mysql-stunnel.socket
run:#SSL wrapper for MySQL
run:tcp-socket-listen 127.0.0.1 mysql
run:tcp-socket-listen "::1" mysql
run:move-to-control-group ../mysql-stunnel.service
run:envuidgid --supplementary -- mysql-stunnel-d
run:userenv-fromenv
run:unshare --mount
run:set-mount-object --recursive slave /
run:make-private-fs --temp --homes
run:make-read-only-fs --os --etc
run:set-mount-object --recursive shared /
run:setuidgid --supplementary -- mysql-stunnel-d
run:tcp-socket-accept --no-delay
run:./service
service:#!/bin/nosh
service:#Service file generated from ./[email protected]
service:#SSL wrapper for MySQL
service:/bin/stunnel /etc/stunnel/mysql-stunnel.conf
restart:#!/bin/sh
restart:#Restart file generated from ./[email protected]
restart:exec false  # ignore script arguments
%                                                                                                                                                                                           

Leitura adicional

por 07.03.2018 / 22:00