Re: grsec-2.6.17-7 exim4 saslauth
On Sun, 30 Jul 2006 17:11:16 +0200, Sven Hartge [EMAIL PROTECTED] wrote: Stefan Bauer [EMAIL PROTECTED] wrote: Sven Hartge schrieb: Ich zweifele daran, dass du hiermit sinnvolle Entropie erzeugst, vor allem, da sowohl /dev/urandom als auch /dev/random den gleichen Pool benutzen, der Unterschied ist lediglich, dass urandom auf eine Pseudo-Zufallsfunktion zurückfällt während random blockiert, wenn der Pool leer ist. Dem bin ich mir bewusst. Was bieten sich mir alternative Möglichkeiten sinnvolen Entropy zu erzeugen? Mein Board verfügt leider nicht über einen RNG den ich als Quelle verwenden könnte. Du könntest solange die Kernel-Developer anweinen, bis diese sich bewusst sind, das nicht jeder ein Serverboard hat und das headless server eben ein dauerhaftes Entropie-Problem haben, seit der Kernel so umgebaut wurde, dass nur noch Maus und Tastatur als Quelle herhalten können. Zum Glück hält auch die Platte als Entropiequelle her, so dass mit etwas sinnfreiem DD der Pool wieder aufgebaut werden kann. Sinnvoller wäre im konkreten Fall, den gnutls-Upstream anzuweinen, dass die ihre Library etwas sinnvoller mit der wertvollen Entropie umgehen lassen. Beispiel: Nur wenige Bytes Entropie ziehen, damit einen PRNG initalisieren, aus diesem dann die nächsten n Bytes Zufall erzeugen. n kann man im Zweifel auch noch mit echter Entropie variieren. Aber ich bekomme so langsam das Gefühl, dass die Gnutls-Leute gar nicht wollen, dass ihre Software auf breiter Front eingesetzt wird. Ohne User ist man ja viel sicherer. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: grsec-2.6.17-7 exim4 saslauth
Marc Haber [EMAIL PROTECTED] wrote: On Sun, 30 Jul 2006 17:11:16 +0200, Sven Hartge [EMAIL PROTECTED] wrote: Du könntest solange die Kernel-Developer anweinen, bis diese sich bewusst sind, das nicht jeder ein Serverboard hat und das headless server eben ein dauerhaftes Entropie-Problem haben, seit der Kernel so umgebaut wurde, dass nur noch Maus und Tastatur als Quelle herhalten können. Zum Glück hält auch die Platte als Entropiequelle her, so dass mit etwas sinnfreiem DD der Pool wieder aufgebaut werden kann. Ja, ich kenne das Script aus dem Debian-Exim-Wiki. Hat mir nur leider nicht viel geholfen (vermutlich nicht genug Kram auf der Platte), am Ende lief es dann alle 15 Minute. Meine Lösung war dann, den Exim gegen OpenSSL zu rekompilieren und das derzeit noch vorhandene SA_SAMPLE_RANDOM wieder den Netzkarten-Treibern zu implantieren, damit wenigstens ein klein wenig mehr Entropie entsteht. S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Markus Schulz schrieb: Falls du mehr zu dieser Thematik herausbekommst würde ich mich über eine Mail (oder via Liste) freuen. Problem solved: Der random / urandom Workaround geht zwar aber ist nicht elegant. Gewisse Aktionen verursachen mehr Input für /dev/random. Super ist hier scheinbar Mouse sowie Tastatur-Eingaben gefolgt von Netzwerkaktivitäten sowie HDD-Last. Um dies nachzustellen verwende ich jetzt rngd-tools (rngd) Dieses sammelt per default von einem Hardware-Zufalls-Nummern-Generator (Hardware RNG) und fütter damit den entropy-pool. Der Hardware RNG kann nur mit geladenem Kernel-Modul benutzt werden. Ich verwende folgende Methode von rngd-tools nun: (ohne Hardware RNG!) Input aus /dev/urandom Output in den entropy-Pool # rngd -b -r /dev/urandom (-b für background -r für die zu schöpfende Quelle) nach diesem Eingriff ist der Entropy-Pool prall gefüllt: /home/duke# cat /proc/sys/kernel/random/entropy_avail 11182 Anmerkung: Falls sich wer über den enorm hohen Entropy-Wert wundert, der wurde über die GRSEC Option verdoppelt, welcher ähnlich wie über die Werte in /proc/sys/kernel/random/poolsize agiert. -- Mit freundlichen Grüßen Stefan Bauer -- www.plzk.de - www.plzk.com --- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Stefan Bauer [EMAIL PROTECTED] wrote: Ich verwende folgende Methode von rngd-tools nun: (ohne Hardware RNG!) Input aus /dev/urandom Output in den entropy-Pool # rngd -b -r /dev/urandom (-b für background -r für die zu schöpfende Quelle) nach diesem Eingriff ist der Entropy-Pool prall gefüllt: Ich zweifele daran, dass du hiermit sinnvolle Entropie erzeugst, vor allem, da sowohl /dev/urandom als auch /dev/random den gleichen Pool benutzen, der Unterschied ist lediglich, dass urandom auf eine Pseudo-Zufallsfunktion zurückfällt während random blockiert, wenn der Pool leer ist. S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Sven Hartge schrieb: Ich zweifele daran, dass du hiermit sinnvolle Entropie erzeugst, vor allem, da sowohl /dev/urandom als auch /dev/random den gleichen Pool benutzen, der Unterschied ist lediglich, dass urandom auf eine Pseudo-Zufallsfunktion zurückfällt während random blockiert, wenn der Pool leer ist. Dem bin ich mir bewusst. Was bieten sich mir alternative Möglichkeiten sinnvolen Entropy zu erzeugen? Mein Board verfügt leider nicht über einen RNG den ich als Quelle verwenden könnte. -- Mit freundlichen Grüßen Stefan Bauer -- www.plzk.de - www.plzk.com --- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Stefan Bauer [EMAIL PROTECTED] wrote: Sven Hartge schrieb: Ich zweifele daran, dass du hiermit sinnvolle Entropie erzeugst, vor allem, da sowohl /dev/urandom als auch /dev/random den gleichen Pool benutzen, der Unterschied ist lediglich, dass urandom auf eine Pseudo-Zufallsfunktion zurückfällt während random blockiert, wenn der Pool leer ist. Dem bin ich mir bewusst. Was bieten sich mir alternative Möglichkeiten sinnvolen Entropy zu erzeugen? Mein Board verfügt leider nicht über einen RNG den ich als Quelle verwenden könnte. Du könntest solange die Kernel-Developer anweinen, bis diese sich bewusst sind, das nicht jeder ein Serverboard hat und das headless server eben ein dauerhaftes Entropie-Problem haben, seit der Kernel so umgebaut wurde, dass nur noch Maus und Tastatur als Quelle herhalten können. S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
grsec-2.6.17-7 exim4 saslauth
Guten Morgen, folgendes Problem habe ich nach der Umstellung von Kernel 2.6.11-12-grsec auf 2.6.17-7-grsec: Exim verweigert die Annahme von E-Mails mit TLS. Es kümmert sich saslauthd darum. Ich verwende das niedrigste Security-Level in grse. Saslauthd meldet mir trotz Debug-Flag keine brauchbaren Informationen und die Clients die versuchen Mails mit TLS zu verschicken erhalten nur die Meldung der Server verweigert die Verbindung. Exim schreibt keine Logs. In den Logs erscheint folgendes: Jul 29 09:47:30 main saslauthd[13238]: main: num_procs : 5 Jul 29 09:47:30 main saslauthd[13238]: main: mech_option: NULL Jul 29 09:47:30 main saslauthd[13238]: main: run_path : /var/run/saslauthd Jul 29 09:47:30 main saslauthd[13238]: main: auth_mech : shadow Jul 29 09:47:30 main saslauthd[13238]: ipc_init: using accept lock file: /var/run/saslauthd/mux.accept Jul 29 09:47:30 main saslauthd[13238]: detach_tty : master pid is: 0 Jul 29 09:47:30 main saslauthd[13238]: ipc_init: listening on socket: /var/run/saslauthd/mux Jul 29 09:47:30 main saslauthd[13238]: main: using process model Jul 29 09:47:30 main saslauthd[18277]: get_accept_lock : acquired accept lock Jul 29 09:47:30 main saslauthd[13238]: have_baby : forked child: 18277 Jul 29 09:47:30 main saslauthd[13238]: have_baby : forked child: 26975 Jul 29 09:47:30 main saslauthd[13238]: have_baby : forked child: 8517 Jul 29 09:47:30 main saslauthd[13238]: have_baby : forked child: 24992 Die Ausgabe sieht eigentlich ganz vernünftig aus. Ich verwende folgende Versionen: ii libgnutls13 1.4.0-2 ii libsasl2 2.1.19.dfsg1-0.2 ii sasl2-bin2.1.19-1.9 Über jegliche Hinweise dankbar. -- Mit freundlichen Grüßen Stefan Bauer -- www.plzk.de - www.plzk.com --- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Am Samstag, 29. Juli 2006 09:57 schrieb Stefan Bauer: Guten Morgen, folgendes Problem habe ich nach der Umstellung von Kernel 2.6.11-12-grsec auf 2.6.17-7-grsec: Exim verweigert die Annahme von E-Mails mit TLS. Es kümmert sich saslauthd darum. Ich verwende das niedrigste Security-Level in grse. Saslauthd meldet mir trotz Debug-Flag keine brauchbaren Informationen und die Clients die versuchen Mails mit TLS zu verschicken erhalten nur die Meldung der Server verweigert die Verbindung. Exim schreibt keine Logs. Start exim4 mal wie folgt als root auf einer Konsole: exim4 -bd -d+all und versuche eine Mail darüber zu senden. Dann siehst du an dem exim4 Output vielleicht woran es hängt. Den Output kannst du dann auch hier noch als Hilfestellung posten. Bei Problemen mit TLS vermute ich immer das die Entropy zu gering ist für das generieren des RSA Schlüssels. Ich behelfe mir dann immer mit Umstellen von /dev/random auf /dev/urandom. -- Markus Schulz This is Linux Land- In silent nights you can hear the windows machines rebooting
Re: grsec-2.6.17-7 exim4 saslauth
Markus Schulz schrieb: Start exim4 mal wie folgt als root auf einer Konsole: exim4 -bd -d+all danke für die rasche Antwort, 2006-07-29 10:15:13 SMTP connection from [80.226.138.102]:3169 I=[217.160.140.172]:25 (TCP/IP connection count = 1) 2006-07-29 10:15:18 ident connection to 80.226.138.102 timed out Exim erwartet also scheinbar einen Identd am Client? Bei Problemen mit TLS vermute ich immer das die Entropy zu gering ist für das generieren des RSA Schlüssels. Ich behelfe mir dann immer mit Umstellen von /dev/random auf /dev/urandom. das dürfe nicht der Fall sein: Habe extra im grsecurity setup folgende Option gesetzt: CONFIG_GRKERNSEC_RANDNET: If you say Y here, the entropy pools used for many features of Linux and grsecurity will be doubled in size. Since several grsecurity features use additional randomness, it is recommended that you say Y here. Saying Y here has a similar effect as modifying /proc/sys/kernel/random/poolsize. -- Mit freundlichen Grüßen Stefan Bauer -- www.plzk.de - www.plzk.com --- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Markus Schulz schrieb: Bei Problemen mit TLS vermute ich immer das die Entropy zu gering ist für das generieren des RSA Schlüssels. Ich behelfe mir dann immer mit Umstellen von /dev/random auf /dev/urandom. scheinbar liegt wirklich dort das Problem: sysctl -n kernel/random/entropy_avail 29 das ist ja armselig wenig. Wie ist das möglich? Der Entropy-Pool wird doch gesteigert, je mehr load die Kiste macht oder? ich habe auf ähnlichen Servern ohne ersichtliche Load einen 10 fach höheren Wert der Entropy. -- Mit freundlichen Grüßen Stefan Bauer -- www.plzk.de - www.plzk.com --- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: grsec-2.6.17-7 exim4 saslauth
Am Samstag, 29. Juli 2006 11:53 schrieb Stefan Bauer: Markus Schulz schrieb: Bei Problemen mit TLS vermute ich immer das die Entropy zu gering ist für das generieren des RSA Schlüssels. Ich behelfe mir dann immer mit Umstellen von /dev/random auf /dev/urandom. scheinbar liegt wirklich dort das Problem: sysctl -n kernel/random/entropy_avail 29 das ist ja armselig wenig. Wie ist das möglich? Der Entropy-Pool wird doch gesteigert, je mehr load die Kiste macht oder? ich habe auf ähnlichen Servern ohne ersichtliche Load einen 10 fach höheren Wert der Entropy. load allein reicht glaube ich nicht, IO-Last sollte glaube ich auch entstehen. Ich hab nämlich bereits des häufigeren erlebt, das Rechner wo /var größtenteils auf einer RamDisk liegt große Probleme in punkto Entropy machen. Dort benutze ich dann den urandom Workaround, da ich mir sonst nicht zu helfen wußte. Falls du mehr zu dieser Thematik herausbekommst würde ich mich über eine Mail (oder via Liste) freuen. -- Markus Schulz denn von vi bin ich erstmal grundsätzlich abgeschreckt und hoffe dass ich mich niemals damit auseinandersetzen muss :) Das hofft der vi von Dir übrigens auch. (Joerg Zimmermann)
