UUGRN:Jails/Konzept: Unterschied zwischen den Versionen
Rabe (Diskussion | Beiträge) (Linkfixes) |
Rabe (Diskussion | Beiträge) K (Linkfixes) |
||
Zeile 28: | Zeile 28: | ||
=== Übergabe / Root === | === Übergabe / Root === | ||
Die Mitglieder-Jails werden ohne Benutzeraccounts angelegt. | Die Mitglieder-Jails werden ohne Benutzeraccounts angelegt. | ||
Voraussetzung für die Schlüsselübergabe für den root-Zugriff ist ein [[UUGRN:Shell|Mitglieder-Account]] auf [[shell.uugrn.org]]. | Voraussetzung für die Schlüsselübergabe für den root-Zugriff ist ein [[UUGRN:Shell|Mitglieder-Account]] auf [[UUGRN:Jails/shell|shell.uugrn.org]]. | ||
Zunächst muss dort ein mit Passphrase gesicherter SSH-Key erzeugt werden: | Zunächst muss dort ein mit Passphrase gesicherter SSH-Key erzeugt werden: | ||
Zeile 48: | Zeile 48: | ||
Um im eigenen Jail später root werden zu können, muss der angelegte User in der wheel-Gruppe sein. Als primäre Gruppe wird man wohl i.d.R. "staff" nehmen und auf die Frage "Invite user to ... " zusätzlich "wheel" angeben, oder nachträglich in /etc/{{man|freebsd|5|group}} eintragen. | Um im eigenen Jail später root werden zu können, muss der angelegte User in der wheel-Gruppe sein. Als primäre Gruppe wird man wohl i.d.R. "staff" nehmen und auf die Frage "Invite user to ... " zusätzlich "wheel" angeben, oder nachträglich in /etc/{{man|freebsd|5|group}} eintragen. | ||
Der SSH-Rootzugriff von mitglied@[[shell.uugrn.org]] aus kann entweder bestehen bleiben, oder aber gelöscht werden. | Der SSH-Rootzugriff von mitglied@[[UUGRN:Jails/shell|shell.uugrn.org]] aus kann entweder bestehen bleiben, oder aber gelöscht werden. | ||
Hierzu ist es erforderlich, die Datei authorized_keys entsprechend zu bearbeiten: | Hierzu ist es erforderlich, die Datei authorized_keys entsprechend zu bearbeiten: | ||
Zeile 134: | Zeile 134: | ||
== Siehe auch == | == Siehe auch == | ||
* [[UUGRN:Jails]] | * [[UUGRN:Jails]] | ||
* [[ | :* [[UUGRN:Jails/Nutzungsbedingungen|Verbindliche Regeln für die Verwendung von UUGRN Jails]] | ||
:* [[UUGRN:Jails/intern/MySQL|MySQL Zugang auf dem zentralen MySQL Server]] | |||
* [[UUGRN:Server/top|top.uugrn.org]] | * [[UUGRN:Server/top|top.uugrn.org]] | ||
* [[UUGRN:Mailkonzept]] | * [[UUGRN:Mailkonzept]] | ||
* [[UUGRN:Mitgliedschaft]] | * [[UUGRN:Mitgliedschaft]] | ||
* [[Jail|Hintergrundinformationen zu BSD Jails]] | |||
[[Kategorie:UUGRN:Jail|!]] | [[Kategorie:UUGRN:Jail|!]] |
Version vom 9. April 2009, 18:03 Uhr
Das Jailkonzept wird ständig überarbeitet und angepasst.
Näheres dazu auf der Diskussionsseite. --RaBe 13:35, 13. Mai. 2007 (CEST)
Jails sind virtuelle Systeme in FreeBSD, die auf einem gemeinsamen Kernel laufen, jedoch voneinander getrennte Userlands haben, inkl. eigene Benutzer- und root-Rechte.
Dieser Artikel soll aufzeigen, was der Verein anbietet, welche Voraussetzungen es gibt und welche Mechanismen wirken.
Vereinsangebot
UUGRN e.V. bietet seinen Mitgliedern eigene virtuelle Root-Server auf Jail-Basis an. Diese Jails werden derzeit auf top.uugrn.org gehostet.
Darüber hinaus werden Jails für teils gemeinsam genutzt Infrastrukturdienste wie etwa Mailserver, Webserver, Shellserver etc. eingesetzt.
Nutzung
Das Jail-Konzept gewährt dem einzelnen Mitglied weitreichende Eigenverantwortung. Damit es jedoch nicht zu Betriebsbeeinträchtigungen kommt, müssen jewisse Standardregeln definiert und befolgt werden:
Verbindliche Policy
Vor der "Übergabe" eines Mitglieder-Jails muss die Jail-Policy anerkannt und unterschrieben werden. Diese definiert, was "fair use" darstellt.
- Die Grundpolicy enthält
- Erlaubt ist alles, was einem "fair use" entspricht.
Diese weitreichende Freiheit wird allerdings definierte Grenzen haben, die überprüft und durchgesetzt werden, um Mißbrauch vorzubeugen. Im Zweifel sind Aktionen vorher mit der Vereinsführung oder Administration abzustimmen. Sonderregelungen werden öffentlich dokumentiert (Transparenzgebot).
Einrichtung
Übergabe / Root
Die Mitglieder-Jails werden ohne Benutzeraccounts angelegt. Voraussetzung für die Schlüsselübergabe für den root-Zugriff ist ein Mitglieder-Account auf shell.uugrn.org. Zunächst muss dort ein mit Passphrase gesicherter SSH-Key erzeugt werden:
[mitglied@shell ~]$ ssh-keygen -t dsa
Standardmäßig werden hierbei die beiden Dateien ~/.ssh/id_dsa
und ~/.ssh/id_dsa.pub
erzeugt.
Vom Einrichter des Mitglieder-Jails wird mitglied@shell:~/.ssh/id_dsa.pub
an root@mitgliedsjail:.ssh/authorized_keys
angehängt, wodurch das Mitglied sein Jail initial als root einloggen kann:
[mitglied@shell ~]$ ssh root@meinjail.uugrn.org
Nach dem initialen root-Login sollte das root-Passwort unbedingt gesetzt werden:
[root@meinjail ~]# passwd
und normale Benutzeraccounts eingerichtet werden:
[root@meinjail ~]# adduser
Um im eigenen Jail später root werden zu können, muss der angelegte User in der wheel-Gruppe sein. Als primäre Gruppe wird man wohl i.d.R. "staff" nehmen und auf die Frage "Invite user to ... " zusätzlich "wheel" angeben, oder nachträglich in /etc/group(5) eintragen.
Der SSH-Rootzugriff von mitglied@shell.uugrn.org aus kann entweder bestehen bleiben, oder aber gelöscht werden. Hierzu ist es erforderlich, die Datei authorized_keys entsprechend zu bearbeiten:
[root@meinjail ~]# vi ~/.ssh/authorized_keys
Basis-Ausstattung
- FreeBSD Basissystem des jeweils aktuellen Releases
-
- Standardumfang des Basissystems
- Shells
-
- bash
- zsh
- ksh
- Standard-Tools
-
- coreutils (The Free Software Foundation's core utilities)
- findutils (The GNU find utilities)
- ImageMagick
- rsync
- sudo
- Console-Standardsoftware
-
- Midnight Commander
- mutt
- lynx
- Editoren
-
- vim 6
- nano
- Devel
-
- PERL 5.8
- Standardausstattung p5-Module
- Python
- PERL 5.8
- Web-Paket
-
- Apache 1.3.x mit mod_ssl
- div. Zusatzmodule
- PHP5 plus zahlreiche Module
- smarty
- mod_perl
- Apache 1.3.x mit mod_ssl
Systempflege und Betrieb
Basis-System
Die Jail-Basissysteme werden zunächst auf testjail.uugrn.org getestet. Wir werden auf den jeweiligen RELEASE-Ständen fahren. Updates des Basis-Systems in /usr/src werden von der Hauptmaschine aus durchgeführt, ebenso wie der idR erforderliche mergemaster. Dabei wird darauf geachtet, dass mauelle Änderungen in /etc nicht überschrieben werden. Bitte wichtige Änderungen mit Kommentar versehen (Zeile obendrüber) und selbst für Sicherheitskopien außerhalb von /etc sorgen.
Software
Vorkompilierte Packages können direkt aus dem Internet installiert werden. Es gibt darüber hinaus ein global verfügbares /usr/ports/, das read-only in allen Jails verfügbar ist. Über ein script auf top.uugrn.org werden regelmäßig alle Distfiles von installierten Ports aktualisiert und in /usr/ports/distfiles/ angeboten (prefetch). Siehe dazu FreeBSD Ports/readonly.
Backup
Die Jail-Maschine wird regelmäßig per rsync auf eine Ausweichmaschine kopiert. Derzeit findet dies 1x pro Tag morgens statt. Restore-Wünsche bitte sehr zeitnah kommunizieren.
Geplant ist der Betrieb eines Spiegel-Servers, der als Fallback und Backup läuft.
Eine individuelle Sicherung mit Historie/Rollback findet derzeit nicht statt.
Firewall
Die aktuelle Firewall-Policy für Mitglieder-Jails ist folgende:
- TCP und UDP
-
- Ein- und ausgehende Verbindungen für TCP und UDP sind frei
- Ausnahmen
-
- Port 25/tcp wird über zentrales MX angeboten (Spamschleudern etc), siehe UUGRN:Mailkonzept
- Port 53/udp wird über zentralen DNS gehostet. Einrichtung und Pflege eigener Domains ist möglich (über hidden Primary), siehe UUGRN:DNS-Konzept.
Auf speziellen Wunsch können weitere deny-Regeln eingerichtet werden
- Raw-Socket
-
- Zugriff auf den raw-Socket sind nicht möglich (z.B. tcpdump)
- ICMP (ping) ist aus den Jails heraus nicht möglich, top selbst ist allerdings in der Lage, auf allen IPs ICMP zu empfangen und zu senden.
Diese Policy kann sich jederzeit ändern oder erweitert werden.
Was tun im Nofall?
Jedes Mitglied kann sein eigenes Jail von innen heraus selbst stoppen:
als root einfach # kill -9 -1
ausführen, beendet alle Prozesse im Jail-Kontext, das Jail wird somit gestoppt.
Ein Neustart kann durch die Administration veranlasst werden.
Beendigung
- Ein Jail wird auf eigenen Wunsch des Mitglieds hin entweder zweitweise deaktiviert oder gelöscht, z.B. wenn keine weitere aktive Nutzung (und Pflege) mehr gewünscht ist bzw. stattfindet.
- Ein Jail wird im Notfall durch die Systemadministration deaktiviert und dokumentiert (z.B. bei Mißbrauch // Abwenden weiterer Schäden)
- Ein Jail wird auf eigenen Wunsch oder bei Vorliegen entsprechender Gründe gelöscht.
- Auf Wunsch kann das Jail in Form einer Datensicherung (Gnu-tar) zur Verfügung gestellt werden.