staging.inyokaproject.org

Hallo zusammen,

ich möchte meinen kürzlich angemieteten Rootserver so dicht und sicher wie möglich machen. Zu diesem Zweck will ich die Serverdienste "chrooten". Ich frage mich nun, ob es nicht ausreicht, "einfach" alle Webdienste (Apache, MySQL, PHP, Perl, Ruby, ISPConfig) in eine einzige chroot-Umgebung zu pressen. Oder sollte ich tatsächlich den Aufwand betreiben und jeden Dienst einzeln chrooten? Das wird ja allein schon dann Ärger machen, wenn bspw. PHP und MySQL kommunizieren wollen, oder? Oder Apache und MySQL.

Was meint ihr? Reicht eine chroot-Umgebung oder soll ich für jeden Dienst eine einzelne nehmen?

Außerdem habe ich gerade einen sehr merkwürdigen Fehler, wenn ich eine Anwendung aus ihrem chroot jail starten möchte. Ich habe mithilfe des Tools makejail eine chroot-Umgebung für ProFTPD erstellt und versuche nun, den Dienst aus diesem zu starten. Verwenden tu ich dafür folgenden Befehl und erhalte folgende Fehlermeldung:

1
2

web:/var/chroot/proftpd# chroot /var/chroot/proftpd/ usr/sbin/proftpd 
chroot: cannot run command `usr/sbin/proftpd': No such file or directory

Hier der Verzeichnisbaum der chroot-Umgebung:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148

./
|-- bin
|   |-- bash
|   `-- sh -> bash
|-- etc
|   |-- cron.monthly
|   |   `-- proftpd
|   |-- default
|   |   `-- proftpd
|   |-- ftpusers
|   |-- init.d
|   |   `-- proftpd
|   |-- pam.d
|   |   `-- proftpd
|   `-- proftpd
|-- lib
|   |-- libacl.so.1 -> libacl.so.1.1.0
|   |-- libacl.so.1.1.0
|   |-- libattr.so.1 -> libattr.so.1.1.0
|   |-- libattr.so.1.1.0
|   |-- libc-2.3.6.so
|   |-- libc.so.6 -> libc-2.3.6.so
|   |-- libcom_err.so.2 -> libcom_err.so.2.1
|   |-- libcom_err.so.2.1
|   |-- libcrypt-2.3.6.so
|   |-- libcrypt.so.1 -> libcrypt-2.3.6.so
|   |-- libdl-2.3.6.so
|   |-- libdl.so.2 -> libdl-2.3.6.so
|   |-- libm-2.3.6.so
|   |-- libm.so.6 -> libm-2.3.6.so
|   |-- libncurses.so.5 -> libncurses.so.5.5
|   |-- libncurses.so.5.5
|   |-- libnsl-2.3.6.so
|   |-- libnsl.so.1 -> libnsl-2.3.6.so
|   |-- libpam.so.0 -> libpam.so.0.79
|   |-- libpam.so.0.79
|   |-- libpthread-2.3.6.so
|   |-- libpthread.so.0 -> libpthread-2.3.6.so
|   |-- libresolv-2.3.6.so
|   |-- libresolv.so.2 -> libresolv-2.3.6.so
|   |-- libwrap.so.0 -> libwrap.so.0.7.6
|   `-- libwrap.so.0.7.6
|-- lib64 -> /lib
|-- usr
|   |-- bin
|   |   |-- ftpcount
|   |   |-- ftpdctl
|   |   |-- ftptop
|   |   |-- ftpwho
|   |   `-- perl
|   |-- lib
|   |   |-- libcrypto.so.0.9.8
|   |   |-- libgcrypt.so.11 -> libgcrypt.so.11.2.2
|   |   |-- libgcrypt.so.11.2.2
|   |   |-- libgnutls.so.13 -> libgnutls.so.13.0.9
|   |   |-- libgnutls.so.13.0.9
|   |   |-- libgpg-error.so.0 -> libgpg-error.so.0.3.0
|   |   |-- libgpg-error.so.0.3.0
|   |   |-- libk5crypto.so.3 -> libk5crypto.so.3.0
|   |   |-- libk5crypto.so.3.0
|   |   |-- libkrb5.so.3 -> libkrb5.so.3.2
|   |   |-- libkrb5.so.3.2
|   |   |-- libkrb5support.so.0 -> libkrb5support.so.0.0
|   |   |-- libkrb5support.so.0.0
|   |   |-- liblber.so.2 -> liblber.so.2.0.130
|   |   |-- liblber.so.2.0.130
|   |   |-- libldap_r.so.2 -> libldap_r.so.2.0.130
|   |   |-- libldap_r.so.2.0.130
|   |   |-- libmysqlclient.so.15 -> libmysqlclient.so.15.0.0
|   |   |-- libmysqlclient.so.15.0.0
|   |   |-- libperl.so.5.8 -> libperl.so.5.8.8
|   |   |-- libperl.so.5.8.8
|   |   |-- libpq.so.4 -> libpq.so.4.1
|   |   |-- libpq.so.4.1
|   |   |-- libsasl2.so.2 -> libsasl2.so.2.0.22
|   |   |-- libsasl2.so.2.0.22
|   |   |-- libssl.so.0.9.8
|   |   |-- libtasn1.so.3 -> libtasn1.so.3.0.6
|   |   |-- libtasn1.so.3.0.6
|   |   |-- libz.so.1 -> libz.so.1.2.3
|   |   |-- libz.so.1.2.3
|   |   `-- proftpd
|   |       |-- mod_ctrls_admin.a
|   |       |-- mod_ctrls_admin.la
|   |       |-- mod_ctrls_admin.so
|   |       |-- mod_facl.a
|   |       |-- mod_facl.la
|   |       |-- mod_facl.so
|   |       |-- mod_ifsession.a
|   |       |-- mod_ifsession.la
|   |       |-- mod_ifsession.so
|   |       |-- mod_ldap.a
|   |       |-- mod_ldap.la
|   |       |-- mod_ldap.so
|   |       |-- mod_quotatab.a
|   |       |-- mod_quotatab.la
|   |       |-- mod_quotatab.so
|   |       |-- mod_quotatab_file.a
|   |       |-- mod_quotatab_file.la
|   |       |-- mod_quotatab_file.so
|   |       |-- mod_quotatab_ldap.a
|   |       |-- mod_quotatab_ldap.la
|   |       |-- mod_quotatab_ldap.so
|   |       |-- mod_quotatab_sql.a
|   |       |-- mod_quotatab_sql.la
|   |       |-- mod_quotatab_sql.so
|   |       |-- mod_radius.a
|   |       |-- mod_radius.la
|   |       |-- mod_radius.so
|   |       |-- mod_ratio.a
|   |       |-- mod_ratio.la
|   |       |-- mod_ratio.so
|   |       |-- mod_rewrite.a
|   |       |-- mod_rewrite.la
|   |       |-- mod_rewrite.so
|   |       |-- mod_sql.a
|   |       |-- mod_sql.la
|   |       |-- mod_sql.so
|   |       |-- mod_sql_mysql.a
|   |       |-- mod_sql_mysql.la
|   |       |-- mod_sql_mysql.so
|   |       |-- mod_sql_postgres.a
|   |       |-- mod_sql_postgres.la
|   |       |-- mod_sql_postgres.so
|   |       |-- mod_tls.a
|   |       |-- mod_tls.la
|   |       |-- mod_tls.so
|   |       |-- mod_wrap.a
|   |       |-- mod_wrap.la
|   |       `-- mod_wrap.so
|   |-- sbin
|   |   |-- ftpasswd
|   |   |-- ftpquota
|   |   |-- ftpshut
|   |   |-- ftpstats
|   |   |-- in.proftpd -> proftpd
|   |   `-- proftpd
|   `-- share
|       `-- proftpd
|           `-- templates
|               |-- modules.conf
|               |-- proftpd.conf
|               `-- welcome.msg
`-- var
    |-- log
    |   `-- proftpd
    `-- run
        `-- proftpd

Danke für eure Hilfe und Meinungen Ulf

web:/var/chroot/proftpd# chroot /var/chroot/proftpd/ usr/sbin/proftpd 

Vielleicht eher so:

web:/var/chroot/proftpd# chroot /var/chroot/proftpd/ /usr/sbin/proftpd 

Da du für alle Dienste den gleichen Benutzer einsetzt (www-data) wirst du wohl alles in einen chroot-Umgebung packen müssen. Bin mir aber nicht ganz sicher.

Bringt leider genau den gleichen Fehler:

1
2

web:/var/chroot/proftpd# chroot /var/chroot/proftpd/ /usr/sbin/proftpd 
chroot: cannot run command `/usr/sbin/proftpd': No such file or directory

Ich hatte eigentlich nicht vor, für alles den gleichen Benutzer einzusetzen. Dienste wie MySQL, ProFTP, etc. laufen alle unter ihrem eigenen Benutzer:

1
2
3

proftpd   8922  0.0  0.1  53212  1752 ?        Ss   16:33   0:00 proftpd: (accepting connections)
www-data  2670  0.0  0.8 169624  9192 ?        S    15:15   0:00 /usr/sbin/apache2 -k start
mysql     2246  0.0  2.1 146552 22508 ?        Sl   15:15   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock

um nur ein paar Beispiele zu nennen. Einige (wie bspw. der Courier oder Postfix) laufen gar als root.

Das Kommando hinter chroot (also der 2. Parameter) muss auch im chroot sein, es wird nicht das Programm aus dem Laufenden System genommen, d.h. der sucht proftpd auch im chroot, wo es vermutlich nicht mit drin ist.

mfg Betz Stefan

hm. Ich gebe zu das ich mich mit chroot nie rchtig auseinandergesetzt habe - war mir zu umständlich. Könntest Du das gleiche mit so ziemlich der gleichen Sicherheit nicht auch mit sehr restriktiven AppArmor Einstellungen erreichen? Dann kannst Du auch Zugriffe auf Dateisysteme wie /proc oder /dev Einschränken - ein Apache mag proc" brauchen (oder auch nicht, weiß ich nicht auswendig), braucht aber kaum das Recht /proc/cpuinfo auszulesen, und sowas lässt sich wahrscheinlich mit AppArmor leichter und m.E. eleganter machen.

Oder wenn Du Bibliotheken aus /usr/lib brauchst... dann musst Du die nicht einzeln kopieren sondern beschränkst den Zugriff auf die, die es braucht. Du kannst auch so machen wie verhindern, dass Dateien aus /etc/apache2 ausgeführt werden...

Oder Du kannst verhindern, dass Code aus .jpg Dateien geladen wird, obwohl Apache natürlich lesend darauf zugreifen könnte...

Die Anwendung komplett einschließen ist natürlich sehr sicher.. Die Frage ist ob sich das noch lohnt... gerade dafür hat Ubuntu ja so großen Wert darauf gelegt AppArmor einzuführen...

PS: Selbst wenn man nicht vorhat AppArmor zu benutzen könnte es im Complaint Mode eine gute Hilfe sein um rauszufinden was man jeweils in die chroot Umgebung packen muss... kein Mensch kennt alle Bibliotheken.

Rabenschwinge schrieb:

hm. Ich gebe zu das ich mich mit chroot nie rchtig auseinandergesetzt habe - war mir zu umständlich.

Viele Serverdienste verfügen oft schon über einen chroot Mode, von daher ist es nichtmal mehr umständlich. Bei einigen Diensten ist ein chroot schon Standard!

Könntest Du das gleiche mit so ziemlich der gleichen Sicherheit nicht auch mit sehr restriktiven AppArmor Einstellungen erreichen?

Idealerweise sollte man beide Techniken kombinieren, den auch aus einem chroot kann man ausbrechen! Wichtig ist daher in erste Linie das der user unter dem der Dienst läuft nichts oder nicht viel anderes machen kann.

kein Mensch kennt alle Bibliotheken.

ldd ist dein Freund!

mfg Betz Stefan

encbladexp schrieb:

Das Kommando hinter chroot (also der 2. Parameter) muss auch im chroot sein, es wird nicht das Programm aus dem Laufenden System genommen, d.h. der sucht proftpd auch im chroot, wo es vermutlich nicht mit drin ist.

mfg Betz Stefan

Guck dir meinen Verzeichnisbaum doch mal an 😉 Es ist in dem Verzeichnis.

Stimmt, die Libs sind ja auch alle drin? (Mit bash in die chroot, und da mal ldd programm machen).

mfg Betz Stefan

Warum nicht gleich eine Virtualisierungslösung heranziehen? Macht auch chrooting überflüssig... ?!

When Not to Use chroot

lilith2k3 schrieb:

Macht auch chrooting überflüssig... ?!

Kanonen und Spatzen...

Sinnvoller wäre es einfach den proftpd mit AppArmor abzusichern!

mfg Betz Stefan

encbladexp schrieb:

Stimmt, die Libs sind ja auch alle drin? (Mit bash in die chroot, und da mal ldd programm machen).

Japp. Aber daran kann es bei dieser Fehlermeldung ja eigentlich auch nicht liegen, oder?

mfg Betz Stefan

Gruß Ulf

derulf schrieb:

ich möchte meinen kürzlich angemieteten Rootserver so dicht und sicher wie möglich machen. Zu diesem Zweck will ich die Serverdienste "chrooten". Ich frage mich nun, ob es nicht ausreicht, "einfach" alle Webdienste (Apache, MySQL, PHP, Perl, Ruby, ISPConfig) in eine einzige chroot-Umgebung zu pressen.

PHP, Perl und Ruby sind keine Webdienste, sondern Programmiersprachen. Willst du den Perl-Interpreter in eine Chroot-Umgebung sperren? Eine ISPConfig-Installation in einem chroot-Gefängnis erscheint mir auch recht sinnfrei. Was willst du denn in einem chroot damit verwalten?

Was meint ihr?

chroot weglassen. Es bringt keinen großen Sicherheitsgewinn. Mit Privilegien bricht der Angreifer einfach aus, ohne wird er eh versuchen, Privilege Escalation Lücken auszunutzen, und bricht dann eben ein bisschen später aus. fnordschrat hat recht, wenn er die Meinung der Kernelentwickler hier einbringt. Sichere Dienstkonfigurationen, tägliche Updates und vielleicht noch ein bisschen SELinux bringen mehr.

Außerdem habe ich gerade einen sehr merkwürdigen Fehler, wenn ich eine Anwendung aus ihrem chroot jail starten möchte. Ich habe mithilfe des Tools makejail eine chroot-Umgebung für ProFTPD erstellt und versuche nun, den Dienst aus diesem zu starten.

vsftpd unterstützt chroot ohne zusätzliche Anpassungen, was bei FTP ja dann auch sinnvoll ist.

Lunar schrieb:

derulf schrieb:

ich möchte meinen kürzlich angemieteten Rootserver so dicht und sicher wie möglich machen. Zu diesem Zweck will ich die Serverdienste "chrooten". Ich frage mich nun, ob es nicht ausreicht, "einfach" alle Webdienste (Apache, MySQL, PHP, Perl, Ruby, ISPConfig) in eine einzige chroot-Umgebung zu pressen.

PHP, Perl und Ruby sind keine Webdienste, sondern Programmiersprachen. Willst du den Perl-Interpreter in eine Chroot-Umgebung sperren? Eine ISPConfig-Installation in einem chroot-Gefängnis erscheint mir auch recht sinnfrei. Was willst du denn in einem chroot damit verwalten?

Ja, dass das keine Dienste sind, ist mir schon klar, würde eben die Interpreter einsperren wollen. Aber jetzt, da ich genauer drüber nachdenke... das wird nicht ganz ohne. Und ISPConfig zu "chrooten" ist wirklich total sinnfrei, da gebe ich dir recht.

Was meint ihr?

chroot weglassen. Es bringt keinen großen Sicherheitsgewinn. Mit Privilegien bricht der Angreifer einfach aus, ohne wird er eh versuchen, Privilege Escalation Lücken auszunutzen, und bricht dann eben ein bisschen später aus. fnordschrat hat recht, wenn er die Meinung der Kernelentwickler hier einbringt. Sichere Dienstkonfigurationen, tägliche Updates und vielleicht noch ein bisschen SELinux bringen mehr.

OK, danke für diese Meinung.

Außerdem habe ich gerade einen sehr merkwürdigen Fehler, wenn ich eine Anwendung aus ihrem chroot jail starten möchte. Ich habe mithilfe des Tools makejail eine chroot-Umgebung für ProFTPD erstellt und versuche nun, den Dienst aus diesem zu starten.

vsftpd unterstützt chroot ohne zusätzliche Anpassungen, was bei FTP ja dann auch sinnvoll ist.

OK, danke 😉

Ich werd das mal durchdenken, aber wenn chroot wirklich nichts oder nicht so viel bringt, werde ich wohl drauf verzichten.