Announcement: there is an English version of this forum on hallo Unix-Historiker, nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin und /usr/sbin nicht starten (bzw. nur umständlich)? Warum ist erst neuerdings™ /sbin in $PATH enthalten? Und warum bei Debian immer noch nicht? Diverse Befehle wie mount waren schon immer auch für User nützlich. Jetzt will man man /sbin und /bin zusammenlegen, also /sbin abschaffen. Andererseits ist noch in 2019 rdate von /bin nach /sbin gewandert!? https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin https://lists.debian.org/debian-devel/2024/02/msg00298.html Leider hilft das dem PATH nicht, im Gegenteil. Bei Fedora könnte alles in /bin landen, aber bei Debian in /usr/bin und als Sahnehäubchen möchte man einzelne Programme nach /libexec oder /usr/libexec oder sogar /lib verschieben.
:
Gesperrt durch Moderator
Bauform B. schrieb: > nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin > und /usr/sbin nicht starten (bzw. nur umständlich)? Warum ist erst > neuerdings™ /sbin in $PATH enthalten? Und warum bei Debian immer noch > nicht? Weil „Utilities used for system administration (and other root-only commands) are stored in /sbin and /usr/sbin” (FHS). Da man klassischerweise administrative Aufgaben als Root durchführt, ist damit auch nichts verkehrt – nur, wenn man beispielsweise die kaputte sudo-Konfiguration der Buntus nutzt, die sich leider etabliert hat (weil: „Bequemlichkeit first, Sicherheit second“, oder so …), muss man halt dran denken. Bei anderen Distributionen ist /usr/sbin auch heute in der Regel nicht in PATH eines ordinären Users, sondern /sbin und Co. sind Symlinks auf /usr/bin.
:
Bearbeitet durch User
Bauform B. schrieb: > nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin > und /usr/sbin nicht starten (bzw. nur umständlich)? Ich arbeite heute nur auf dem Raspi mit Linux, kenne aber den Urvater Unix noch aus der Zeit, als Linus noch in den Kindergarten ging. Unix war ursprünglich ein reines Server/Client-OS für mehrere Nutzer. Der teure Rechner stand in einem eigenen Raum, da durfte nur ein Admin rein. Die Nutzer saßen irgendwo anders an einfachen Text-Terminals. Da durfte natürlich kein Nutzer alle Systembefehle nutzen, z. B. beliebige Datenträger mounten, Programme oder Updates einspielen oder gar den Rechner herunterfahren. Die Executables für den Admin standen deshalb zur Klarheit separat in /sbin. Ist eine historische Altlast. > warum bei Debian immer noch nicht? Die Debian-Philosophie ist es, möglichst wenig **unnötig** zu ändern. Debian will vermeiden, dass man oft frickeln muss, auch wenn man eigentlich keine neuen Funktionen braucht/will. Man soll UNTER dem OS arbeiten können, ohne AN dem OS frickeln zu müssen. Die Kehrseite ist, dass sich manche Programme nicht installieren lassen, weil sie Libs brauchen, die Debian (noch) nicht kennt. > Diverse Befehle wie mount waren schon immer auch für User nützlich. Unter Client/Server-Unix durfte man natürlich nicht einfach irgendwelche physischen Datenträger mounten: Man war ja nicht alleine am Rechner. Ich erinnere mich am einen Bürorechner von 1980, da musste man sich als root anmelden, nur um eine Diskette mounten zu können. Praktisch musste deshalb jeder das root-Passwort kennen, also hieß es root. :-) War ziemlich umständlich damals, weil ja jeder seine eigene Arbeit auf Disketten haben wollte, damit er sie sicher in den Schrank legen konnte. Heute arbeiten die meisten von uns nicht unter einem Server/Client-System, sondern unter einem Desktop-System, wo sie ihr eigener Admin sind. Dafür ist sudo ganz praktisch, es gab das aber auch schon unter späteren Versionen von Unix. > Jetzt will man man /sbin und /bin zusammenlegen, also /sbin abschaffen. > Andererseits ist noch in 2019 rdate von /bin nach /sbin gewandert!? > Bei Fedora könnte alles in /bin landen, aber bei Debian in /usr/bin und > als Sahnehäubchen möchte man einzelne Programme nach /libexec oder > /usr/libexec oder sogar /lib verschieben. Ja, und wenn man Shell-Scripts hat, laufen die wegen so was dann plötzlich nicht mehr und das Frickeln geht los. Du weißt ja sicher, was die Hardcore-Linuxer dir dann sagen: "Linux hat da keine Schuld, das ist ja nur der Kernel. Und es ist doch supergut, dass sich jeder eine für ihn passende Distri auswählen kann."
:
Bearbeitet durch User
Rolf schrieb: > Die Kehrseite ist, dass sich manche Programme nicht installieren lassen, > weil sie Libs brauchen, die Debian (noch) nicht kennt. Ja. In solchen Fällen habe ich allerdings keine Hemmungen, die fehlenden Pakete von Ubuntu zu "borgen". Das hat bisher immer geklappt. Trotz gelengentlicher Trickserei dieser Art bevorzuge ich Debian wegen seiner genannten Stabilität. Es soll zuverlässig laufen ohne alle paar Wochen mit neuen Änderungen oder neuen Bugs zu überraschen. Wenn ich von einzelnen Programmen eine sehr aktuelle Version haben will, kann ich das ja immer noch separat installieren. Als ehemaliger Windows User bin ich mit der Methode aufgewachsen.
Jack V. schrieb: > Bei anderen Distributionen ist /usr/sbin auch heute in der Regel nicht > in PATH eines ordinären Users, sondern /sbin und Co. sind Symlinks auf > /usr/bin. Dann gibt es ja praktisch kein /sbin mehr, also reicht auch ein PATH="/usr/bin"; in Zukunft sieht es wohl so aus. Rolf schrieb: > Der teure Rechner stand in einem eigenen Raum, da durfte nur ein Admin > rein. Die Nutzer saßen irgendwo anders an einfachen Text-Terminals. Da > durfte natürlich kein Nutzer alle Systembefehle nutzen, z. B. beliebige > Datenträger mounten, Programme oder Updates einspielen oder gar den > Rechner herunterfahren. Die Executables für den Admin standen deshalb > zur Klarheit separat in /sbin. Ist eine historische Altlast. Für die Trennung von /bin und /usr/bin gibt es ja eine vernünftige Erklärung, aber die passt nicht für /bin vs /sbin. Bleibt also nur Tradition, das ist auch ok. Ich kenne auch PATH nur ohne /sbin, erst, als ich jetzt wieder rdate gebraucht hatte, ist es mir aufgefallen. Vor allem, weil das das Gegenteil von unified /bin ist. > Ich erinnere mich am einen Bürorechner von 1980, da musste man sich als > root anmelden, nur um eine Diskette mounten zu können. Praktisch musste > deshalb jeder das root-Passwort kennen, also hieß es root. :-) Ich glaube, mounten ging hier schon mit der mount option "users" und zum Runterfahren gab es den User halt, Passwort halt ;)
Steve van de Grens schrieb: > Wenn ich von einzelnen Programmen eine sehr aktuelle Version haben will, > kann ich das ja immer noch separat installieren. Äh, was genau meinst du mit "separat"?
Rolf schrieb: > Äh, was genau meinst du mit "separat"? Von der Homepage des Autors herunter laden, anstatt es aus der Linux Distribution zu nehmen.
Bauform B. schrieb: > Für die Trennung von /bin und /usr/bin gibt es ja eine vernünftige > Erklärung, aber die passt nicht für /bin vs /sbin. In meinen Augen ist die Trennung zwischen */usr* und */* (Edit: die Textformatierung in diesem Forum könnte ruhig auch mal auf den Stand dieses Jahrtausends gebracht werden, ohne die * werden die Slashes gefressen …) heute eher weniger vernünftig erklärbar, als eine Trennung der Werkzeuge zur Systemadministration und der Anwendersoftware. Ich kenne keinen, der heute /usr heute noch in einem eigenen Dateisystem hat, aber dass ein User mangels Rechten nichts mit beispielsweise adduser anfangen kann, und das daher auch nicht in seinem Suchpfad braucht, ist im Grunde auch heute noch der Fall.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Von der Homepage des Autors herunter laden, anstatt es aus der Linux > Distribution zu nehmen. Und dann? Das Herunterladen ist hier nicht so spannend, sondern das danach, Stichwort "Linux-Dreisatz". Bei Skyrim-Mods ist das ja kein Ding, die haben ihre eigene Logistik. Und ein neueres Programm? Kann man bei Wine auch nehmen, heißt dann aber passend "testing" und kann man über den üblichen Weg installieren.
Jack V. schrieb: > (Edit: die Textformatierung in diesem Forum könnte ruhig auch mal auf den > Stand dieses Jahrtausends gebracht werden, ohne die * werden die Slashes > gefressen …) https://www.mikrocontroller.net/articles/Formatierung_im_Forum
Alexander S. schrieb: > https://www.mikrocontroller.net/articles/Formatierung_im_Forum Ist schon klar. Versuch mal, die obenstehende Darstellung in meinem Beitrag ohne die * zu schreiben – dann verstehst du sicher, was ich meine.
:
Bearbeitet durch User
> nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin > und /usr/sbin nicht starten (bzw. nur umständlich)? Warum ist erst > neuerdings™ /sbin in $PATH enthalten? Und warum bei Debian immer noch > nicht? Weil das ein essentielles Sicherheitsfeature/Zugriffsschutz in Multi-User/Multitask systemen ist. https://de.wikipedia.org/wiki/Mehrbenutzersystem#Rechtemanagement /sbin ist halt das Verzeichniss für systemprogramme wie "su" oder "shutdown" mit denen ein "normaler User. nur Unsinn anstellt.
Klar P. schrieb: > /sbin ist halt das Verzeichniss für systemprogramme wie "su" Nun ja – su in /sbin wäre ziemlich dämlich, oder? Abgesehen davon kann ein User auch unter Debian jederzeit Programme aus /sbin und /usr/sbin zu starten versuchen – er muss halt den Pfad mit angeben. Eine Sicherheitsfunktion war das nie – dazu ist die Rechteverwaltung da. Es war nur geschickt, als Bytes noch was wert waren und Festplattenzugriffe für spürbare Pausen gesorgt haben. Ist heute nicht mehr so wichtig.
Jack V. schrieb: > Klar P. schrieb: >> /sbin ist halt das Verzeichniss für systemprogramme wie "su" > > Nun ja – su in /sbin wäre ziemlich dämlich, oder? Stimmt, oder? Aber es hat doch das SUID-bit gesetzt oder? Und man kann Programme unter Angabe des vollständigen pathes starten /sbin/su sollte doch kein Problen darstellen, wenn man nicht gerade ein Tastaturspastiker ist. https://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap18A-004.htm#:~:text=SUID%20(Set%20User%20ID)%20und,die%20GID%20der%20Besitzergruppe%20erh%C3%A4lt https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#/sbin_%E2%80%93_wichtige_Systembefehle > Eine Sicherheitsfunktion war das nie Also ich kenn da einige Sicherheitsregeln, die explizit angeben, was man nicht in den $PATH packen sollte.
Klar P. schrieb: > Stimmt, oder? Ich wollte darauf hinaus, dass auch unter Debian su unter /usr/bin zu finden ist – schließlich will man, dass der normale User das ohne Hürden nutzen kann. Klar P. schrieb: > Also ich kenn da einige Sicherheitsregeln, die explizit angeben, was man > nicht in den $PATH packen sollte. Du merkst selbst, wie du dir widersprichst, oder? Klar P. schrieb: > Und man kann Programme unter Angabe des vollständigen pathes starten $PATH beinhaltet den Suchpfad. Das ist für die Bequemlichkeit, und hat mit Sicherheit nichts zu tun.
:
Bearbeitet durch User
> Ich wollte darauf hinaus, dass auch unter Debian su unter /usr/bin zu > finden ist – schließlich will man, dass der normale User das ohne > Hürden nutzen kann. manchmal deucht mir man will dem unterprivilegierten user su mit sudo austreiben ... https://www.opensuse-forum.de/thread/40397-su-oder-sudo-und-der-ganze-shell-und-login-wirrwarr/
>> Also ich kenn da einige Sicherheitsregeln, die explizit angeben, was man >> nicht in den $PATH packen sollte. > > Du merkst selbst, wie du dir widersprichst, oder? Da ist kein Widerspruch, du siehst (noch?) nicht klar. > Das ist für die Bequemlichkeit, und hat > mit Sicherheit nichts zu tun. Bequemlichkeit ist der Tod der Sicherheitsregeln. https://tldp.org/HOWTO/Path-12.html
Klar P. schrieb: > manchmal deucht mir man will dem user su mit sudo austreiben Mir deucht, du hast nicht den Schimmer einer Ahnung von Linux in der Praxis – sonst hättest du kurz nachgeschaut, bevor du gepostet hast: Ausgabe von ›which su‹ unter Arch: /usr/bin/su Buster: /usr/bin/su Bookworm: /usr/bin/su RaspberryPi OS: /usr/bin/su grml: /usr/bin/su … mehr hab ich nicht hier. Und nun erzähl’ mir nochmal, dass ›su‹ als Systemprogramm unter /sbin liegen würde.
> … Und nun erzähl’ mir nochmal, dass ›su‹ als > Systemprogramm unter /sbin liegen würde. Nö, warum Rücktritt vom Rücktritt? - gehts dir dann besser ?? Ist Dein Wohlbefinden für irgendjemand hier relevant?
Klar P. schrieb: > Ist Dein Wohlbefinden für irgendjemand hier relevant? Ah, Argumente sind aus – geht auf die persönliche Ebene. So, wie ich dich kenne, bekommst du die Kurve zurück zum Thema eh nicht mehr – viel Spaß also noch o/
Jack V. schrieb: > Klar P. schrieb: >> Ist Dein Wohlbefinden für irgendjemand hier relevant? > > Ah, Argumente sind aus – geht auf die persönliche Ebene. So, wie ich > dich kenne, bekommst du die Kurve zurück zum Thema eh nicht mehr – viel > Spaß also noch o/ Danke, gleichfalls /oo
Klar P. schrieb: > Bequemlichkeit ist der Tod der Sicherheitsregeln Wer glaubt die Sicherheit mit einem Suchpfad zu erhöhen, der befindet sich auf einem Irrpfad. Die Aufteilung der Verzeichnisse geht zurück in eine Zeit, als die Dinger noch auf separaten Platten lagen und entsprechend eingebunden wurden. Damit einhergehend hat man dann auch direkt eine Unterscheidung getroffen, welche Programme (im Allgemeinen) von wem genutzt werden. Beim neuesten Debian wird man zum Beispiel feststellen, das einige Verzeichnisse nunmehr als Symlinks zu anderen Verzeichnissen darstellt werden. Sanfter Übergang, usw.
Norbert schrieb: > Wer glaubt die Sicherheit mit einem Suchpfad zu erhöhen, > der befindet sich auf einem Irrpfad. Wäre das Äquivalent zum DNS-Stoppschild, das gewisse Politisierende damals™ etablieren wollten. Da haben wir auch sehr gelacht. Bzw. hätten, weil’s eigentlich ziemlich traurig war.
Norbert schrieb: > Klar P. schrieb: >> Bequemlichkeit ist der Tod der Sicherheitsregeln > > Wer glaubt die Sicherheit mit einem Suchpfad zu erhöhen, > der befindet sich auf einem Irrpfad. Die Argumentation geht hier eigentlich in die entgegensetzte Richtung, mit einem (dumm/bequem gesetzten) Suchpfad kann man die Sicherheit erniedrigen resp. ein security risk schaffen ...
Klar P. schrieb: > Die Argumentation geht hier eigentlich in die entgegensetzte Richtung, > mit einem (dumm/bequem gesetzten) Suchpfad kann man die Sicherheit > erniedrigen resp. ein security risk schaffen ... Ich sehe keine Argumentation. Ein Programm welches Dinge tun möchte für die der Benutzer sowieso keine Rechte hat, wird ganz simpel rein gar nichts bewerkstelligen. Der Benutzer darf gerne zB. fdisk und Konsorten aufrufen (oder es versuchen), da passiert mal gar nichts.
1 | ~$ /sbin/fdisk -l |
2 | fdisk: cannot open /dev/sdd: Permission denied |
3 | fdisk: cannot open /dev/sda: Permission denied |
4 | fdisk: cannot open /dev/sdc: Permission denied |
5 | fdisk: cannot open /dev/sdb: Permission denied |
Warum sollte das die Sicherheit verringern?
Norbert schrieb: > Klar P. schrieb: >> Die Argumentation geht hier eigentlich in die entgegensetzte Richtung, >> mit einem (dumm/bequem gesetzten) Suchpfad kann man die Sicherheit >> erniedrigen resp. ein security risk schaffen ... > > Ich sehe keine Argumentation. Da ist aber ein link, den man folgen könnte ... > Warum sollte das die Sicherheit verringern? Denk mal vom "user" weg, denk an "root". Und daran, das viele security risks eben deshalb risks sind, weil sich eben der Unterprivilegierte Privilegien verschaffen könnte indem er root etwas "unterschiebt".
Klar P. schrieb: > Da ist aber ein link, den man folgen sollte. Wenn du den tldp meinst, da steht auch nichts, aber auch wirklich gar nichts, was nicht schon seit einem halben Jahrhundert bekannt ist. Und wenn root blöde genug ist auf ungesicherte Verzeichnisse im Suchpfad zuerst zuzugreifen, das sagt mehr über den Menschen als über die Architektur aus.
Norbert schrieb: > Klar P. schrieb: >> Da ist aber ein link, den man folgen sollte. > > Wenn du den tldp meinst, da steht auch nichts, aber auch wirklich gar > nichts, was nicht schon seit einem halben Jahrhundert bekannt ist. Ja eben, "Bequemlichkeit ist der Tod der Sicherheitsregeln", sollte sogar noch länger bekannt sein als 50 Jahre. > Und wenn root blöde genug ist auf ungesicherte Verzeichnisse im Suchpfad > zuerst zuzugreifen, das sagt mehr über den Menschen als über die > Architektur aus. Naja Architekturen kann man anpassen, bei Menschen muss man mit deren Irrungen leben oder eben die Umgebung möglichst foolproof gestalten.
Klar P. schrieb: > Ja eben, "Bequemlichkeit ist der Tod der Sicherheitsregeln", sollte > sogar noch länger bekannt sein als 50 Jahre. Bevor du noch weiter um den heißen Brei herum redest, auf welchem System wird per default so etwas Blödes eingerichtet? Richtig, auf keinem. Also müsste es root nachträglich machen. Und wenn jemand gleichzeitig root und blöd ist (die denkbar ungünstigste Konstellation), dann helfen auf keine Pfadeinschränkungen.
> Bevor du noch weiter um den heißen Brei herum redest, auf welchem System > wird per default so etwas Blödes eingerichtet? > > Richtig, auf keinem. Mutig so eine Aussage über geschätzt eine Billiarde installierte Systeme > Also müsste es root nachträglich machen. > Und wenn jemand gleichzeitig root und blöd ist (die denkbar ungünstigste > Konstellation), dann helfen auf keine Pfadeinschränkungen. Faule Ausrede, Menschen neigen nun mal es sich bequem zu machen. Und seit der Einführung von Suse und breiten Einsatz von Linux in der Ausbildung hat man ohnehin die Kontrolle über die Befähigung der (Hobby-)Administratoren verloren. Aber deshalb gleich alle Sicherheitshinweise und "dos and don'ts" zu ignorieren ist sicher keine gute Idee..
Klar P. schrieb: > Mutig so eine Aussage über geschätzt eine Billiarde installierte Systeme Ernsthaft? Das ist deine Aussage? Ich hatte per default geschrieben. Ohne nachträglichen Idioteneingriff! Aber wenn du das wirklich glaubst, dann nenn' eines. Nee, lass es, ich bin raus hier. Hat keinen Zweck.
> Nee, lass es, ich bin raus hier. Hat keinen Zweck.
Für diese weise Einsicht gibt's, obwohl sie reichlich spät kommt, ein:
'+1'.
Es trollt also absichtlich? Dann ergibt der Verlauf in der Tat Sinn. Schade.
Jack V. schrieb: > auch nichts verkehrt – nur, wenn man beispielsweise die kaputte > sudo-Konfiguration der Buntus nutzt, die sich leider etabliert hat An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher.
Rolf schrieb: > Unix war ursprünglich ein reines Server/Client-OS für mehrere Nutzer. Zudem waren Festplatten eher klein und Sysops hatten schon damals eine Tendenz zur Zentralisierung, und deswegen wurde die /usr-Hierarchie mitunter von einem zentralen NFS-Host gemountet, und die installierte Software wurde dort zentral gepflegt. Trotzdem mußten die Systeme natürlich gewartet, und zudem natürlich /usr gemountet werden können, deswegen lagen bestimmte Binaries für normale Benutzer in /bin und für den Admin zusätzlich weitere in /sbin. Damit ließen sich viele Arbeiten auch im Singleuser-Modus ohne Netzwerk, mithin also ohne gemountetes usr-Verzeichnis erledigen. Bei der Teilung von /bin und /sbin ging es auch um die Autokomplettierung, die verschiedene Shells (die Bash mit der Tab-Taste) anbieten. Früher haben Shells -- Festplatten waren nicht nur klein, sondern auch langsam -- beim Startup die verfügbaren Binaries gelesen und im Speicher gecached. Durch die Trennung von Benutzer- und Admin-Kommandos konnte der Speicher für die Benutzer kleiner und die Startup-Zeit der Shell reduziert werden, denn auch der Arbeitsspeicher und die CPU-Leistung waren damals klein und teuer. Wenn man damals neue Programme in seinem $PATH installiert hatte, mußte man in der Z-Shell das Builtin rehash und in der Bash den Befehl "hash -r" aufrufen. Heute ist das nicht mehr nötig und die Bash liest die Liste der verfügbaren Binaries jedes Mal neu, wenn die Autokomplettierung aufgerufen wird.
Ein T. schrieb: > An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher. Du findest es nicht unsicher, wenn in einer Shell nach einem sudo-Aufruf alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird, ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann? Gerade in Hinsicht auf die Hauptzielgruppe der Buntus, die gerne mal unkritisch irgendwelchen Kram aus PPAs holt, oder ebensogerne mal komplette Eingabezeilen mangels Verständnis ohne weitere Prüfung in die Eingabezeile pastet und ausführt? Ich find’s schon ein bisschen fragwürdig. Versteh’s nicht falsch – ich mag sudo. Bei mir kann damit ein gegebener User einige sehr genau definierte Sachen machen. Das ist, wie’s ursprünglich auch gedacht war, wenn man der Programmbeschreibung glauben möchte. Entsprechend empfinde ich die Konfiguration der Buntus als … fragwürdig.
Rolf schrieb: > Ja, und wenn man Shell-Scripts hat, laufen die wegen so was dann > plötzlich nicht mehr und das Frickeln geht los. Nur wenn man so dämlich war, sein System jenseits aller Standards komplett zu verbasteln, aber ist man ohnehin nicht mehr zu retten. Denn solange */bin* ein Symlink auf */usr/bin*, */lib* einer auf */usr/lib* ist und so weiter, ist es völlig egal, ob Du */bin/ls* oder */usr/bin/ls* aufrufst: es wird automatisch das richtige Executable gestartet. Vielleicht möchtest Du vor dem Verfassen von Beiträgen in diesem Forum etwas mehr über die inhaltliche Qualität Deines Beitrags nachdenken statt darüber, wie Du möglichst oft das Wort "Frickeln" darin unterbringen kannst.
Ein T. schrieb: > beim Startup die verfügbaren Binaries gelesen > und im Speicher gecached. Deren Liste, nicht die Binaries.
rolf schrieb: > Unix war ursprünglich [...]. Die Executables für den Admin > standen deshalb zur Klarheit separat in /sbin. In /etc. Das waren hauptsächlich Sachen zum Booten des Systems (inkl netwerk daemons). Ein ziemliches Chaos von Configfiles und Executables - nix von "Klarheit". /sbin haben ich, iirc, erstmalig bei Linux gesehen. Kann aber sein, dass es das bei BSD schon früher gab. Aus einem alten /etc/default/login:
1 | ... |
2 | PATH=:/usr/local/bin:/bin:/usr/bin:/usr/games |
3 | SUPATH=/etc:/usr/local/bin:/bin:/usr/bin:/usr/games |
4 | ... |
Ein T schrieb: > Früher haben Shells -- Festplatten waren nicht nur klein, > sondern auch langsam -- beim Startup die verfügbaren Binaries gelesen > und im Speicher gecached. Das wäre mir neu. Irgendwelche Linux-Distries hatten sowas mal ausprobiert (beim Booten den Systemcache mit häufig benutzten Dateien seeden). Das Shell hat nur einen Hash <kommandoname> -> <pfad> (see 'help hash').
Angehängte Dateien:
-
scan.jpg
230 KB -
scan0131.jpg
240 KB
>> Früher haben Shells -- Festplatten waren nicht nur klein, >> sondern auch langsam -- beim Startup die verfügbaren Binaries gelesen >> und im Speicher gecached. > Das wäre mir neu. Irgendwelche Linux-Distries hatten sowas mal rehash ist älter als Linux. Linux kam erst mit dem 386 auf, im Ingenieurwesen liefen da bereits seit den Achtzigern Unix-Derivate auf Sun/Sparc-Kisten und ähnlichem. Mit Slackware brach Linux 1993/94 langsam in die Studenten und Script-Kiddies-Szene ein. Viele kopierten sich die per ftp gezogenen (Floppy-)Disc-images mit den mtools auf bspw eine DECstation in der Fakultät für den privaten PC-Gebrauch. Mit den Suse-CD-Images wurde das Ganze dann bequemer. https://de.wikipedia.org/wiki/DECstation https://www.unix.com/man-page/plan9/1/rehash/ https://en.wikipedia.org/wiki/Sun-1 Anbei die Erklärungen aus "Unix Power Tools" aus dem O'Reilly-Verlag dazu
> rehash ist älter als Linux Hab ich was anderes behauptet? Es ging um: > Früher haben Shells [...] beim Startup die verfügbaren Binaries gelesen > und im Speicher gecached. Und das haben sie nie gemacht. Sie haben nur die Pfade von Binaries gecached. Und auch nicht alle beim Startup, sondern einzeln, beim ersten mal benutzen. Die darauf folgende Argumentation ergibt damit keinen Sinn. Das was er beschreibt (cachen von Binaries) haben, wie gesagt, einige Linux-Distris mal ausprobiert (eine Liste von Dateien einmal während des Bootens lesen, damit sie im Cache sind (Ziel war iirc "Booten in <10s"). Filesystem sogar so optimiert, dass diese Dateien alle nah beieinander lagen, damit nicht groß geseekt werden muß.). Hat aber nicht viel gebracht.
(prx) A. K. schrieb: > Ein T. schrieb: >> beim Startup die verfügbaren Binaries gelesen >> und im Speicher gecached. > > Deren Liste, nicht die Binaries. Natürlich. Man hätte zwar aus dem Kontext darauf kommen können, aber das hatte ich ungenau ausgedrückt. Danke für die Verdeutlichung. :-)
Foobar schrieb: > /sbin haben ich, iirc, erstmalig bei Linux gesehen. Hatte Solaris IIRC ab Solaris 7, das muß so etwa 98 oder 99 gewesen sein.
Ich finde das mit /sbin eher nervig. Manchmal verwende ich die Binaries da drin nämlich auch als nicht-root, und dann muss ich den PATH anpassen oder den vollen Pfad angeben... Als Beispiele `/sbin/ifconfig` zeigt auch ohne root die Infos an. Die diversen mkfs.* Programme (z.B. mkfs.ext4), funktionieren auch bei normalen Dateien und Fuse Device Files. Genauso auch fdisk / sfdisk. pivot_root kann man auch zusammen mit unshare / user namespaces verwenden. etc. PS: Mir gefällt der Symlink nonsens aber auch nicht besonders. Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen. Die Symlink betrachte ich als üblen Workaround. Ok, dann hätte man mit `#!/bin/sh` usw. Probleme. Das ist aber auch irgendwie sowieso Mist. Man sollte mal einführen, dass `#!sh` wie `#!/usr/bin/env sh` funktioniert, oder irgend was in die Richtung. Aber irgendwie tun immer alle so, als könne man solche Altlasten nicht mehr ändern.
:
Bearbeitet durch User
Man sollte bedenken dass an Unix und Linux ständig gebastelt wurde. Ein vereinfachtes Bild findet man zum Beispiel in der Wikipedia https://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Unix_history-simple.svg/1280px-Unix_history-simple.svg.png Und jeder hat für sein OS alles ein bisschen anders interpretiert und verschlimmbessert. Daran wird nun seit 55 Jahren gebastelt. Daher gibt es x Geschichten und Interpretationen woher /bin, /sbin, /usr/bin und /usr/sbin kommen. Dazu kommt dass sich keiner, auch bis heute nicht, 100% an die selbst gesetzten Standards hält. Hier ist was ich im Kopf habe, wie es mal war: /bin - Was zum Booten benötigt wird, bzw. wurde bevor /sbin kam. Die Programme müssen auf der Root-Partition liegen. Da zum Booten diverse Systemtools benötigt werden sammelten die sich dort an. Soweit man sie aus /etc rausgeworfen hatte ... Dazu stehen dort auch normale Tools, die eben zum Booten benötigt werden, aber für normale Benutzer interessant oder sogar wichtig sind. Zum Beispiel die Bourne-Shell. /sbin - Kam später hinzu. Als ich mit Unix angefangen habe gab es das noch nicht. Das "s" steht nicht für System, su oder ähnliches, sondern für static. Als dynamisch gelinkte Programme bei Unix aufkamen fand es jemand wichtig die separat zu speichern. Statisch gelinkte Programme sind im Notfall wichtig wenn die dynamischen Libraries nicht ladbar sind, der ldd spinnt usw. Damit landeten in /sbin die Tools die ohne dynamisches Linken funktionieren, auch beim Booten. /bin behielt den Rest. Nicht selten gab es das selbe Programm zwei mal. Statisch gelinkt in /sbin, dynamisch gelinkt in /bin. /usr/bin - Für Benutzer gedachte Programme. Heute würde man sagen Anwendungsprogramme, im Gegensatz zu Systemprogrammen. /usr war früher auch der Start für die Stammverzeichnisse der Benutzer, was heute /home ist. So war es damals ziemlich logisch Anwendungsprogramme in /usr/bin zu speicher. Da es neben Root (Homeverzeichnis früher einfach /, heute /root) auch andere spezielle Systemuser gibt, wie das Druckersystem, landeten solche "Benutzer" auch in und unter /usr. Und die zugehörigen Programme unter /usr/bin /usr lag gerne auf einer separaten Partition oder Platte. Daher konnte man dort keine Programme speichern die beim Booten gebraucht wurden. /usr/sbin kam später hinzu, als die Aufteilung in dynamische und statisch gelinkte Programme kam. /usr/sbin waren die statisch gelinkten Anwendungsprogramme. /usr wurde dann später geteilt. Dateien (Anwendungs-Programme, Libraries, Benutzer, etc.) die mit dem OS kamen blieben unter /usr. Zum Beispiel das Druckersystem. Echte Benutzer-Stammverzeichnisse wanderten nach /home. Externe Programmpakte sollten nach /opt. Allerdings hat sich /opt nicht sehr weit durchgesetzt. Damit hast du auch die Erklärung warum manche Distributionen die sbin Verzeichnisse nicht im normalen Benutzerpfaden haben (wollen). Dort glaubt man zu wissen dass normale Benutzer nie und nimmer statisch gelinkte Programme brauchen. Was Blödsinn ist, wenn es kein dynamisch gelinktes Äquivalent in den bin Verzeichnissen gibt. Abgesehen davon findet man auch schon mal dynamisch gelinkte Programme in sbin. Wenn jemand wieder nicht verstanden hat wofür sbin gedacht ist bzw. war, oder wenn jemand sbin umdefiniert hat zu "für Systemprogramme".
:
Bearbeitet durch User
Daniel A. schrieb: > PS: Mir gefällt der Symlink nonsens aber auch nicht besonders. Statt > /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen. > Ok, dann hätte man mit `#!/bin/sh` usw. Probleme. Das ist aber auch > irgendwie sowieso Mist. Man sollte mal einführen, dass `#!sh` wie > `#!/usr/bin/env sh` funktioniert, oder irgend was in die Richtung. Aber > irgendwie tun immer alle so, als könne man solche Altlasten nicht mehr > ändern. Komisch: jetzt tun die Distributoren etwas an den Altlasten, nämlich genau das, was Du "Symlink nonsens" nennst, achten dabei auf Abwärtskompatibilität, und dann ist es Dir auch wieder nicht Recht.
Hannes schrieb: > /sbin - Kam später hinzu. Das "s" steht nicht für System, su oder > ähnliches, sondern für static. Hast du eine Quelle dafür? Hatte das schonmal irgendwo gelesen - schien mir aber "erfunden" zu sein. An eine Trennung der statischen und dynamischen Programme kann ich mich nicht erinnern (kenn aber auch nicht alle Unixe). Und zumindest bei SCO waren in /dbin keine dynamischen sondern DOS binaries ;-) Der Übergang ging aber eh immer ziemlich fix - wenn man erstmal dyn konnte, hat mach schnell alles umgestellt. /sbin ist aber immer noch da ... Btw, in meinen */sbin gibt's genau ein static: ldconfig[1] - selbst init ist inzw dynamisch. Zumindest für Linux sagt der FHS: "3.16. /sbin : System binaries" https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html Und hab gerade mal nachgeschaut: selbst in einer alten Linuxinstallation von '94 gab's schon /sbin. -- [1] Und das scheint eher ein Versehen (gleiche Compileroptionen wie ld.so und das muss statisch sein).
:
Bearbeitet durch User
https://de.wikipedia.org/wiki/Hashtabelle Es ist vielleicht hilfreich, wenn man Linux und Unix trennt. Man müsste sich wirklich mehr auf Linux konzentrieren, die Linux-Geschichte selber, Linux-Spiele, Linux-Community, Linux-Zukunft, Linux-Kernel oder VMs z.B. Wo möchte man denn mit Linux hin? In eine glückliche Desktop-Zukunft mit happy-legacy Mainframe-Hintergründen von 1970 (oder früher)? Diablo1 und 2 wurde mit Talent, Mut und Hingabe entwickelt, und nicht mit Prinzipienreiterei, Dogmatismus oder gemütlich warmen Scheuklappen. Gab es bei Linux eigentlich auch Crunch-Zeiten? Vielleicht wäre sowas mal gut, um etwas mehr Feinschliff, Ordnung und Kante hineinzubekommen. Oder um es mal mit einem Bibeltext auszudrücken: "Also, weil du lau bist und weder heiß noch kalt, werde ich dich ausspeien aus meinem Munde." (Offenbarung 3,16)
:
Bearbeitet durch User
Jack V. schrieb: > Ein T. schrieb: >> An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher. > > Du findest es nicht unsicher, wenn in einer Shell nach einem sudo-Aufruf > alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird, > ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann? Auch ohne dieses Zeitfenster konnte jeder User einfach so alle Rechte bekommen. Besonders bequem fand ich "sudo su -". Ist das immer noch so? Auch bei der Ubuntu Server Edition? Ubuntu liefert eben Produkte, die für eine bestimmte Anwendung optimiert sind. Deshalb ist das kein Problem. Auf einem privaten Desktop PC ist es total egal, da boote ich notfalls von meinem USB-Stick. Und auf einem Server gibt es gefälligst keine User mit Shell.
Hannes J. schrieb: > /sbin - Kam später hinzu. Als ich mit Unix angefangen habe gab es das > noch nicht. Korrekt. /sbin gab es in den 80ern, als die UNIX-Rechner tatsächlich noch in separaten Server-Räumen stand, wo nur der Admin Zugang hatte, noch gar nicht. Hier gab es lediglich die Unterscheidung /bin und /usr/bin. Unterschied: Unter /bin waren die allernotwendigsten Programme, um ein UNIX im Single-User-Mode zu starten, damit man Wartungsarbeiten durchführen konnte (sh, mount, fsck & Co). Unter UNIX System V (bis SVR3) gab es kein /sbin, da bin ich mir 100%ig sicher. Das /sbin wurde meiner Kenntnis nach das erste Mal unter BSD 2.11 gesichtet. Das war aber erst Anfang der 90er. SVR4 hatte auch einiges aus der BSD-Welt übernommen, soweit ich weiß, auch das /sbin-Verzeichnis. Ob damals die allerersten Linux-Distributionen auch schon ein /sbin enthielten? Da bin ich mir nicht ganz sicher. Siehe auch: https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
:
Bearbeitet durch Moderator
Rbx schrieb: > Oder um es mal mit einem Bibeltext auszudrücken: > "Also, weil du lau bist und weder heiß noch kalt, werde ich dich > ausspeien aus meinem Munde." > (Offenbarung 3,16) Um es mal mit Frank Sinatra zu sagen: To be do be doooo…
Bauform B. schrieb: > Auf einem privaten Desktop PC ist es > total egal, da boote ich notfalls von meinem USB-Stick. Und auf einem > Server gibt es gefälligst keine User mit Shell. Verseuchter Desktop-PC ist total egal? Das Problem mit Malware ist: die macht (erstmal) nicht alles offensichtlich kaputt, sodass man auf die Idee kommt, vom USB-Stick zu booten und das zu fixen. „Gute“ Malware bleibt (erstmal) möglichst unbemerkt und nistet sich ein, und macht vielleicht ’ne Backdoor auf, oder etabliert eine Verbindung zum CC-Server. Oder sie macht schon mal im Hintergrund deine Backups unbrauchbar. Der normale User bekommt das nicht automatisch mit, und die Zielgruppe der Buntus schon gar nicht. Denn normale User sind eher nicht die, denen ’ne 500ms-Verzögerung so komisch vorkommt, dass sie da mal nachschauen … Und das mit dem Server – nun, ich hoffe, dass hier keiner von etwa Uberspace mitliest. Die wissen das nämlich glücklicherweise noch nicht, dass der User keine Shell auf dem Server haben soll ;)
Jack V. schrieb: > Bauform B. schrieb: >> Auf einem privaten Desktop PC ist es >> total egal, da boote ich notfalls von meinem USB-Stick. Und auf einem >> Server gibt es gefälligst keine User mit Shell. > > Verseuchter Desktop-PC ist total egal? Nein. > Das Problem mit Malware ist: die macht (erstmal) nicht alles > offensichtlich kaputt, sodass man auf die Idee kommt, > vom USB-Stick zu booten und das zu fixen. Ein kleines Missverständnis: ich wollte vom USB-Stick booten, um den PC anzugreifen :)
Bauform B. schrieb: > Ein kleines Missverständnis: ich wollte vom USB-Stick booten, um den PC > anzugreifen :) Da bekomme ich allerdings ein Problem, das mit meinem Beitrag, den du gequotet hattest, zusammenzubringen: ein Angriff durch einen physisch anwesenden Angreifer ist nochmal eine ganz andere Situation. Muss dich aber auch da enttäuschen: heutige Distributionen bieten bei der Installation Verschlüsselung an. Einen solchen Rechner kannst du dann gerne mit deinem Stick booten, aber mit dem Angreifen ist’s dann etwas schwierig. Klar, gibt auch da Wege – aber für Privatmenschen mit ihrem Desktop-PC geht bezüglich Kompromittierung durch physisch anwesende Angreifer die größte Gefahr von der Polizei aus (in manchen Bundesländern dürfen sie zur Installation von Überwachungssoftware unbemerkt in die Wohnung eindringen). Und das sollte man schon auch mitbekomment, wenn man nicht zu naiv ist. Bauform B. schrieb: > Besonders bequem fand ich "sudo su -". Ist das immer noch so? Ja. Brauchst aber ein Passwort, wenn du nicht grad im Zeitfenster bist. Das ist entsprechend kein Problem. Ob jemand nun mittelbar über sudo beliebige Sachen als Root ausführt, oder unmittelbar mittels su zu Root wird, ist dann wohl auch egal. Das größte Problem mit der kaputten ›sudo‹-Config sehe ich tatsächlich darin, dass es eben ein Zeitfenster gibt, in dem völlig ohne jede direkte Rückmeldung alles als Root ausgeführt werden kann. Erschwerend kommt hinzu, dass viele User mittlerweile zu glauben scheinen, dass man ›sudo‹ vor alles schreiben müsse, ihnen also die Bedeutung davon nicht einmal mehr bewusst zu sein scheint. Beispiele dafür lassen sich in den einschlägigen Foren leider zuhauf finden.
:
Bearbeitet durch User
Foobar schrieb: > Hannes schrieb: >> /sbin - Kam später hinzu. Das "s" steht nicht für System, su oder >> ähnliches, sondern für static. > > Hast du eine Quelle dafür? Daran kann ich mich auf "richtigen" UNIXen auch noch erinnern, unter Linux hat es das aber -- wenn überhaupt -- schon früh nicht mehr gegeben. Der Filesystem Hierarchy Standard (FHS, FSSTND) in Version 1.0 vom 14.2.1994 [1] sagt: "3.4. /etc : Machine-local system configuration No binaries should go directly into /etc. Binaries that would have, in the past, been found in /etc should now be placed in /sbin. This includes such files as init, getty, and update. Binaries such as hostname that are used by users as well as root should not be placed in /sbin, but in /bin." ".10. /sbin : System binaries (binaries once kept in /etc) Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically contains files essential for the booting phase of starting the system up. Anything executed after /usr is known to be mounted (when there are no problems) should be placed into /usr/sbin. Local-only system administration stuff should now be placed into /usr/local/sbin. [...] Users should have execute permission for everything in /sbin that can be executed by non-root users. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the OS, but to provide a good division between binaries that everyone uses and the ones that are primarily used for administration tasks. There is no inherit security advantage in making /sbin off-limits for users."
Daniel A. schrieb: > Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen. Wirst du alle Programme und Scripte der Welt (oder wenigstens einer Linux Distribution) anpassen, damit sie danach noch funktionieren?
Daniel A. schrieb:
> Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen.
Und wenn wir schon dabei sind, mal endlich das "v" wieder aus der
deutschen Schrift entfernen: follkommen überflüssig, ist entweder ein
"f" (Fielfraß) oder ein "w" (Wentil). Bei Falschbenutzung: Kopf ab.
Unix (nur so grob): /bin /bin/sh /boot /dev /dev /etc (viel Benutzerkontensteuerung) /usr /usr/lib/uucp Linux: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (s.o.) - ist halt die bessere Referenz gerade. Ich hatte auch mal in den Büchern nachgesehen, aber besonders geistreiches oder tiefschürfendes war zu /sbin nicht zu finden. (auch hier nicht: https://askubuntu.com/questions/308045/differences-between-bin-sbin-usr-bin-usr-sbin-usr-local-bin-usr-local) Und von der Logik her kann doch der admin-Quark genauso gut unter /bin/admin laufen. Bei Windows gab es auch mal so eine lächerliche Posse, weil man plötzlich Hexeditoren oder den ProcessExplorer nicht mehr ohne Admin-Passwort einsetzen konnte. Und auf der anderen Seite konnte man mit debug auf der SD-Karte von da aus überall auf C: zugreifen und auch drauf schreiben.. Und bei Linux habe ich auch gelegentlich Fehlermeldungen, die darauf hinweisen, dass Wine oder Steam gelegentlich offenbar den gcc brauchen.. /sbin angeblich immer für "essentielle" "Systemprogramme" was immer sich man dazu vorstellen kann. Ist doch aber auch ein wenig von Betrachter abhängig. Und bei Windows genauso: Wozu soll das gut sein, dass ich auf der Benutzerebene keinen Hexeditor als einfacher Benutzer nutzen kann? Das hat eher was mit Bevormundung zu tun. Und Virenscanner sind ja ganz ähnlich drauf. Und wie man weiter (ganz) oben (Disketten) sieht: Klappt die Bevormundung nicht immer so, wie das in der Realworld-Alltagswelt abläuft. Ist deswegen die Benutzerkontenverwaltung blöd? Finde ich jetzt nicht. Aber man kann auch Ärger mit dem Rechenzentrum bekommen, wenn gewisse Sachverhalte und Regeln nicht transparent sind oder nicht klar auf den Tisch gelegt werden. Man könnte ja soweit gehen, bestimmte Sachen gar nicht anzubieten. ... Naja, und Schulungen gibt es wohl auch kaum noch. Das war früher noch ein wenig anders. So grundsätzlich, und das ist meine Erfahrung mit dem ODP sollten sich Ordnungsstrukturen zwar an Vorgaben halten, aber nicht zwingend vorgeben. Teilweise war es ja manchmal auch nötig, Zwischenordungen herzurichten. Über allem stand A-Z mit als erfolgreichste Ordnung. Zwischenordnung wäre da z.B. A, H, L, Sonstige, weil die meisten Einträge eben nur in A, H und L gingen. Aber da gab es auch schon Rumgeheule. Viele Interessengruppen halt..manchmal gab es Streiterei über eine Kategorie, die es nicht geben soll, manchmal gab es Streiterei oder Geheule, weil man wieder mal von Übereditoren (eher unabsichtig im Zuge gewisse Aufräumarbeiten - kennt man ja hier auch) aus einer bestimmten Ecke gelöscht wurde, oder die eigenen Arbeiten gelöscht wurden ..hach ja und dann sind wir wieder bei https://de.wikipedia.org/wiki/Chaosforschung https://de.wikipedia.org/wiki/Komplexität https://de.wikipedia.org/wiki/Panta_rhei Ist das jetzt nicht offtopic? Nein, gar nicht. Ordnungen sollen helfen, das (Zusammen)Leben zu erleichtern. Was sie aber nicht machen sollten, ist genau umgekehrt, das (Zusammen)Leben zu behindern. Ohne einen gewissen Zwang gibt es aber auch keine Freiheit. Vorgegebene Ordnungen nehmen einem z.B. Entscheidungskosten ab. Bauform B. schrieb: > nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin > und /usr/sbin nicht starten (bzw. nur umständlich)? Soweit ich das richtig verstehe, haben /sbin-Ordner unter /usr überhaupt nichts verloren und /sbin selbst (abgesehen davon, dass das kein Ordner für Userprogramme ist) ist eher so ein Dummy-Ding, das es zwar gibt, aber keiner so richtig weiß, wozu das gut sein soll. Bei Windows sind die ganzen Systemsachen bei Windows/System, schon seit Urzeiten, und da ist bisher auch noch keiner dran gestorben ;)
Bauform B. schrieb: > Besonders bequem fand ich "sudo su -". Hüalp. Das ist krank. Da nimmt man
1 | sudo -i |
.
Jack V. schrieb: > Nicht ›sudo su -c 'sudo su -c "bash"'‹? Noch ein paar Versuche und wir sind bei der guten alten rekursiven Shell-Bombe.
Steve van de Grens schrieb: > Daniel A. schrieb: >> Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen. > > Wirst du alle Programme und Scripte der Welt (oder wenigstens einer > Linux Distribution) anpassen, damit sie danach noch funktionieren? Bei den Skripten mit sed schnell gemacht, bei guten Skripten muss man nur die erste Zeile anpassen. Bei zu Kompilierenden Programmen sollte man sowieso eine Konstante für den Prefix dazutun, was es ja meistens eh schon gibt, oder halt $PATH nutzen. Und wenn der ein oder andere dadurch lernt, nicht einfach ungeprüft Skripte aus dem Internet laufen zu lassen, ist das noch ein Zusatzbonus. Sheeva P. schrieb: > Komisch: jetzt tun die Distributoren etwas an den Altlasten, nämlich > genau das, was Du "Symlink nonsens" nennst Wenn man /bin usw. entfernt, dann gefälligst richtig. Mit einen Symlink ist / immernoch mit dem Eintrag zugemüllt. Ein Symlink ist ein Hack. Eine scheinlösung. Das einzige was man davon hat, ist, das nachher Programme als /bin und anderswo auch noch als /usr/bin hartkodiert werden. Dann kann man gar kein echtes /bin Verzeichnis mehr haben, und alles ist so richtig kaputt.
:
Bearbeitet durch User
Rbx schrieb: > Es ist vielleicht hilfreich, wenn man Linux und Unix trennt. Man müsste > sich wirklich mehr auf Linux konzentrieren, die Linux-Geschichte selber, > Linux-Spiele, Linux-Community, Linux-Zukunft, Linux-Kernel oder VMs z.B. > Wo möchte man denn mit Linux hin? In eine glückliche Desktop-Zukunft mit > happy-legacy Mainframe-Hintergründen von 1970 (oder früher)? Ich habe eine Weile lang darüber nachgedacht, was ich auf so etwas antworten kann. Mir sind kluge, aber leider keine freundlichen Dinge eingefallen. > Diablo1 und 2 wurde mit Talent, Mut und Hingabe entwickelt Stimmt, aber das trifft auch auf Solaris, Free-, Net- und OpenBSD zu. > Gab es bei Linux eigentlich auch Crunch-Zeiten? Vielleicht wäre sowas > mal gut, um etwas mehr Feinschliff, Ordnung und Kante hineinzubekommen. Wie vor einiger Zeit hier jemand geschrieben hat, ist Linux das mit Abstand erfolgreichste Betriebssystem auf der Erde, und meines Wissens auch auf dem Mars. Das wäre nicht so, wenn es zu wenig "Feinschliff, Ordnung und Kante" hätte. Die "Ordnung" und die "Kante" sind übrigens nicht zuletzt Folgen der POSIX-Spezifikation und des Bemühens der Linux-Entwickler, sie einzuhalten. Aber Linux ist, und bleibt hoffentlich, anders als die üblichen Systeme für den Desktop. Linux ist offen, sehr leistungsfähig und extrem flexibel. Aber dafür verzeiht es nichts und nimmt den Benutzer in die volle Verantwortung. Das ist -- die klugen Anwesenden mögen bitte verzeihen, dass mein Vergleich hinkt -- wie der Vergleich zwischen einem Rennauto und einem handelsüblichen Straßenfahrzeug. Mit meinem 2002ti kann ich Donuts auf die Strasse malen, da würden bei meinem Golf sofort alle Lämpchen angehen und mich fragen, ob ich noch alle Latten am Zaun habe. Zurecht, der BMW ist für andere Bedingungen (und Bediener) gemacht als der Golf... Vor einiger Zeit gab es hier einen Thread, da hat jemand gefragt, wie er die Unterstützung von Windows abschalten könne. Dieser Thread hat mir die Augen geöffnet. Während Windows versucht zu reparieren, was es als defekt ansieht, macht ein Linux einfach genau das, was ihm gesagt wird. Und genau das gilt auch für den Desktopbereich. Linux ist wunderbar auf dem Desktop, braucht dazu aber kompetente Benutzer und / oder Admins. Wer seinen Linux-Desktop und das System darunter beherrscht, kann damit nicht nur Spass haben, sondern in vielen Fällen auch extrem effizient damit arbeiten. Er muss es halt können, sonst Enttäuschungen vorhersehbar. > Oder um es mal mit einem Bibeltext auszudrücken: > "Also, weil du lau bist und weder heiß noch kalt, werde ich dich > ausspeien aus meinem Munde." (Offenbarung 3,16) Im Moment ist Linux das heißeste System der Welt und wie gesagt, auch auf dem Mars. Bei allen aktuellen IT-Themen hat Linux die Nase vorn, vom Distributed über das Super- bis hin zum Cloud-Computing, Machine- und Deep Learning, und natürlich bei der Containerisierung und dem Clustering. Auch auf dem Desktop hat es vielfach die Nase vorn. Die "Aktivitäten" meines KDE nutze ich zwar selten. Aber die virtuellen Desktops mit den Aufgaben zu verknüpfen, die ich damit erledigen will, und dabei Dinge zu automatisieren, das ist manchmal eine sehr feine und komfortable Idee. Und apropos virtuelle Desktops: wo hat dieses Microsoft Windows sich die wohl abgeschaut? :) Allerdings werden Deine Anwendungsfälle, Windows-Spiele unter alten Versionen von Linux zu nutzen, für die Linux-Entwicker vermutlich kaum die allerhöchste Priorität geniessen. Das tut mir leid für Dich. Aber können wir uns vielleicht trotzdem darauf einigen, dass das weder Maßstab noch Ziel ist? Merci.
Jack V. schrieb: > Ein T. schrieb: >> An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher. > > Du findest es nicht unsicher, wenn in einer Shell nach einem sudo-Aufruf > alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird, > ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann? Ich kann nicht für den Typ sprechen. Aber nein, das finde ich weder kaputt noch unsicher. Im Gegenteil: wenn ich administrative Arbeiten zu erledigen habe, ist das komfortabel. Was wäre der Angriffsvektor?
Bauform B. schrieb: > Auch ohne dieses Zeitfenster konnte jeder User einfach so alle Rechte > bekommen. Besonders bequem fand ich "sudo su -". Ist das immer noch so? > Auch bei der Ubuntu Server Edition? Ja. Und wenn Du eine passende Datei in /etc/sudoers.d/<username>, oder es in der /etc/sudoers.conf ablegst, dann bekommst Du sogar ohne Passwort und ohne Paßwortabfrage sofort Rootrechte. Oder halt die Rechte, etwas als Root zu tun, das sonst leider nicht ginge. > Ubuntu liefert eben Produkte, die für eine bestimmte Anwendung optimiert > sind. Deshalb ist das kein Problem. Auf einem privaten Desktop PC ist es > total egal, da boote ich notfalls von meinem USB-Stick. Darum geht es gar nicht... wenn Du Benutzer hast, die bestimmte Dinge tun sollen, oder mit mehreren Sysops auf demselben System arbeiten möchtest, kommen mir so ein paar Möglichkeiten in den Sinn. Zum Beispiel SE-Linux, AppArmor, grsecurity oder RSBAC. Will ich das konfigurieren? Im Ernst? Solche Aufwände gönne ich mir nur bei den Systemen, die besonders exponiert sind und / oder besonders sensible Daten halten. Datenbankserver aller Art, wenn sie exponiert werden müssen, oder Firewalls kommen mir da in den Sinn. Die elegantere Alternative ist nun einmal sudo(1). Da kann ich für meine User relativ präzise festlegen, was sie tun dürfen, mit oder ohne Passworteingabe. Credential Caching kann man machen, das ist natürlich konfigurierbar, und auf meinen Desktops und Schleppis nutze ich das auch. Auf die meisten meiner Server kommt ohnehin nur, wer erstens ein passendes Zertifikat fürs VPN und zweitens einen gültigen SSH Private Key hat. Und um sich dann per sudo(1) weitere Privilegien zu verschaffen, bedarf es dennoch noch eines Passworts. Voll unsicher, na klar... :) > Und auf einem Server gibt es gefälligst keine User mit Shell. Na logo. Und wenn, sind die über sudo(1) und / oder eine restricted Shell so weit wie möglich auf das beschränkt, was sie tun dürfen. :)
Jack V. schrieb: > Verseuchter Desktop-PC ist total egal? Ja, total, absolut, und vollkommen egal. Wenn einer meiner Desktops geseucht ist, dann ist das Kind ja bereits in den Brunnen gefallen. Davor schützt uns nichts. Da greift $Kackvogel einfach ab, was er will: Deine SSH-Keys, Deine VPN-Schlüssel, Deine Tastatureingaben und damit Deine Passworte... you get the idea. > oder etabliert eine Verbindung zum CC-Server. Ich glaube nicht, daß Chatcity was damit zu tun hat. :)
Sheeva P. schrieb: > Was wäre der Angriffsvektor? Rhetorische Frage? Hättest du den zitierten Beitrag weitergelesen, hättest du schonmal eine Antwort gefunden (die im Übrigen einen realen Hintergrund hat). Da du offensichtlich nicht einmal das getan hast, gehe ich davon aus, dass du auch nicht an einer weitergehenden Antwort interessiert bist – die Zeit dafür kann ich also sparen. Sheeva P. schrieb: > wenn ich administrative Arbeiten zu > erledigen habe, ist das komfortabel. Und wenn ich administrative Aufgaben zu erledigen habe nutze ich ›su‹ – das ist noch komfortabler und bietet, anders als ›sudo‹ in der kaputten Konfiguration, auch zeitlich und visuell eine scharfe Trennung zwischen Anwender- und Administratoraccount.
Jack V. schrieb: > Sheeva P. schrieb: >> Was wäre der Angriffsvektor? > > Rhetorische Frage? Nein. > Hättest du den zitierten Beitrag weitergelesen, hättest du schonmal eine > Antwort gefunden (die im Übrigen einen realen Hintergrund hat). Tatsächlich habe ich Deinen Beitrag gelesen und sogar verstanden, lieber Kollege. Aber ich frage nach Implikation und Wahrscheinlichkeiten? Oder, anders gefragt: dem realen Hintergrund? > Da du > offensichtlich nicht einmal das getan hast, gehe ich davon aus, dass du > auch nicht an einer weitergehenden Antwort interessiert bist – die Zeit > dafür kann ich also sparen. Sparsamkeit ist zweifellos eine hohe Kunst. :) > Sheeva P. schrieb: >> wenn ich administrative Arbeiten zu >> erledigen habe, ist das komfortabel. > > Und wenn ich administrative Aufgaben zu erledigen habe nutze ich ›su‹ > – das ist noch komfortabler Das halte ich für ein Gerücht, denn... ich habe ja diese Dings... Kollegen. Dieses su(1) ist da leider ein bisschen doof. Dann muss jeder nämlich dasselbe Passwort kennen, nämlich das Root-Passwort. Grandios. AFAIK macht su(1) auch keinen Logeintrag, sudo(1) hingegen schon. Was hat es eigentlich mit dieser "Auditability" auf sich? ISO27k, HIPAA, SOX, ...? > und bietet, anders als ›sudo‹ in der kaputten Konfiguration, auch > zeitlich und visuell eine scharfe Trennung zwischen Anwender- und > Administratoraccount. Möchtest Du mich ärgern?
Klar P. schrieb: > manchmal deucht mir man will dem unterprivilegierten user su mit > sudo austreiben ... Das ist mittlerweile übrigens veraltet. Heute nimmt man run0 von systemd...
Sheeva P. schrieb: > Aber ich frage nach Implikation und Wahrscheinlichkeiten? Oder, > anders gefragt: dem realen Hintergrund? Wie geschrieben: es gab Vorfälle. Sheeva P. schrieb: > Das halte ich für ein Gerücht, denn... ich habe ja diese Dings... > Kollegen. Und das hat mit der zitierten Aussage genau was zu tun? Sheeva P. schrieb: > AFAIK macht su(1) auch keinen Logeintrag, sudo(1) hingegen schon. Was > hat es eigentlich mit dieser "Auditability" auf sich? ISO27k, HIPAA, > SOX, ...? Ich glaube, hier liegt das Missverständnis: du gehst von einer kontrollierten Umgebung mit strengen Regeln im Firmenkontext (oder Schlimmerem) aus, und davon, dass ausschließlich qualifizierte Leute in der sudoers stehen. Alle Anderen in diesem Thread jedoch nicht (wobei ich mir beim Typen nicht vollkommen sicher bin, der mag einen ähnlichen Hintergrund wie du haben). In deiner kleinen Welt mag deine Ansicht vollkommen und richtig sein. In der Welt da draußen ist die Konfiguration schlicht gefährlich. Fun fact am Rande: in der Standard-Buntu-Systemkonfiguration kann jemand, der mittels ›sudo‹ faktisch volle Rootrechte erlangt hat, dann auch problemlos die korrespondierenden Logeinträge manipulieren. Da ist dann ggf. nicht mehr viel mit Nachvollziehbarkeit – im Gegenteil. Sheeva P. schrieb: > Möchtest Du mich ärgern? Möchtest du denn mich ärgern?
:
Bearbeitet durch User
Jack V. schrieb: > Sheeva P. schrieb: >> Aber ich frage nach Implikation und Wahrscheinlichkeiten? Oder, >> anders gefragt: dem realen Hintergrund? > > Wie geschrieben: es gab Vorfälle. Vorfälle. Please elaborate? > Sheeva P. schrieb: >> AFAIK macht su(1) auch keinen Logeintrag, sudo(1) hingegen schon. Was >> hat es eigentlich mit dieser "Auditability" auf sich? ISO27k, HIPAA, >> SOX, ...? > > Ich glaube, hier liegt das Missverständnis: du gehst von einer > kontrollierten Umgebung mit strengen Regeln im Firmenkontext (oder > Schlimmerem) aus, und davon, dass ausschließlich qualifizierte Leute in > der sudoers stehen. Ja, natürlich. Ich entscheide mit meinen Kollegen, was in den sudoers steht. Trotzdem fehlt mir noch eine Idee, wie sich das ausnutzen ließe. Klar habe ich Ideen, aber: die erfordern, dass der Angreifer schon "root" hat, also das Huhn bereits längst im Topf ist. Please elaborate. > In deiner kleinen Welt mag deine Ansicht vollkommen und richtig sein. In > der Welt da draußen ist die Konfiguration schlicht gefährlich. Nein, ist sie nicht.
Sheeva P. schrieb: > Vorfälle. Please elaborate? Nein, not in the public. So groß ist mein Ego dann auch nicht, als dass ich ’nem völlig unbekannten Typen die Sachen in einem öffentlich lesbaren Forum darlegen würde. Sheeva P. schrieb: > Trotzdem fehlt mir noch eine Idee, wie sich das ausnutzen ließe. Und du kommst tatsächlich nicht von alleine darauf? Stell dir einfach vor, dass da normale User am Rechner sitzen. Diese User spielen in dem Szenario eine Rolle, und die kaputte ›sudo‹-Konfiguration hilft dabei sehr. Sheeva P. schrieb: > Nein, ist sie nicht. So naiv war ich nie.
Sheeva P. schrieb: > Wie vor einiger Zeit hier jemand geschrieben hat, ist Linux das mit > Abstand erfolgreichste Betriebssystem auf der Erde, und meines Wissens > auch auf dem Mars. Das ist nun allerdings eine sehr fragwürdige Quelle. Linux ist sicherlich das erfolgreichste Open Source Betriebssystem auf „richtigen“ Computern, und das erfolgreichste im IoT-Bereich. Letzteres, weils kostenlos, leistungsfähig und flexibel ist, in dieser Reihenfolge. Und warum das auch so bleibt, zeigt die Diskussion hier über die wahre Lehre bzgl. sudo. Oliver
Noch ein Argument für die Aufteilung ist auch aus der Mode gekommen: single user mode. Mal eben telinit 1, reparieren, telinit 2 wurde schon aufgegeben, als init noch init hieß. Wann habt ihr das zum letzten Mal benutzt? https://www.linux-magazine.com/Issues/2016/187/Doghouse-Filesystem-Standards Die Geschichte von Linux auf dem Mars ist ja vollkommen irre: "Watching the Mars rover, maddog is delighted to observe that the small helicopter it carries named Ingenuity has many off-the-shelf components and runs under Linux using free and open source software." Soweit so gut; Commercial off-the-shelf components (COTS) sind ja ein Mittelweg zwischen unbezahlbar-Military und Schrott-Commercial. Aber das?! "Many of the other parts for the helicopter were ordered from SparkFun electronics." "It runs an Open-Source Flight Software Framework called "F' (F Prime)" which runs on a Raspberry Pi 3 under Linux." https://www.linux-magazine.com/Issues/2021/246/maddog-s-Doghouse
Bauform B. schrieb: > Linux auf dem Mars Auch hier wird es sicher etliche geben, die ein Bit oder Byte dazu beigetragen haben. Eigentlich trivial, aber im nichttechnischen Freundeskreis ruft es dennoch Erstaunen hervor. https://github.com/users/Ho-Ro/achievements/mars-2020-contributor
Jack V. schrieb: > Hättest du den zitierten Beitrag weitergelesen, hättest du schonmal eine > Antwort gefunden (die im Übrigen einen realen Hintergrund hat). Also ich habe den besagten Beitrag gelesen und halte ihn für Unfug. Daß irgendwelche Spatzenhirne unverstandenes Zeug aus dubiosen Quellen in ihre Shell eingeben, ist kein Argument für irgendwas, außer für die Hirnlosigkeit dieser Spatzenhirne. Ähnliches gilt für Deinen "realen Hintergrund". Zudem bemerkt hat Sheeva ja sehr schön beschrieben, daß Linux kompetente Benutzer voraussetzt, insofern ist es bestenfalls ein Ablenkungsmanöver, hier mit möglichen Fehlern irgendwelcher Spatzenhirne zu argumentieren. Im Übrigen ist der besagte Beitrag aber auch sachlich falsch. Es ist nämlich nicht so, daß "in einer Shell nach einem sudo-Aufruf alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird, ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann", wie Du geschrieben hast. Richtig ist, daß man -- und zwar man selbst, nicht irgendeine magische Engelsgestalt aus einem Wi-wa-wunderland -- immer noch "sudo" davor eingeben muß. > Da du > offensichtlich nicht einmal das getan hast, gehe ich davon aus, dass du > auch nicht an einer weitergehenden Antwort interessiert bist – die Zeit > dafür kann ich also sparen. Wenn sie genauso "klug" ist wie der besagte Beitrag, kannst Du Dir und uns diese Zeit wirklich ersparen. > Und wenn ich administrative Aufgaben zu erledigen habe nutze ich ›su‹ > – das ist noch komfortabler und bietet, anders als ›sudo‹ in der > kaputten Konfiguration, auch zeitlich und visuell eine scharfe Trennung > zwischen Anwender- und Administratoraccount. In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger unsicher als sudo. Zudem sind gesetzte Root-Paßworte anfällig für allerlei Angriffe. Vielleicht hast ja sogar Du schon einmal von Rainbowtabellen, Wörterbuch- und Bruteforce-Angriffen gehört, ja? sudo(1) bietet übrigens dieselbe "scharfe Trennung zwischen Anwender- und Administratoraccount". Man muß es nämlich eingeben, um höhere Privilegien zu erlangen. Es ist nicht so, daß man nach der Benutzung von sudo plötzlich für einen gewissen Zeitraum Administratorrechte als normaler Benutzer hat. Man muß "sudo" hinschreiben. Selbst. Explizit. Ausdrücklich. Und daran ist nichts, aber auch gar nichts unsicher.
Jack V. schrieb: > Sheeva P. schrieb: >> Vorfälle. Please elaborate? > > Nein, not in the public. So groß ist mein Ego dann auch nicht, als dass > ich ’nem völlig unbekannten Typen die Sachen in einem öffentlich > lesbaren Forum darlegen würde. Du argumentierst also mit angeblichen "Vorfällen", kannst und willst sie jedoch auch auf ausdrückliche Nachfrage nicht erläutern. Damit sind Deine angeblichen "Vorfälle" nichts als unbelegte Behauptungen -- und fallen als Argument somit komplett aus.
Ein T. schrieb: > In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet > werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger > unsicher als sudo. Korrektur: ...mit Abstand weniger sicher...
Ein T. schrieb: > In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet > werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger > [sicher] als sudo. In deiner realen Welt reicht unter Buntu ein ›sudo passwd‹, um das Passwort zu setzen. Oder halt ›sudo bash‹, ›sudo su‹ oder auch ›sudo -i‹ – was den Rest deiner „Argumentation“ irgendwie ad absurdum führt. Merkt ihr das denn nicht selbst, wenn ihr mit der angeblichen höheren Sicherheit der kaputten Konfiguration gegenüber einem Rootpasswort argumentiert? Damit, dass Aufrufe via ›sudo‹ ja einwandfrei nachprüfbar geloggt würden? Seht ihr echt nicht, dass es lediglich ein Aufruf von ›sudo‹ in dieser kaputten Konfiguration ist, um das alles auszuhebeln? Dass genau das das Problem dieser Konfiguration ist? Keiner sagt was gegen ›sudo‹ ansich – ich mag das Tool sehr. Aber ihr verteidigt hier ’ne Konfiguration mit Argumenten, die sich angesichts ebendieser Konfiguration in Luft auflösen. Ein T. schrieb: > Man muß "sudo" hinschreiben. Selbst. Explizit. > Ausdrücklich. Und daran ist nichts, aber auch gar nichts unsicher. Ja … weil das natürlich in einem C&P-String nie auftauchen kann, und in Scripten selbstverständlich auch nicht. Is klar … Ein T. schrieb: > Zudem bemerkt hat Sheeva ja sehr schön beschrieben, daß > Linux kompetente Benutzer voraussetzt, insofern ist es bestenfalls ein > Ablenkungsmanöver, hier mit möglichen Fehlern irgendwelcher Spatzenhirne > zu argumentieren. Deiner Ansicht nach richtet sich Buntu mit seiner kaputten Konfiguration also an kompetente Linuxnutzer. Bist du denn auch einer dieser … „kompetenten“ Linuxnutzer, für die Buntu geschaffen wurde? Das würde in der Tat einiges erklären … In meiner Welt, die ich für recht real halte, benötigt ein kompetenter Linuxnutzer die kaputte Konfiguration nicht als Krücke, sondern er richtet sich sein ›sudo‹ direkt passend und sicher ein. Er ist ja schließlich kompetent. OT: kennst du das Geheimnis, das hinter dem „Bearbeiten“-Link unter einem Beitrag steht? Ist spannend: man sieht nicht so dämlich aus, wie wenn man für eine Antwort drei Beiträge schreibt.
:
Bearbeitet durch User
Jack V. schrieb: > Ein T. schrieb: >> In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet >> werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger >> [sicher] als sudo. > > In deiner realen Welt reicht unter Buntu ein ›sudo passwd‹, um das > Passwort zu setzen. Oder halt ›sudo bash‹, ›sudo su‹ oder auch ›sudo -i‹ > – was den Rest deiner „Argumentation“ irgendwie ad absurdum führt. In meiner realen Welt gibt es mehrere Möglichkeiten, ein root-Paßwort zu setzen. Mein Punkt ist: ich will gar kein root-Paßwort setzen. Denn jedes Paßwort, insbesondere eines zu einem bekannten Account, ist potentiell ein Risiko. Das gehe ich nicht ein, wenn ich das nicht muß. Und ich muß es ja nicht, denn ich habe sudo(8). Dadurch hat ein Angreifer überhaupt gar keine Chance, mein root-Paßwort zu knacken. Deswegen gibt es auch keine Notwendigkeit für mich, mir mehrere Paßworte zu merken. Auch das ist eine feine Sache, denn so kann ich mich für das eine Paßwort, das ich brauche und mir merken muß, auf ein besonders starkes und langes Paßwort allem Drum und Dran konzentrieren. Deswegen hat auch das Credential Caching von sudo(8) eine feine Sache, denn dadurch muß ich mein langes Paßwort nicht alle naselang eintippen und komme auch deswegen nicht auf die Idee, ein kurzes, mithin schwaches, dafür aber schnell eintippbares Paßwort zu wählen. Ebensowenig komme ich auf die Idee, ständig als Benutzer root, sondern mit den geringstmöglichen Privilegien zu arbeiten und eine root-Shell nur zu starten, wenn ich sie wirklich brauche. Insofern haben die Standardkonfiguration von sudo(8) und auch die von Ubuntu zwar keine riesigen Vorzüge vor dem, was Du vorschlägst. Im Endeffekt dürfte das Sicherheitssniveau der beiden Lösungen jedoch vergleichbar sein. Ich kenne auch keine Sicherheitsregularien oder -Empfehlungen, die sich gegen sudo(8) aussprechen. Im BSI-Grundschutzhandbuch und den Ausführungen zu PCI-DSS steht IIRC ein bisschen zur Konfiguration von sudo(8), aber keines dieser Werke spricht sich gegen sudo(8) aus oder würde gar empfehlen, das Credential Caching zu deaktivieren. Wozu auch? Nebenbei bemerkt, wenn Du Dein Sicherheitsniveau wirklich nachhaltig erhöhen möchtest, empfehle ich Dir eine Mehrfaktor-Authentifizierung zum Beispiel mit dem Google Authenticator [1] und / oder One Time Passwords. Das kannst Du mit überschaubarem Aufwand über die Pluggable Authentication Modules (PAM) in der Datei /etc/pam.conf oder auf den meisten moderneren Distributionen in dem Verzeichnis /etc/pam.d/ einrichten und hast dann eine Stufe der Sicherheit erreicht, die heute als state of the art gilt. [1] https://de.wikipedia.org/wiki/Google_Authenticator [2] https://www.cl.cam.ac.uk/~mgk25/otpw.html > Merkt ihr das denn nicht selbst, wenn ihr mit der angeblichen höheren > Sicherheit der kaputten Konfiguration gegenüber einem Rootpasswort > argumentiert? Meine Güte, was gibts denn da zu merken? Meine Güte, werd' doch mal konkret. Beschreib doch einfach ein Gefahrenszenario, das dadurch entstehen soll, statt auf den Boden zu stampfen und Fragen wie "merkt ihr's nicht" zu stellen. Nein, ich merke es nicht, was möglicherweise allerdings auch daran liegen könnte, daß Du beharrlich verschweigst, was es denn da zu merken gäbe. > Damit, dass Aufrufe via ›sudo‹ ja einwandfrei nachprüfbar > geloggt würden? Seht ihr echt nicht, dass es lediglich ein Aufruf von > ›sudo‹ in dieser kaputten Konfiguration ist, um das alles auszuhebeln? > Dass genau das das Problem dieser Konfiguration ist? Auch ein weiteres Aufstampfen und Iterieren Deiner unsinnigen Behauptung, daß das "kaputt" sei, ist zwar lustig für mich und unsere Mitleser, aber leider immer noch weit von einem sachlichen Argument entfernt. Behaupten kannst Du viel, argumentativ belegen oder gar überzeugen aber nichts. > Ja … weil das natürlich in einem C&P-String nie auftauchen kann, und in > Scripten selbstverständlich auch nicht. Is klar … Also ist die Standardkonfiguration von sudo(8) doof, weil Vollhonks Sachen in ihrer Shell ausführen, die sie nicht verstanden haben? Meine Güte, was für eine unfaßbar riesige Sicherheitslücke, da hat su(1) ja echt den total tollen Vorteil, daß die Vollhonks HAARGENAU EXAKT DASSELBE UNVERSTANDENE ZEUGS DANN DIREKT IN IHRE GOTTVERDAMMTE ROOT-SHEL EINTIPPEN! Verstehst Du das? Die wollen einfach nur ein vorhandenes oder eingebildetes Problem lösen, und sie sind so dermaßen erpicht darauf, daß sie alle nötige und sinnvolle Vorsicht über Bord werfen! Und daran ändern Du und ich nichts, weder mit einer anderen Software wie su(1), noch mit einer anderen Konfiguration von sudo(8). In der IT gibt es deswegen nicht von ungefähr den bekannten Spruch "immer, wenn Du etwas idiotensicher gemacht hast, kommt die Natur und erfindet größere Idioten". Ich weiß auch nicht, was für ein merkwürdiges Verständnis von Sicherheit zu einer solchen Argumentation kommt und wie weit sie dann geht. Womöglich wäre es das Sicherste (tm), wenn Privilegienerhöhung gar nicht möglich wäre. Das wäre jedenfalls die logische Konsequenz. > Ein T. schrieb: >> Zudem bemerkt hat Sheeva ja sehr schön beschrieben, daß >> Linux kompetente Benutzer voraussetzt, > > Deiner Ansicht nach richtet sich Buntu [...] also an kompetente Linuxnutzer. Du mußt wirklich aufmerksamer lesen, Jack. Ich schrieb "Linux", weil ich alle Linuxe gemeint habe, und zwar, ja, auch die Ubuntus. Die machen die Sache ein bisschen einfacher, aber auch sie setzen mündige, kompetente Nutzer voraus. > Bist du denn auch einer dieser … > „kompetenten“ Linuxnutzer, für die Buntu geschaffen wurde? Das würde in > der Tat einiges erklären … > > OT: kennst du das Geheimnis, das hinter dem „Bearbeiten“-Link unter > einem Beitrag steht? Ist spannend: man sieht nicht so dämlich aus, wie > wenn man für eine Antwort drei Beiträge schreibt. Aha, dann sind wir also jetzt schon auf der Ebene persönlicher Angriffe und Provokationen angekommen. Daß Du das nötig zu haben scheinst, erhärtet meinen Verdacht, daß Du entweder keine sachlichen Argumente hast oder es warum auch immer nicht schaffst, sie zu formulieren und vorzubringen. Schau, wenn Du keine Argumente hast, dann halt Dich doch einfach mit Deinem FUD bezüglich einer angeblich unsicheren Konfiguration zurück und erspar uns und den Anwesenden solche unsinnigen Diskussionen. > In meiner Welt, die ich für recht real halte, benötigt ein kompetenter > Linuxnutzer die kaputte Konfiguration nicht als Krücke, sondern er > richtet sich sein ›sudo‹ direkt passend und sicher ein. Er ist ja > schließlich kompetent. Das stimmt, und deswegen ändere ich auch etwas an meiner sudo-Konfiguration: ich trage meinen Benutzer mit visudo(8) in die sudoers(5) ein, denn mitunter bearbeite ich die Gruppenzugehörigkeiten meines Benutzers und möchte dadurch verhindern, mich selbst auszuschließen, wenn meine Software oder ich dabei möglicherweise die Gruppen "sudo" und "admin" vergessen sollten. Am Credential Caching dagegen ändere ich ganz bewußt nichts, weil ich das (siehe oben) für ein sehr sinnvolles Feature halte und deswegen keinen Grund dafür sehe, dessen Standardkonfiguration zu ändern. Das ist gleichermaßen sicher wie in mehrerlei Hinsicht komfortabel. Und ja, eine moderne Sicht auf das Thema Sicherheit berücksichtigt auch den Komfort für die Nutzer. Denn deren Arbeit mit Verweis auf die Sicherheit zu erschweren, senkt deren Akzeptanz von Sicherheitsmaßnahmen und fördert ihre Bereitschaft, die Sicherheitsmaßnahmen kreativ zu umgehen, was am Ende viel schlimmere Auswirkungen auf das Sicherheitsniveau (siehe dazu auch oben bei "Paßwortlänge") haben kann als alles, was zuvor verhindert werden sollte.
Beitrag #7658911 wurde von einem Moderator gelöscht.
Beitrag #7658918 wurde von einem Moderator gelöscht.
Beitrag #7658946 wurde von einem Moderator gelöscht.
Beitrag #7658959 wurde von einem Moderator gelöscht.
Beitrag #7658965 wurde von einem Moderator gelöscht.
Beitrag #7658966 wurde von einem Moderator gelöscht.
Beitrag #7658998 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten