Hi, hab es heute morgen geschafft (war eigentlich ganz einfach) mint linux auf einer zweiten Partition zu installieren. Bei den Dateirechten bin ich etwas stutzig geworden. Ist es wirklich so, dass man bei Linux für eine Datei nur die Rechte des Besitzers bzw. EINER Gruppe setzen kann? Unter Windows kann ich ja die Rechte beliebiger User auf eine Datei getrennt setzen. Auch können die Rechte für mehrere Gruppen für einzelne Dateien oder Ordner gesetzt werden. Ist Linux an dieser Stelle wirklich schwächer als Windows? Gruß Tom
War es lange Zeit, aber fast genauso lang gibt es schon ACL (access control lists) auch unter Linux. Die werden nur von den Standard-Tools nicht angezeigt.
Hallo, nein ganz im Gegenteil. Die Rechteverwaltung in Unixoiden System ist deutlich umfangreicher und kein Vergleich zu Windows. http://de.wikipedia.org/wiki/Unix-Dateirechte Schau dir die Details an, dann wirst du es sehen... Grüße aus Berlin
ah, ok dann hab ich das doch richtig verstanden. Dank Dir!
> http://de.wikipedia.org/wiki/Unix-Dateirechte
Die klassischen UGO/RWX-Rechte (wie im verlinkten Artikel beschrieben)
kann man wohl kaum als mächtiger ansehen als die NTFS-ACLs. Sie sind in
den meisten Fällen ausreichend, aber reichen nicht mal ansatzweise an
die Möglichkeiten von NTFS heran.
(Triviales Beispiel: Klassisch Unix erlaubt mir nicht, exakt zwei
Nutzern Rechte auf eine Datei zu geben, ohne denen eine eigene Gruppe
einzrichten. Mit ACLs ist das ganz einfach.
Zum Glück gibt es ACLs allerdings seit langem auch für Linux.
SW schrieb: > Die werden nur von den Standard-Tools nicht angezeigt. Auch Dateimanager aktueller Linux-Distros sind nicht unbedingt damit vertraut. Das macht den Umgang mit ACLs nicht einfacher.
:
Bearbeitet durch User
Rene Schube schrieb: > nein ganz im Gegenteil. Die Rechteverwaltung in Unixoiden System ist > deutlich umfangreicher und kein Vergleich zu Windows. > > http://de.wikipedia.org/wiki/Unix-Dateirechte ist zwar richtig, aber Windows ist an dieser stelle immer weiter. Die ACLs sind noch nur drangebastelt. Es fängt schon damit an, das alles nur über eine einfache ID abgebildet wird, wenn man von einem fremden System das System mountet stehen komplett anderen Namen und Gruppe da. Auch das Standard-Tool zum packen und sichern (TAR) ignoriert die ACLs. Die ACLs unter Windows sind immer kompletten System einheitlich, Registry, Devices, Pipes, Filesystem usw. Es gibt zwar wirklich dinge die bei Linux gut gelöst sind, aber die ACLs gehören, meiner Meinung nach, nicht dazu.
Thomas Burkhart schrieb: > Wie kann man die ACLs unter Linux denn benutzen? Hardcore: getfacl, setfacl.
Mit setfacl und getfacl (set bzw. get file acl). Näheres in den respektiven man pages. Außerdem: Das Dateisystem muß mit der Option acl gemountet sein. Eine (englische) Einführung: https://wiki.archlinux.org/index.php/Access_Control_Lists
Peter II schrieb: > Es gibt zwar wirklich dinge die bei Linux gut gelöst sind, aber die ACLs > gehören, meiner Meinung nach, nicht dazu. Dem stimme ich zu. Ich versuche sie wenn möglich zu vermeiden.
>> Es gibt zwar wirklich dinge die bei Linux gut gelöst sind, aber die ACLs >> gehören, meiner Meinung nach, nicht dazu. > Dem stimme ich zu. Ich versuche sie wenn möglich zu vermeiden. Handhabe ich ähnlich. Am Ende braucht man auch nur sehr selten mehr als den Unix-Standard (auch unter Windows), und so richtig extrem vermißt hab ich die Dinger früher(TM) auch nie. Es ist aber sehr schön, das es die Möglichkeit gibt, wenn es doch mal klemmt.
SW schrieb: > Am Ende braucht man auch nur sehr selten mehr als > den Unix-Standard (auch unter Windows) also zu Hause eventuell, in Firmen ist alles mögliche in Gruppen organisiert und da kommt es regelmäßig vor, das man einen Ordner für verschiedene Gruppe verschiedene Rechte gibt.
SW schrieb: > Die klassischen UGO/RWX-Rechte (wie im verlinkten Artikel beschrieben) > kann man wohl kaum als mächtiger ansehen als die NTFS-ACLs. Ein Klassiker dabei ist der Umgang mit dem Recht, Files löschen zu dürfen. Peter II schrieb: > in Firmen ist alles mögliche in Gruppen > organisiert und da kommt es regelmäßig vor, das man einen Ordner für > verschiedene Gruppe verschiedene Rechte gibt. Genau da liegt das Problem. Bei Desktops und den weitaus meisten Appservern ist das egal. Bei Fileservern hingegen sieht das anders aus. Das setzt sich dann bei unternehmensweiter Identität und der entsprechenden Verwaltung von Rechten in Gruppen und Gruppen aus Gruppen fort. Active Directory macht dabei erheblich mehr Spass, als die Pendants in Linux. Unix war nie auf eine solche Zentralisierung eingerichtet und alles was danach kam wurde an das eher schwache Unix-Identitäts- und Rechtemodell angeklebt. Ich will damit nicht sagen, dass es in Linux nicht ginge. Es geht schon.
:
Bearbeitet durch User
Peter II schrieb: > Es fängt schon damit an, das alles nur über eine einfache ID abgebildet > wird, wenn man von einem fremden System das System mountet stehen > komplett anderen Namen und Gruppe da. Das ist eine Schwäche von NFS. Du kannst ja die ACLs auch über SMB rausreichen. ;-) Habe mich aber lange nicht mehr mit NFS befasst. Möglicherweise sind aktuelle Versionen da besser. NFS ist halt zu Zeiten entworfen worden, als die Computerleistung noch deutlich schwächer war als heute, da wäre etwas wie ein komplettes Um-Mappen der User IDs im Kernel eine heftige Performance-Einbuße gewesen. Windows gab es zu dieser Zeit noch gar nicht, und MS-DOS konnte Netzwerkprotokolle damals nur mittels Zusatzpaketen abhandeln, die einem von den wertvollen 640 KiB Hauptspeicher eine nicht ganz unbeträchtliche Menge abgezogen haben … > Auch das Standard-Tool zum packen > und sichern (TAR) ignoriert die ACLs. Das Standard-Tool zum Sichern heißt pax. :-) (Ignoriert aber vermutlich ACLs genauso, weil es eine insgesamt eher stiefmütterlich behandelte Erfindung von Posix ist.) Wie heißt doch gleich das Standard-Tool zum Sichern unter Windows? :-) A. K. schrieb: > Ein Klassiker dabei ist der Umgang mit dem Recht, Files löschen zu > dürfen. Da drückt sich allerdings ein diametral anderer Ansatz unixoider Dateisysteme aus: eine Datei besteht eben aus der Datei selbst und den Verzeichniseinträgen, die auf sie zeigen. Damit wird das Recht zum Löschen als Schreibrecht auf dem Verzeichnis abgebildet. Ist aber zugegebenermaßen gewöhnungsbedürftig (wie das Konzept der hard links insgesamt).
Rene Schube schrieb: > nein ganz im Gegenteil. Die Rechteverwaltung in Unixoiden System ist > deutlich umfangreicher und kein Vergleich zu Windows. Dummschwatz! Das traditionelle UNIX-Rechtesystem ist extrem eingeschränkt, erst die ACLs haben das geändert. Und waren damit später dran als Windows. Nichtsdestotrotz reicht das traditionelle UNIX-System noch heute relativ weit. Und damals war es natürlich weit vorne.
Stefan Rand schrieb: > erst die ACLs haben das geändert. Und waren damit später dran als > Windows. So viel später nun auch wieder nicht. Die proprietären Unixe haben damit Anfang/Mitte der 1990er Jahre begonnen. Allerdings hat eben jeder sein eigenes Süppchen gekocht (Windows ja ebenfalls ;-), und der Standardisierungsversuch wurde anschließend auch noch zurückgezogen (laut Wikipedia). Entsprechend haben die freien Unixe erst sehr spät ACLs implementiert; das ist das, was hier die zeitliche Wahrnehmung etwas verschiebt.
Jörg Wunsch schrieb: > Du kannst ja die ACLs auch über SMB rausreichen. ;-) Das macht auch nicht wirklich Spass. Denn wenn man da nicht die Umsetzung der anderartigen NT-Rechte in die Linux-ACLs genau im Kopf hat, sondern Windows gewohnt ist, dann gibts bloss Fehlermeldungen oder seltsame Rechte. > Habe mich aber lange nicht mehr mit NFS befasst. > Möglicherweise sind aktuelle Versionen da besser. Mit NFS4 hat sich anscheinend etwas getan. > NFS ist halt zu Zeiten entworfen worden, als die Computerleistung noch > deutlich schwächer war als heute Bei einer Sicherheitsphilosophie, die weitgehend davon ausgeht, dass der zugreifende Client schon sicher ist und weiss was er tut, würde man heute die Hände über dem Kopf zusammenschlagen. ;-) Auch heute noch finden sich NFS Services, deren Sicherheit eigentlich nur in der Kontrolle der IP-Adresse des Clients besteht. Weil der Client stets mit "root" zugreift (VMware).
:
Bearbeitet durch User
Jörg Wunsch schrieb: > So viel später nun auch wieder nicht. Die proprietären Unixe haben > damit Anfang/Mitte der 1990er Jahre begonnen. Allerdings hat eben > jeder sein eigenes Süppchen gekocht (Windows ja ebenfalls ;-) Der Unterschied: Mit Windows NT wurde ein komplexes Sicherheits- und Rechtekonzept von Grund weg ins System eingebaut. Dave Cutler, der Chefdesigner von NT, kam ja von DEC und kannte daher das für damalige Verhältnisse recht hoch entwickelte Rechtekonzept von VMS. In Unix hingegen musste jede Erweiterung in das bestehende sehr einfache Konzept integriert bzw. daran angeklebt werden.
:
Bearbeitet durch User
A. K. schrieb: > Dave Cutler, der Chefdesigner von NT, kam ja von DEC und kannte daher > das für damalige Verhältnisse recht hoch entwickelte Rechtekonzept von > VMS. Ja, WNT = VMS + 1. :) (Jeder Buchstabe um eins hochgezählt …)
Stefan Rand schrieb: > Und damals war es natürlich weit vorne. Es war für die Verhältnisse der Entstehungszeit und der dafür eingesetzten Maschinen recht ordentlich. Aber ebendiese Maschinen und die angepeilte Einfachheit des Gesamtsystems setzten natürliche Grenzen. Unix entstand ja schon von der Namensgebung her als einfaches Gegenmodell zum komplexen Multics, und obwohl ich Multics nicht kenne, gehe ich davon aus, dass es (auch) in dieser Hinsicht erheblich komplexer war (Ritchie: "The problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system.") In den 70ern kam dann DEC VMS mit einem ebenfalls deutlich weiter entwickelten Rechtemodell. Ungefähr zu der Zeit, zu der Unix grössere Bekanntheit erlangte. Nur standen VMS mit den VAXen deutlich mehr Ressourcen zur Verfügung, als Unix auf den PDP-11ern. Nur bei den PC-Betriebssystemen hatte Unix einen gewissen Vorsprung. Gegenüber DOS und Windows 16-Bit ist alles eine Verbesserung ;-). Wie es gegen Novell aussieht weiss ich allerdings nicht. Immerhin war Novell lange Zeit der dominante Fileserver im PC-Umfeld.
:
Bearbeitet durch User
Lustigerweise findet man im Netz wenn man nach Dateirechten und Linux und Windows sucht immer noch jede Menge Artikel die behaupten, dass das Linuxrechte system besser und sicherer wäre.... Es lebe die Ideeologie...
Thomas Burkhart schrieb: > Lustigerweise findet man im Netz wenn man nach Dateirechten und Linux > und Windows sucht immer noch jede Menge Artikel die behaupten, dass das > Linuxrechte system besser und sicherer wäre.... Man muss zwischen der Praxis eine Systems und dessen technischen Grundlagen und Möglichkeiten unterscheiden. In Linux haben Anwender seit jeher meist unter ihrem eigenen Account gearbeitet, mit entsprechend eingeschränkten Rechten. Desktop-Linuxe ermöglichen oft einen individuellen Übergang zu administrativen Tätigkeiten, indem beim Aufruf eine Bestätigung/Password verlangt wird. In Windows war es bis einschliesslich XP völlig üblich, dass Hinz und Kurz auf seinem PC als Administrator agierte. Nur in Firmen war es verbreitet, normale Benutzer mit eingeschränkten Rechten agieren zu lassen (aber auch nicht selbstverständlich). Mit Vista hat sich das geändert, nun ist immerhin eine Bestätigung für administrative Tätigkeiten nötig, oberflächlich vergleichbar zu den Linux-Desktops. Das ist freilich die Praxis der Systeme. Die sicherheitstechnischen Grundlagen der Kernels und der Filesysteme sind eine gänzlich andere Baustelle. So lassen sich beispielsweise die Administrationsrechte in Windows einzeln fein aufdröseln, während das traditionelle und auch heute auf vielen Systemen übliche Unix-Prinzip mit "root" alles freischaltet. Auf Filesysteme bezogen bedeutet es auch, dass der Admin eines normalen Linux-Systems an alle Files direkt rankommt. Während das in Windows verhindert werden kann, ohne jedoch dem Admin beispielsweise die Möglichkeit von Backup/Restore dieser Files zu nehmen. Man kann in Linux mit entsprechend eingerichteten Zusatzfunktionen sicherlich viele der Schwächen wieder reparieren. Nur wurde dafür in Linux mit der Zeit viel nachgearbeitet und es wurden optionale Zusätze angebaut, die in Standardsystemen oft nicht aktiv sind. In Windows ist es umgekehrt. Das Zeug war von Anfang an drin, wurde und wird aber nur in geringem Umfang genutzt. > Es lebe die Ideeologie... Ich arbeite beruflich wie auch privat mit beiden Systemen gleichermassen. Beide haben ihre Vor- und Nachteile. Das Thema dieses Threads beleuchtet auch nur einen Teilaspekt dieser Systeme.
:
Bearbeitet durch User
Fein granulare ACLs (egal welches System) neigen dazu völlig auszuarten und in Folge versteht niemand mehr die Zugriffsrechte. Ich empfehle jedoch sich mal mit den setuid, setgid und sticky Bits unter Unix zu beschäftigen, damit lassen sich Standartzugriffs Probleme recht übersichtlich lösen.
A. K. schrieb: > Auf Filesysteme bezogen bedeutet es auch, dass der Admin eines normalen > Linux-Systems an alle Files direkt rankommt. Während das in Windows > verhindert werden kann, ohne jedoch dem Admin beispielsweise die > Möglichkeit von Backup/Restore dieser Files zu nehmen. Wenn jemand Backup/Restore auf alle Files machen kann, dann kommt derjenige an alle Files ran.
Jörg Wunsch schrieb: > Das Standard-Tool zum Sichern heißt pax. :-) (Ignoriert aber > vermutlich ACLs genauso, weil es eine insgesamt eher stiefmütterlich > behandelte Erfindung von Posix ist.) Es sollen nicht die ACLs mit gesichertwerden sondern die "Extended file attributes" damit landen auch die SE-Linux Label im Backup. Und SE-Linux bietet sehr weitgehende Möglichkeiten. Gibt es was vergleichbares für Windows?
setter schrieb: > Wenn jemand Backup/Restore auf alle Files machen kann, dann kommt > derjenige an alle Files ran. Aber nur mit dem Backup-API des Systems. Oder an den Backup-Stream, nur hilft dir der nicht unmittelbar weiter, weil das kein normales und damit einfach verarbeitbares Fileformat ist. Inwieweit das einen Zugriff auf den Inhalt wirklich effektiv verhindern kann weiss ich jetzt auch nicht. Aber auf die übliche Tour per Explorer kommst du jedenfalls an den Inhalt nicht ran. Und nach dem Restore nach woanders auch nicht, denn dann hängen wieder die vorherigen Rechte dran. Mit Zugriff auf die Disk kommst du andererseits an alles ran, was nicht verschlüsselt ist. Also flugs ein Knoppix gestartet und schon sieht die Welt wieder offener aus. ;-)
:
Bearbeitet durch User
setter schrieb: > Und SE-Linux bietet sehr weitgehende Möglichkeiten. Gibt es was > vergleichbares für Windows? Dazu kann ich leider nichts sagen, weil ich mit SELinux nicht vertraut bin.
A. K. schrieb: > Und nach dem Restore hängen dann wieder die vorherigen > Rechte dran. ... die Du aber nach einem restore auf einem anderen Sytem beliebig (Besitz übernehmen) anpassen kannst. Ich lach mich immer tot wenn der Serverraum mit den irrwitzigsten Zugangssystemen gesichert ist die Sicherungsmedien aber bei der Sekretärin in Haufen auf dem Schreibtisch rumliegen. Stefan
Stefan schrieb: > ... die Du aber nach einem restore auf einem anderen Sytem beliebig > (Besitz übernehmen) anpassen kannst. Du bist dir sicher, dass du den Besitz auch dann übernehmen kannst, wenn du das Recht, den Besitz zu übernehmen, nicht hast? Das ist nämlich auch eines der Einzelrechte von Files und Directories.
:
Bearbeitet durch User
A. K. schrieb: > Stefan schrieb: >> ... die Du aber nach einem restore auf einem anderen Sytem beliebig >> (Besitz übernehmen) anpassen kannst. > > Du bist dir sicher, dass du den Besitz auch dann übernehmen kannst, wenn > du das Recht, den Besitz zu übernehmen, nicht hast? Das ist nämlich auch > eines der Rechte. Auf dem anderen System ist man natürlich Root.
Stefan schrieb: > (Besitz übernehmen) anpassen kannst. Ich lach mich immer tot wenn der > Serverraum mit den irrwitzigsten Zugangssystemen gesichert ist die > Sicherungsmedien aber bei der Sekretärin in Haufen auf dem Schreibtisch > rumliegen. Klar. Das gehört ebenfalls zum allseits geliebten Thema "Theorie vs. Praxis". Bis direkt in die NSA hinein - immerhin hatte Snowden offenbar wenig Probleme, seinen Kollegen kritische Passwörter abzuluchsen. Ich wüsste ja wirklich zu gerne, ob die Chinesen nicht lieber die Amis schnüffeln lassen um dann das Ergebnis zu lesen, als selber teuer schnüffeln zu müssen. Aber das ist ein anderes Thema. ;-)
Ja, als Administrator eines Systems geht das. Wie gesagt die Besitzübernahme muss auf einem System erfolgen auf das man vollständigen Zugriff hat. Du hättest ja sonst keine Möglichkeit Zugriff auf Datenträger eines verreckten Systems zu bekommen dessen (nicht Standard) ACLS ja mit ihm sterben. Stefan
setter schrieb: > Auf dem anderen System ist man natürlich Root. In diesem Fall geht es um Windows, nicht von Linux. Und da gibts in den ACLs von Files und Directories ein Recht namens "Besitz übernehmen". Wenn du das bei diesem File nicht hast, dann sollte es nicht möglich sein, den Besitz zu übernehmen. Jedenfalls nicht via API und ohne Hacks.
:
Bearbeitet durch User
Stefan schrieb: > Du hättest ja sonst keine Möglichkeit Zugriff auf > Datenträger eines verreckten Systems zu bekommen dessen (nicht Standard) > ACLS ja mit ihm sterben. Verwaltet werden Rechte über die SIDs, und die SID der lokalen Administratorgruppe ist bei allen Systemen gleich. Meist hat diese Gruppe von Haus aus alle Rechte, und deshalb lassen sich Fremdmedien direkt übernehmen. Bei einem File, auf das diese SID das Recht "Besitz übernehmen" jedoch nicht hatte, sehe ich auch auf einem anderen System schwarz.
:
Bearbeitet durch User
A. K. schrieb: > setter schrieb: >> Auf dem anderen System ist man natürlich Root. > > In diesem Fall geht es um Windows, nicht von Linux. Und da gibts in den > ACLs von Files und Directories ein Recht namens "Besitz übernehmen". > Wenn du das bei diesem File nicht hast, dann sollte es nicht möglich > sein, den Besitz zu übernehmen. Jedenfalls nicht via API und ohne Hacks. Wenn also also auf Windows eine Datei von einen nicht mehr vorhanden Nutzer mit entsprechenden Rechten existiert kann root diese Datei also nicht mehr löschen?
Es wird noch etwas komplizierter. Es gibt positive und negative Rechte. Man kann also explizit ein Zugriffsrecht geben, man kann es aber auch explizit nehmen. Letzteres hat Vorrang, worauf Windows auch hinweist, wenn man es nutzt. Dazu kommen die von weiter oben geerbten Rechte. In welcher Kombination von Rechten auch ein Administrator sich definitiv ausschliesst und den Schlüssel versenkt, habe ich auch nicht parat. Aber das Rechtesystem gibt diese Eigenschaft jedenfalls her.
@prx Erstell doch einfach mal eine Datei. Entferne die Übernahme übergeordneter Berechtigungen. Lösche alle Zugriffsberechtigungen inklusive System. Jetzt hat nur noch der Besitzer (Ersteller) die Möglichkeit Berechtigungen zu bearbeiten. Jetzt ändere den Besitzer, oder melde Dich in einem anderen account an. Es gibt keine Berechtigungen für mehr Dich. Jetzt kannst Du, als Administrator, nur noch den Besitz übernehmen und dann wieder Berechtigungen nach deinem Geschmack einrichten. Ein Eintrag in der ACL bezieht sich immer auf eine SID. Stefan
setter schrieb: > Wenn also also auf Windows eine Datei von einen nicht mehr vorhanden > Nutzer mit entsprechenden Rechten existiert kann root diese Datei also > nicht mehr löschen? Files, die sich nicht löschen liessen, hatte ich schon. Aus verschiedenen nicht immer abschliessend bekannten Gründen. In AIX (IBM Unix) hatte ich das aber einmal auch. Da hatte ich mal ein File mit dem Namen "", also dem Leerstring. Frag nicht, wie das zustande kam. Aber die Art, wie Pfade im System verarbeitet werden, führt dazu, dass so ein File im System auf die Directory gemappt wird, in der es sich befindet. Und die ist ja nicht leer, weil ebendieses File drin liegt.
A. K. schrieb: > Es wird noch etwas komplizierter. Es gibt positive und negative Rechte. > Man kann also explizit ein Zugriffsrecht geben, man kann es aber auch > explizit nehmen. Letzteres hat Vorrang, worauf Windows auch hinweist, > wenn man es nutzt. MS hat aber auch schon beim NT4 Server mit seinen noch wirklich überschaubaren ACLs darauf hingewiesen das verweigern die Verarbeitung der ACL langsam macht und man ohne auskommen sollte. Entspricht also in etwa einem goto in C ;) Stefan
A. K. schrieb: > Es wird noch etwas komplizierter. Es gibt positive und negative > Rechte. > Man kann also explizit ein Zugriffsrecht geben, man kann es aber auch > explizit nehmen. Letzteres hat Vorrang, worauf Windows auch hinweist, > wenn man es nutzt. Dazu kommen die von weiter oben geerbten Rechte. In > welcher Kombination von Rechten auch ein Administrator sich definitiv > ausschliesst und den Schlüssel versenkt, habe ich auch nicht parat. Aber > das Rechtesystem gibt diese Eigenschaft jedenfalls her. Komplexität ist der Feind von Sicherheit.
Stefan schrieb: > Jetzt kannst Du, als Administrator, nur > noch den Besitz übernehmen und dann wieder Berechtigungen nach deinem > Geschmack einrichten. Ich habe grad die Rechte eines Files so gesetzt, dass es ihm explizit ausgeschlossen war, den Benutzer zu übernehmen. Und dem Administrator explizit auch in der GPO dieses Recht genommen. Folgerichtig ging da auch nichts. Aber es stimmt, da per GPO der Administrator dieses Recht als Override besitzen kann, sollte es auch möglich sein, auf diese Art Fremddaten zugreifbar zu machen.
setter schrieb: > Komplexität ist der Feind von Sicherheit. Lang lebe MSDOS? ;-) Aber das ist was dran. MSDOS ohne Netzwerk, USB und CDROM ist heute ein verdammt sicheres System. Bootsektorviren von Floppy-Disks sind ziemlich aus der Mode gekommen.
:
Bearbeitet durch User
A. K. schrieb: > Aber es stimmt, da per GPO der Administrator dieses Recht als Override > besitzen kann, sollte es auch möglich sein, auf diese Art Fremddaten > zugreifbar zu machen. Was ist "GPO"?
Group Policy Objects. Da steht ein ziemlicher Rattenschwanz an durch das System vergebenen Einzelrechten drin. Bein Einzelrechnern selten benötigt, ist eher bei Domains relevant. MMC starten, Snap-In hinzufügen, Gruppenrichtlinie. Darin dann Computerkonfiguration, Windows-..., Lokale Richtlinien, Zuweisen, ...
:
Bearbeitet durch User
A. K. schrieb: > Group Policy Objects. Da steht ein ziemlich Rattenschwanz an durch das > System vergebenen Einzelrechten drin. Bein Einzelrechnern selten > benötigt, ist eher bei Domains relevant. Ist das das Zeug was beim Domain-Login in die Registry kopiert wird und mit poledit befummelt wird?
Wahrscheinlich, wobei ich poledit nicht kenne. Gibts auch ohne Domains, wird da aber seltener gebraucht. Gibts auch als gpedit.msc.
setter schrieb: > Ich empfehle jedoch sich mal mit den setuid, setgid und sticky Bits > unter Unix zu beschäftigen, damit lassen sich Standartzugriffs Probleme > recht übersichtlich lösen. Wenn auf ein Verzeichnis mehrere User/Gruppen mit unterschiedlichen Rechten zugreifen sollen, dann geht das nicht ohne ACLs. Ebendies ist eine Standardaufgabe bei Fileservern. > Fein granulare ACLs (egal welches System) neigen dazu völlig auszuarten > und in Folge versteht niemand mehr die Zugriffsrechte. Weshalb fein granulare Rechte in Windows auch erst sichtbar werden, wenn man das explizit will. Normalerweise werden die nicht einzeln verwaltet.
:
Bearbeitet durch User
A. K. schrieb: > Wenn auf ein Verzeichnis mehrere User/Gruppen mit unterschiedlichen > Rechten zugreifen sollen, dann geht das nicht ohne ACLs. Ebendies ist > eine Standardaufgabe bei Fileservern. Wenn man nur einen Hammer hat sieht alles wie ein Nagel aus. RTFM
setter schrieb: > Wenn man nur einen Hammer hat sieht alles wie ein Nagel aus. Dann werd doch mal konkreter. Wie würdest du das lösen? Verweis auf setuid, setgid und sticky ist mir zu wenig. Zumal ich da keinen Zusammenhang erkennen kann. Oder willst du auf die Umkehrung der Hammerregel hinaus? Probleme, die sich nicht mit dem Hammer (klassisches ugo/rwxs) lösen lassen, haben gefälligst nicht zu existieren!
:
Bearbeitet durch User
A. K. schrieb: > setter schrieb: >> Wenn man nur einen Hammer hat sieht alles wie ein Nagel aus. > > Dann werd doch mal konkreter. Wie würdest du das lösen? Verweis auf > setuid, setgid und sticky ist mir zu wenig. Zumal ich da keinen > Zusammenhang erkennen kann. http://de.wikipedia.org/wiki/Setgid#Wirkung_des_gesetzten_Bits_auf_Verzeichnisse
Sorry, aber ich kapier es immer noch nicht. Ich habe ein(!) Verzeichnis und zwei Gruppen. Die eine soll den Inhalt von ebendiesem Verzeichnis lesen können, die andere soll dort auch schreiben können. Der Rest soll nichts können. Da es sich in beiden Fällen um Gruppen handelt, ich aber nur einen Satz an rwx Bits für Gruppen habe, kann ich keine verschiedenen Rechte für Gruppen vergeben. Egal wie das setgid Bit steht. Der verlinkte Text beschreibt gewissermassen den umgekehrten Fall. Einen User, der sich in mehreren Gruppen befindet, und der mit mehreren Gruppenverzeichnissen analoger Rechtestruktur arbeitet.
:
Bearbeitet durch User
A. K. schrieb: > Da es sich in beiden Fällen um Gruppen handelt, ich aber nur einen Satz > an rwx Bits für Gruppen habe, kann ich keine verschiedenen Rechte für > Gruppen vergeben. Egal wie das setgid Bit steht. Naja, dann musst Du dich etwas mehr mit Linux, Kernel und ACL auseinandersetzen. ACL ist nicht das Standard UNIX Permission System. Grüsse, René
Rene H. schrieb: > Naja, dann musst Du dich etwas mehr mit Linux, Kernel und ACL > auseinandersetzen. Dass es mit ACLs geht war von vorneherein klar.
Rene H. schrieb: > Naja, dann musst Du dich etwas mehr mit Linux, Kernel und ACL > auseinandersetzen. Nein. Wenn du wirklich glaubst, dass das von ihm genannte Problem sich mit Standard-Unix-Rechten lösen ließe, darfst du schon erläutern, wie du glaubst, dass es zu erledigen wäre. Genau das war nämlich die Behauptung des Meister "setter". A. K. ist gewiss kein dummer Junge, der noch nie ein Unix in der Hand hatte, und den man erstmal auf die Lehrbücher verweisen sollte.
:
Bearbeitet durch Moderator
Was ist dann unklar? ACL ist Bestandteil des Linux Kernels. Oder willst Du das Problem auf einem 20 Jahren alten NeXT Cube lösen? Grüsse, René
Rene H. schrieb: > Was ist dann unklar? Dass du dich in Dinge reinhängst, um die es nicht geht. Es kam einer daher und hat behauptet, man müsse sich nur mal mit sticky bits und dergleichen auseinander setzen, dann wäre das doch alles machbar (ohne ACLs). Nachdem A. K. ein Szenario schildert, welches damit eben nicht machbar ist, kommst du als Lehrmeister daher, nur um am Ende festzustellen, dass es mit ACLs machbar ist. Das wussten wir aber vorher schon.
Jörg Wunsch schrieb: > Nein. Wenn du wirklich glaubst, dass das von ihm genannte Problem > sich mit Standard-Unix-Rechten lösen ließe, Hat er etwas von Standard-Unix Rechner erwähnt? Das muss ich übersehen haben. Jörg Wunsch schrieb: > A. K. ist gewiss kein dummer Junge, der noch nie ein Unix in der Hand > hatte, und den man erstmal auf die Lehrbücher verweisen sollte. Bin ich auch nicht ;-). Auf Lehrbücher habe ich nicht verwiesen. Das würde ich nie tun! Grüsse, René
Rene H. schrieb: > Was ist dann unklar? ACL ist Bestandteil des Linux Kernels. Oder willst > Du das Problem auf einem 20 Jahren alten NeXT Cube lösen? Du steigst hier mitten in einen Diskussionszweig des Threads ein, dessen Anfang du offenbar nicht mitbekommen hast. Weshalb dir nicht klar ist, um welche Frage es überhaupt geht. Die Frage war nie, ob es mit ACLs ginge. Sondern die Behauptung, dass man Standardprobleme von Fileservices oft auch ohne lösen könne. Und wenn du von dem Thread mehr mitbekommen hättest, als bloss den Schwanz davon, dann wäre dir auch klar geworden, dass mir die Existenz von ACLs bekannt ist.
Ah, ok. Ich habe den Thread nicht durchgelesen. Sondern lediglich die Frage und letzte Antworten. Grüsse, René
A. K. schrieb: > Du steigst hier mitten in einen Diskussionszweig des Threads ein, dessen > Anfang du offenbar nicht mitbekommen hast. Weshalb dir nicht klar ist, > um welche Frage es überhaupt geht. Ja ja, ist ja ok. Ich klink ich mich an der Stelle aus. René
Hai! A. K. schrieb: > Aber es stimmt, da per GPO der Administrator dieses Recht > als Override besitzen kann, sollte es auch möglich sein, > auf diese Art Fremddaten zugreifbar zu machen. Hab' ich das jetzt richtig verstanden: Die Folge aus Deiner Aussage ist, dass man ein geklautes Backup lesbar machen könnte, wenn man es auf eine Windows-System rückspielt, über das man volle Kontrolle hat? Ich muss mal so blöd fragen, weil ich mich mit Windows nicht auskenne, mich aber die Antwort interessiert. Grusz, Rainer
Jörg Wunsch schrieb: > Es kam einer daher und hat behauptet, man müsse sich nur mal mit sticky > bits und dergleichen auseinander setzen, dann wäre das doch alles > machbar (ohne ACLs). Nicht Alles, sondern Vieles.
A. K. schrieb: > Da es sich in beiden Fällen um Gruppen handelt, ich aber nur einen Satz > an rwx Bits für Gruppen habe, kann ich keine verschiedenen Rechte für > Gruppen vergeben. Egal wie das setgid Bit steht. Benutzer können in mehreren Gruppen sein. > Der verlinkte Text beschreibt gewissermassen den umgekehrten Fall. Einen > User, der sich in mehreren Gruppen befindet, und der mit mehreren > Gruppenverzeichnissen analoger Rechtestruktur arbeitet. Der Effekt für den User ist der gleiche. Mit diesen Bits geht noch mehr, die Administration von Desktops ist nicht mein Thema.
Rainer Ziegenbein schrieb: > Hab' ich das jetzt richtig verstanden: Die Folge aus Deiner > Aussage ist, dass man ein geklautes Backup lesbar machen > könnte, wenn man es auf eine Windows-System rückspielt, über > das man volle Kontrolle hat? Solange das Backup nicht verschlüsselt ist, gilt das für jedes OS.
Rainer Ziegenbein schrieb: > Hab' ich das jetzt richtig verstanden: Die Folge aus Deiner > Aussage ist, dass man ein geklautes Backup lesbar machen > könnte, wenn man es auf eine Windows-System rückspielt, über > das man volle Kontrolle hat? Es ging zunächst darum, ob der Admin eines Systems darauf gespeicherte Files lesen kann, auf die er explizit kein Leserecht hat, bzw. das ihm explizit genommen wird. Ein Szenario, das durchaus vorkommen kann. Wenn er an den Backup-Stream rankommt, und der nicht verschlüsselt ist, dann geht das sowieso immer. Muss er halt den Stream entporkeln. Wenn er an die Disk per Linux rankommt, dann auch. Soweit wars klar. Konkret war nun die Frage, ob der Sysadmin die Möglichkeit besitzt, sich die fehlenden Rechte zu holen, auch wenn die Rechte des Files dies explizit ausschliessen. Und mindestens beim Recht, den Besitz zu übernehmen, geht das. Weil es in der GPO eine Einstellung gibt, die bestimmten Account einen Art Override verpasst. Quintessenz: Wer sicher sein will, dass niemand sonst seine Daten liest, ob nun vom Backup oder sonstwie, der verlässt sich nicht auf Rechte, sondern verschlüsselt seine Files auf der Disk. Wenn man das richtig macht, dann kommt der Admin ohne Keylogger oder so wirklich nicht mehr ran.
setter schrieb: > Mit diesen Bits geht noch mehr, die Administration von Desktops ist > nicht mein Thema. Das ist auch kein Desktop-Problem, sondern Problem in Server-Umgebungen. Beispielsweise bei Projektverzeichnissen.
:
Bearbeitet durch User
Rainer Ziegenbein schrieb: > Hab' ich das jetzt richtig verstanden: Die Folge aus Deiner > Aussage ist, dass man ein geklautes Backup lesbar machen > könnte, wenn man es auf eine Windows-System rückspielt, über > das man volle Kontrolle hat? > > Ich muss mal so blöd fragen, weil ich mich mit Windows nicht > auskenne, mich aber die Antwort interessiert. Behauptet habe ich es, er hat's dann gleich mal positiv verifiziert. Und ja es ging schon immmer und wird auch immer gehen! Wer will mich denn daran hindern,im Extremfall, ein nicht verschlüsseltes Dateisystem mit einem modifizierten Treiber auf einem mir genehmen System zu lesen, oder einfach die Dateien sektorweise anhand der MFT zusammenzubauen oder oder oder ... Man braucht auch kein Backup man kann auch einfach eine Platte aus einem RAID 1 ziehen. Wer Backups offen rumliegen oder Server offen rumstehen lässt ist einfach etwas blauäugig! Stefan
A. K. schrieb: > setter schrieb: >> Mit diesen Bits geht noch mehr, die Administration von Desktops ist >> nicht mein Thema. > > Das ist auch kein Desktop-Problem, sondern Problem in Server-Umgebungen. > Beispielsweise bei Projektverzeichnissen. Wenn Desktops per (Netz)Filesystem drauf zugreifen ist das für mich Desktop-Administration.
setter schrieb: > Wenn Desktops per (Netz)Filesystem drauf zugreifen ist das für mich > Desktop-Administration. Sieh an. So gesehen ist ein Server-Admin einer, der Server administiert, auf die nur andere Server zugreifen? ;-)
setter schrieb: > Nicht Alles, sondern Vieles. Aber vieles eben auch nicht. Das sticky bit auf einem Verzeichnis ist eine relativ miserable Krücke, um eins der schlimmsten Szenarien in den Griff zu bekommen, in dem das Unix-Rechte-System einfach unbrauchbar ist (öffentlich lesbare Verzeichnisse, in denen trotzdem nicht jeder den Kram behacken können soll, den jemand anders da angestellt hat). Diese Krücke deshalb als Beinahe-Allheilmittel anzupreisen, ist allerdings schon ziemlich daneben. Klar kann man mit Gruppenrechten teilweise ein ACL-System implementieren, aber das läuft darauf hinaus, dass man für jede neue Menge von Nutzern, die eine separate Berechtigung für irgendwas benötigen, eine neue Gruppe anlegen muss. Das ist machbar, aber alles andere als schön, zumal es (gerade bei älteren Unixen) immer noch hinreichend viele Limitierungen gab/gibt, wie viele Mitglieder eine Gruppe haben darf, wie lang eine Zeile in /etc/group maximal sein darf, und in wie vielen Gruppen ein Benutzer sein kann.
Jörg Wunsch schrieb: > aber das läuft darauf hinaus, dass man für jede neue Menge von Nutzern, > die eine separate Berechtigung für irgendwas benötigen, eine neue Gruppe > anlegen muss. IMHO auch in NTFS Umgebungen der einzige Weg die Übersicht über Rechte zu behalten. Stichwort: Rollenkonzept Einzelne Nutzer in Filesystemen seperat zu berechtigen ist der Weg ins Chaos und damit der Weg ins Gegenteil von Zugriffsschutz. > Das ist machbar, aber alles andere als schön, zumal es > (gerade bei älteren Unixen) Gerade bei älteren DOS und Windows Versionen gab es gar keine Rechte.
setter schrieb: > Rollenkonzept Ein richtiges Rollenkonzept ist auch noch was anderes. Solaris hat sich an sowas mal versucht, aber das betraf dann weniger die Rechte im Dateisystem.
setter (Gast) schrieb:
> Gerade bei älteren DOS und Windows Versionen gab es gar keine Rechte.
Wozu auch? Echte Sicherheit durch Rechtevergabe zu erreichen ist doch
ein frommer Wunschtraum. War doch die Quintessenz der ganzen Diskussion
hier.
Jörg Wunsch schrieb: > setter schrieb: >> Rollenkonzept > > Ein richtiges Rollenkonzept ist auch noch was anderes. Solaris hat > sich an sowas mal versucht, aber das betraf dann weniger die Rechte > im Dateisystem. Deshalb habe ich "Stichwort" davor geschrieben. Und der Zugriff über daemons auf Daten ist schon lange Standart unter Unix. Es gab früher mal "Pitbull" für Solaris, hat Solaris in späteren Versionen was eigenes mitgebracht? Solaris hat aber auch keine ernsthafte Relevanz mehr. Mit SE-Linux kann man Paranoia bis zum Wahnsinn ausleben, für irgentwas müßen die Jungs aus Fort Meade ja gut sein, kosten ja scheiße viel Kohle :-()
Skeptiker schrieb: > Wozu auch? Echte Sicherheit durch Rechtevergabe zu erreichen ist doch > ein frommer Wunschtraum. War doch die Quintessenz der ganzen Diskussion > hier. Es macht schon einen gewissen Unterschied, ob nur der Admin an Zeug rankommt, was ihn nichts angeht. Oder jeder Dödel, der es schafft, seinen PC ins WLAN zu hängen. Auch kommt es vor, dass PCs von mehreren Mitarbeitern oder Familienmitgliedern genutzt werden. Auch da ist nicht immer gewollt, dass jeder die Daten der Anderen studieren kann. Nur weil absolute Sicherheit nicht erreichbar ist, sollte man nicht gleich die absolute Unsicherheit zu erreichen versuchen.
A. K. (prx) schrieb: > Nur weil absolute Sicherheit nicht erreichbar ist, sollte man nicht > gleich die absolute Unsicherheit zu erreichen versuchen. Wenn ich mal Zeit und Lust habe, werde ich mich auf die Suche nach dem Mehr an relativer Sicherheit machen, das der gemeine Computer/Smartphone/Cloud-Nutzer heutzutage haben soll, im Gegensatz zu damals, als die Geräte noch weitgehend unvernetzt, primitiv vernetzt und nicht oder wenig im Fokus der Werbewirtschaft/Regierungsschnüffelbehörden mit Milliardenbudget standen. Am Ende waren die Computer samt Daten des antikapitalistischen Klassenfeindes vom alten Mielke die Sichersten, die jemals gebaut wurden und an denen die NSA sich heute noch aufreiben würde, weil sie die verdammte Cloud einfach nicht finden können und nicht mal Snowden was darüber auf seinen geklauten Festplatten findet.
Offline-System? Kein Problem. Insektendrohne ins Kabel beißen lassen und daten rüberfunken lassen.
Ein Unix-Fileserver hat ein Verzeichnis von root:root mit den Rechten drwx---rwx für NFS-Export freigegeben. Auf einem Unix-Client werden Verzeichnisse für root:grpa und root:grpb mit den Rechten drwxrwx--- angelegt. Darin wird jeweils ein Verzeichnis angelegt und das Verzeichnis vom Fileserver gemountet. Der Systemadministrator möge entscheiden, ob das lustiger als ACLs ist. ;-) Ich habe bisher einen weiten Bogen um ACLs gemacht und trotzdem alle Sicherheitsanforderungen erfüllen können. Da waren aber auch nur eine dreistellige Anzahl User zu verwalten, die sich auf ein gutes Dutzend Anwendergruppen verteilt haben. Jörg Wunsch schrieb: > ..., eine neue Gruppe > anlegen muss. Das ist machbar, aber alles andere als schön, zumal es > (gerade bei älteren Unixen) immer noch hinreichend viele Limitierungen > gab/gibt, wie viele Mitglieder eine Gruppe haben darf, wie lang eine > Zeile in /etc/group maximal sein darf, und in wie vielen Gruppen ein > Benutzer sein kann. Dieses Problem ist bei Verwendung von ACLs mit Gruppen natürlich ebenfalls vorhanden, trägt also nichts zur Lösung oder Verschärfung des Problems bei. Und wegen überfüllter Gruppen ersatzweise mit einzelnen Benutzern und ACLs zu arbeiten macht auch nicht wirklich glücklich.
Jörg Wunsch schrieb: > aber das läuft darauf hinaus, dass man für jede neue Menge von Nutzern, > die eine separate Berechtigung für irgendwas benötigen, eine neue Gruppe > anlegen muss. Das mag ja unbequem sein, wenn es nur einen User in der Gruppe gibt, aber spätestens wenn der eine Urlaubsvertretung braucht, hat sich das mehr als gelohnt. Daher die NTFS-Regel, Rechte grundsätzlich nur an Gruppen zu vergeben. Gruss Reinhard
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.