RBAC - es muss nicht immer "root" sein 1 RBAC Oder – es muss nicht immer „root“ sein

RBAC - es muss nicht immer "root" sein 2 Einführung Root ist der Administrations-User auf Unix-Systemen. Für Ihn gibt es keine Begrenzung in dem was er tun kann. Das Konzept, ein Unix-System durch einen Administrator mit praktisch unbegrenzten Privilegien verwalten zu lassen, stammt aus den späten 60er Jahren. Nicht einmal Microsoft verwendet heute noch ein solch undifferenziertes Administrationskonzept. Unter Windows lassen sich Gruppen mit Sätzen von Privilegien einrichten, durch Zugehörigkeit einzelner User zu den Gruppenlassen sich die Privilegien steuern. Wie kann der „Oldie“ Unix ohne Bruch mit etablierten Mechanismen auf ähnliche Weise administriert werden ?

RBAC - es muss nicht immer "root" sein 3 Alternativen Augen zu und durch – nach dem Urteil des BGH zur Verant- wortung des RZ-Leiters keine gute Idee, der haftet jetzt persönlich Arbeit mit Gruppen-Account oder mit Gruppenpasswörtern. Davon wird so streng abgeraten, dass ich nicht einmal weiss, wie man Gruppenpasswörter implementiert. Access-Control Lists – für mich ein weisser Fleck auf der Landkarte. Wer weiss mehr ? Sudo – ist begrenzt auf das lokale System RBAC Solaris, RSBAC / Linux Power Broker

RBAC - es muss nicht immer "root" sein 4 IST-Zustand User werden in der /etc/passwd angelegt und erhalten eine eindeutige User- ID (uid) User sind Mitglied einer Default-Gruppe und möglicherweise mehrerer alternativer Gruppen. Im Kontext der Shell, mit der der User arbeitet, sind uid und gid hinterlegt. Sie werden vereinfacht mit den zu Dateien oder Verzeichnissen hinterlegten abgeglichen. Ein Programm darf ich ausführen, wenn ich –entweder der Eigentümer bin –Mitglied der benannten Gruppe –Irgend jemand bin und jeder Zugriff besitzt je nachdem, wie die Zugriffsrechte (file-Permissions) auf die Datei durch den Eigentümer (oder root) eingerichtet wurden.

RBAC - es muss nicht immer "root" sein 5 Praktisches Beispiel User werden in der Datei /etc/passwd definiert: –chris:x:100:10::/home/chris:/bin/sh Gruppen werden in der Datei /etc/group definiert: –staff::10: Bei Anmeldung eines Benutzers übernimmt seine Shell die User-id (uid) und Group-id (gid) des angemeldeten Benutzers: – $ id –uid=100(chris) gid=10(staff) Die uid und gid bestimmen die Möglichkeiten des Benutzers, sich im Dateisystem zu bewegen und Dateien zu bearbeiten oder Programme aus zu führen: –$ ls -ld. –drwxr-x chris staff 1024 Apr 24 00:56.

RBAC - es muss nicht immer "root" sein 6 Programmaufruf Ein Benutzer kann ein Programm dann ausführen, wenn seine Zugriffsrechte dafür ausreichen: –Er muss (vereinfacht) lesenden Zugriff auf das Verzeichnis mit dem Programm haben und für alle Verzeichnisse, auf die das Programm zugreift –Er, seine Gruppe oder jeder muss (vereinfacht) das Programm ausführen dürfen, dafür muss er es nicht lesen können (logisch, oder ? ) Über ein sogenanntes suid (set-uid) Bit kann das Programm auch mit den Privilegien eines anderen, höher privilegierten Users ausgeführt werden. Das ist aber kaum individuell steuerbar und zudem ein erhebliches Sicherheitsrisiko. Denn je nach Permissions kann jedes Mitglied einer Gruppe (staff) oder einfach jeder das (privilegierte) Programm aufrufen. Hat das auch noch Sicherheitslücken, dann ist der Notfall schneller da, als man glaubt.

RBAC - es muss nicht immer "root" sein 7 Schwachpunkte des Konzepts Die File-Permissions in lokalen File-Systemen sind gültig für lokale User, wobei ein durch NIS oder NIS+ authentifizierter User (lokal angemeldet) für Unix ein lokaler User ist. Bei NFS-gemounteten Verzeichnissen und Dateien wird es noch komplizierter, da darf root gar nichts, wenn er nicht auf dem exportierenden Server als Admin eingetragen worden ist. Lokale User (auf dem Client) müssen den gleichen Namen und die gleich uid besitzen, wie auf dem Server, sonst gibt’s leicht Stress.

