Apache2.4 / FCGI / Chroot - Rechte probleme

[MarcoH]

Servus!

Ich versuche meine Benutzer in ihrem home Verzeichnis (gleichzeitig auch http) einzusperren. Das klappt soweit auch ganz gut.

Das eigentliche Problem ist dabei wohl FCGI

Chroot möchte alle Ordner oberhalb vom eigentlichen chroot als Besitzer root haben. fcgi läuft aber nicht wenn der ordner oberhalb von www gleich root ist.

Also die Rechte sehen momentan so aus:

--| drwxr-xr-x 4 root root 4096 Aug 25 12:46 DOMAIN (home des users unter /home)
---| drwxr-xr-x 2 DOMAIN DOMAIN 4096 Aug 25 12:47 www
----| -rw-r--r-- 1 DOMAIN DOMAIN 0 Aug 25 12:29 index.php

Wenn die rechte so gesetzt sind, kann ich mich per sftp als DOMAIN/USER einloggen. Apache bzw. FCGI verweigert aber seinen dienst mit:

[2016-08-25 13:04:23]: target uid/gid (1004/1004) mismatch with directory (0/0) or program (1004/1004)

Wenn ich diesen Fehler korrigiere sehen die rechte so aus:

--| drwxr-xr-x 4 DOMAIN DOMAIN 4096 Aug 25 12:46 DOMAIN (home des users unter /home)
---| drwxr-xr-x 2 DOMAIN DOMAIN 4096 Aug 25 12:47 www
----| -rw-r--r-- 1 DOMAIN DOMAIN 0 Aug 25 12:29 index.php

Dann funktioniert FCGI und ich kann index.php sauber aufrufen. Allerdings meckert dann SSH da ja alle ordner oberhalb von www root gehören müssen.

Fehler: fatal: bad ownership or modes for chroot directory "/home/DOMAIN"

Jetzt weis ich leider nicht weiter. Könnte mir da jemand bei helfen?

Vielen Dank

[Joe User]

Die index.php muss in /home/DOMAIN/www liegen, dann klappt es auch.

[MarcoH]

Die index.php muss in /home/DOMAIN/www liegen, dann klappt es auch.

Das tut sie doch auch. Wie oben beschrieben

--| drwxr-xr-x 4 root root 4096 Aug 25 12:46 DOMAIN (home des users unter /home)
------| drwxr-xr-x 2 DOMAIN DOMAIN 4096 Aug 25 12:47 www
----------| -rw-r--r-- 1 DOMAIN DOMAIN 0 Aug 25 12:29 index.php

[Joe User]

Hoppla, verguckt

Wie sehen denn Deine sshd_config und PHP-FPM-Pools aus und wie genau (exakte Schritte mit Beispieldaten bitte) legst Du Deine Web/SFTP-User an?
Ich glaube die Lösung zu kennen, muss es aber nochmal verifizieren, nicht dass ich Dein System verschlimmbessere.

[MarcoH]

Fangen wir mal bei einem Apache2 Virtual host an:

Code: Select all

<VirtualHost *:443>
  ServerName DOMAIN.de
  SSLEngine on
  SSLCertificateFile "/etc/ssl/DOMAIN.de.pem"
  SSLCertificateKeyFile "/etc/ssl/DOMAIN.de.key"
  ServerAdmin webmaster@DOMAIN.de
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains;"

  DocumentRoot /home/DOMAIN/DOMAIN/www
  SuexecUserGroup DOMAIN DOMAIN

  <Directory /home/DOMAIN/DOMAIN/www/>
    FCGIWrapper /home/DOMAIN/conf_DOMAIN .php
    <FilesMatch \.php$>
      SetHandler fcgid-script
    </FilesMatch>
    Options +ExecCGI
    AllowOverride All
    Require all granted
  </Directory>

  ErrorLog /var/log/apache2/DOMAIN-error.log
  LogLevel warn
  CustomLog /var/log/apache2/DOMAIN-access.log combined
</VirtualHost>

