maschinenraum

sind die Fortsetzung der Graustufen mit anderen Mitteln. Behauptet zumindest der fröhlich wahnsinnige Autor von /dev/soup, der sonst auch die eine oder andere Weisheit im Netz findet.

hat's nie gegeben. Steht anscheindend auf einem der letzten Reste des Palastes der Republik. Zumindest hat der Dingens der da in Berlin dieses Fachdingends für Dingens betreibt da so ein Dingens ... äh Bildchen auf seinem Fachdingens.

Mehr will ich jetzt über den komischen Revisionismus der da in Mitte trotz der sonst schon langweiligen Neubauten dort einen noch viel langweiligeren entstehen lässt nicht schreiben. Da würd' ich mich nur wieder aufregen.

In den Kommentaren zu diesem Post hat Klaus Mebus -- Sicherheitschef des SCC -- den folgenden Text über die Probleme des SCC und die Umstellung von NIS auf LDAP hinterlassen, der hier nach Rücksprache mit ihm veröffentlicht wird:

Die Umstellung war für definitiv für März geplant. Die Voraussetzungen sollten u.a. mit der seit Juni 2008 laufenden und immer noch nicht abgeschlossenen Passwortsynchronisierung geschaffen werden. Wenn man ein Authentifizierungssystem umstellt, dann geht das in einer gewachsenen völlig heterogenen Umgebung mit verteilten Verantwortlichkeiten und einer möglichst geringen Beeinträchtigung aller Nutzer (wir haben über 7500 Accounts!) nicht auf die Schnelle, ohne das ggf. wichtige Prozesse beeinträchtigt werden. Das Problem war im übrigen nicht in erster Linie die Verwendung eines unsicheren Verschlüsselungsalgorithmus, sondern die Zugänglichkeit der NIS-Datenbank und der damit verbundenen Möglichkeit des Crackens der Passwort-Hashes. Hier machen es einem viele Nutzer sehr leicht, indem sie Passwörter verwenden, die die Bezeichnung kaum verdient haben. Hier hilft nicht mal die stärkste Verschlüsselung, wenn das bloße Raten ausreicht. Mir wäre es auch lieber, dass alle bekannten Misstände auf einen Schlag Geschichte wären, aber im SCC laufen eben noch viele andere Prozesse, die vielleicht nicht jeder auf den ersten Blick so sieht, und damit meine ich nicht nur die Standardaufgaben, sondern Projekte wie die gerade durchgeführte Storageumstellung. Umstellungen mit weitreichenden Folgen sollten gut geplant und ausreichend getestet werden, sonst kann es bei einer schnellen Implementierung auch wieder zu Fehlern kommen, die einem später auf die Füße fallen. Im Lehrbuch ist das immer einleuchtend und wenn meine seine(n) Home-PC oder Mac bearbeitet, geht das auch immer fix, aber hier geht es um wie gesagt um die komplette Infrastruktur eine Universität.
Schon mal versucht ein Passwortsystem für über 7500 accounts von Crypt auf MD5 (das wäre ja wohl die einzige Alternative im NIS) umzustellen? Funktioniert das überhaupt auf allen Systemen? Wie soll das Passwortsystem in der Übergangszeit crypt und MD5-Hashes gleichzeitig verarbeiten? Ist das überhaupt möglich? Sollten wir allen Nutzer das Passwort wegnehmen, alle accounts auf MD5 umstellen und dann jeder sich ein neues beim Benutzerservice abholen? Was machen die, die gerade nicht in Weimar sind?.... So easy ist das eben nicht.

Jedenfalls wurde die Umstellung nun angegangen und das bei vielen nicht ohne Schmerzen, die hätten vielleicht vermieden werden können, aber wir waren nun mal im Zugzwang und wollten und konnten nicht mehr warten. Ich hoffe jeder hat nun auch das Verständnis dafür, wenn eben mal temporär was nicht läuft, aber so ist das eben bei unplanmäßigen Änderungen und selbst bei einer guten Planung und Test kann es immer Fälle geben, bei denen Abhängigkeiten auftauchen, die man nicht voraussehen konnte.

In einer E-Mail fügte er an:

Bei neuen auf LDAP basierenden System werden wir natürlich bemüht sein einen Hash-Algorithmus zu verwenden, der die größt mögliche Sicherheit verspricht (SHA oder RIPEMD160). SHA-1 ist da zwar Standard bei LDAP, Bruce Schneier hat aber bereits 2005 auf Schwächen hingewiesen. Wenn es möglich ist werden wir also SHA-2 einsetzen und zusätzlich in jedem Fall dafür sorgen, dass man an die nicht mehr so einfach rankommt.

...use condom

Nun ist es soweit, ich fass es nicht.

Als Gründer distanziere ich mich hiermit öffentlich und betrachte das was da kommen wird.

Es kann nicht sein, das einige wenige bei FEiNT die Grundlagen der Ethik (Private Daten schützen, öffentlichen Daten Nützen) scheinbar weder verstanden haben, noch sie befolgen.

Vieleicht sollte zur Ethik in Zukunft auch , erst denken, dann Posten  gehören.

meint ein trauriger, kopfschüttelnder

sysTim

chmod ist das allseits beliebte unix tool um Daterichte zu setzen. Um nur ein paar bits zu verwackeln reicht meistens ein Befehl, wie chmod g=rw . um der Gruppe Lese- und Schreibzugriff auf das aktuelle Verzeichnis zu geben.
An Syntax reicht dafür meistens chmod [ugo][+-=][rwx] DATEI, manchmal auch mit -R für rekursive Operatioen, wobei user, group, other und read, write, execute fröhlich kombiniert werden können.

Worauf ich aber eigentlich hinaus wollte ist, dass viele Leute anscheinend die oktale Notation bevorzugen. Ab und zu vergesse ich wie sich die Rechte zusammen setzen obwohl das eigentlich ganz einfach ist:
Die letzten 3 Stellen des Blocks entsprechen jeweils den Benutzer-, Gruppen-, und Mobrechten. Als Nerd stellt man sich jede Ziffer am besten als Bitmaske der Form rwx mit dem höchstwertigsten Bit voran. Damit entspricht r der dezimalen 4, w der 2 und x der 1.
Jede Kombination der drei Rechte lässt sich so eindeutig als Summe darstellen.

Lacher am Rande: Ich wollte gerade ein Beispiel einbinden und erhalte fiesen Murx:
[wm@krtek tmp]$ ls -la foo
ls: Zugriff auf foo/. nicht möglich: Keine Berechtigung
ls: Zugriff auf foo/.. nicht möglich: Keine Berechtigung
insgesamt 0
d????????? ? ? ? ? ? .
d????????? ? ? ? ? ? ..

Das Beispiel sollte jedenfalls so aussehen:
drw-r--r-- 2 wm users 40 1. Dez 12:18 foo
als Bitmaske steht hier bei der Berechtigung
110100100
oder dezimal
420400400
und als Summe von jeweils 3 Bits
644

edit:

• In den man pages steht natürlich noch deutlich mehr!
• html-tag-Unglück verlagert
• Unglück entfernt