RBAC - es muss nicht immer "root" sein 8 Die Lösung durch RBAC Eine mögliche Lösung für dieses Problem bietet RBAC „Role based access control“ (Rollenbasierte Zugriffssteuerung). (ab Solaris 8 ) RBAC basiert auf definierten Profilen / Rollen, die einem User zugewiesen werden. Jede Rolle enthält einen Satz von einem oder mehr Privilegien (authorizations), der die Möglichkeit des Users zum Aufruf administrativer Programme einschränkt oder erweitert. Entsprechend werden die File-Permissions jetzt so gesetzt, dass administrative Programme grundsätzlich von jedem gelesen und ausgeführt werden können. Über die Prüfung der Privilegien ermittelt der Systemkern, ob ein User ein Programm (ggf. mit welchen Optionen) aufrufen darf, oder eben auch nicht. Mit Konfigurationsdateien sieht das im übrigen ganz anders aus, da sind die Zugriffsrechte überaus restriktiv zu handhaben. RBAC kann lokal, aber via NIS+ auch netzwerkweit konfiguriert werden. Es gibt ein API (application programming interface) [siehe rbac (5)] und ein Kommandozeilen-Utility [siehe auth(1) ], das erlaubt, RBAC auch in Shell-Scripts zu verwenden. SUN liefert RBAC mit den für die Administration eines Systems erforderlichen kompletten Satz von Privilegien und Profilen aus.

RBAC - es muss nicht immer "root" sein 9 Der Ablauf einer Autorisation unter RBAC In der Datei auth_attr sind die verschiedenen „Autorisationen“/Privilegien aufgelistet: –solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html –solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html –solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html –solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html Nach diesen Privilegien sucht die Funktion chkauthattr() in der Datenbasis, beginnend mit der Datei policy_attr. Die „policy_attr“ enthält als Grundaustattung nur eine Default-Autorisation und ein Default-Profil. –AUTHS_GRANTED=solaris.device.cdrw –PROFS_GRANTED=Basic Solaris User Entspricht das nicht der geforderten Autorisation, wird überprüft, ob dem User ein bestimmtes Tätigkeitsprofil, eine Rolle in der Datei „user_attr“ zugewiesen wurde. –chris::::profiles=Printer Management;type=normal

RBAC - es muss nicht immer "root" sein 10 Der Ablauf einer Autorisation unter RBAC (2) Gibt es für den User hier einen oder mehrere Einträge, dann werden die zu diesem Profil gehörigen Autorisierungen in der Datei „prof_attr“ nachgesehen. –Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.html;auths=solaris.admin.printer.read,sola ris.admin.printer.modify,solaris.admin.printer.delete In „prof_attr“ werden einem Profil / einer Rolle die dazu gehörigen Autorisierung zugeordnet. Im obrigen Beispiel sind alle Funktionen, die ein Printeradmin benötigt in dem Profil „PrinterManagement“ zusammen gefasst. Durch Zuordnung mehrerer Profile zu einer userid können Autorisierungen entsprechend der Aufgabenbereiche der User festgelegt werden.

RBAC - es muss nicht immer "root" sein 11 Beispiel einer Autorisierung User chris will einen neuen Drucker anlegen und gibt das Kommando $ /usr/lib/lpadmin -p printer -v device ein. Dann prüft das Programm „lpadmin“, ob chris über die Autorisierung „solaris.admin.printer.modify“ aus auth_attr verfügt. Hier eine sinnvolle Autorisation zu finden, ist Aufgabe des Softwarentwicklers. –solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html Die Suche in „policy_attr“ im Key AUTHS_GRANTED liefert etwas anderes (solaris.device.cdrw), also wird als nächstes in „user_attr“ gesucht. In user_attr findet man unter chris –chris::::profiles=Printer Management;type=normal

RBAC - es muss nicht immer "root" sein 12 Beispiel einer Autorisierung (2) In prof_attr wird nun nachgesehen, welche Autorisationen sich hinter „Printer Management“ verbergen: –Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.html;auths=solaris.admin.printer.read,sola ris.admin.printer.modify,solaris.admin.printer.delete Die gesuchte Autorisation ist dabei, die Benutzung des Programmes „lpadmin“ (mit den administrativen Optionen) wird nun gestattet. Anderenfalls wird eine Fehlermeldung ausgegeben. „You are not allowed, to do that.“

RBAC - es muss nicht immer "root" sein 13 Ende Workshop und Ausprobieren auf der mitgebrachten SUN