<VirtualHost *:80>
   ServerName DOMAIN.de
   Redirect permanent / https://DOMAIN.de
</VirtualHost>

<VirtualHost *:80>
   ServerName www.DOMAIN.de
   Redirect permanent / https://DOMAIN.de
</VirtualHost>

Jetzt die /home/DOMAIN/conf_DOMAIN

Code: Select all

#!/bin/sh
 export PHPRC="/etc/php5/cgi"
 exec /usr/bin/php5-cgi

Die /etc/apache2/mods-available/fcgid.conf

Code: Select all

<IfModule mod_fcgid.c>
DefaultMinClassProcessCount 0
IdleTimeout 300
IdleScanInterval 30
MaxProcessCount 15
PHP_Fix_Pathinfo_Enable 1
</IfModule>

Die /etc/ssh/sshd_conf / komplett original bis auf public_key only und:

Code: Select all

Subsystem sftp internal-sftp

Code: Select all

Match User DOMAIN
    ChrootDirectory %h
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

Die Rechte der ordner:

--| drwxr-xr-x 4 root root 4096 Aug 25 12:46 DOMAIN (home und = chroot des users unter /home)
------| drwxr-xr-x 2 root root 4096 Aug 25 12:47 DOMAIN
----------| drwxr-xr-x 2 DOMAIN DOMAIN 4096 Aug 25 12:47 DOMAIN
--------------| -rw-r--r-- 1 DOMAIN DOMAIN 0 Aug 25 12:29 index.php

Benutzer werden normal angelegt mit adduser -> name -> passwort und fertig. Was meinst du mit PHP-FPM-Pools?

So wie jetzt oben beschrieben kann ich mich per SFTP einloggen und unter /home/Domain/Domain/www schreiben
Chroot funktioniert wie gewünscht in /home/DOMAIN

Nur suexec sagt: target uid/gid (1004/1004) mismatch with directory (0/0) or program (1004/1004)

Ändere ich die rechte von /home/DOMAIN auf den user geht suexec und chroot nicht mehr.

Ich hoffe du kannst was damit anfangen

Grüße Marco

[Joe User]

Als Referenz mal eine von meinen Beispiel sshd_config

Code: Select all

#       $OpenBSD: sshd_config,v 1.97 2015/08/06 14:53:21 deraadt Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

Port 22
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes256-cbc
Macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1
RekeyLimit 500M 1h

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

LoginGraceTime 1m
PermitRootLogin prohibit-password
StrictModes yes
MaxAuthTries 3
MaxSessions 10

RSAAuthentication no
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable PAM authentication
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
PermitTTY yes
PrintMotd yes
TCPKeepAlive yes
UseLogin no
UsePrivilegeSeparation sandbox
PermitUserEnvironment no
Compression delayed
ClientAliveInterval 10
ClientAliveCountMax 6
UseDNS yes
PidFile /var/run/opensshd.pid
MaxStartups 10:30:100
PermitTunnel no
ChrootDirectory %h

Subsystem sftp internal-sftp -u 0027

AllowGroups wheel admin sshusers sftponly

Match User root
    ChrootDirectory none
    PasswordAuthentication no

Match Group admin
    ChrootDirectory none
    PasswordAuthentication no

Match Group sshusers
    ChrootDirectory none
    PasswordAuthentication no

Match Group sftponly
    ChrootDirectory /home
    PasswordAuthentication yes
    ForceCommand internal-sftp -d %u

Entscheidend sind hier "Subsystem ... -u 0027" (setzt die Zugriffsrechte für per SFTP übertragene Files/Dirs korrekt) und in "Match Group sftonly" das "ChrootDirectory /home" zusammen mit "ForceCommand ... -d %u" (chroot nach /home aber springt gleich nach /home/USER)
Statt mit "Match Group" kannst Du natürlich auch mit "Match User" arbeiten, das bleibt Dir überlassen.

Mit den Zugriffsrechten für die Verzeichnisse in /home musst Du bei Bedarf gemäss Deines Sicherheitskonzepts selbst spielen.


Hoffe das hilft Dir schonmal weiter.