Hallo Leute,
kürzlich fiel mir auf, dass scripte im aktuellen Verzeichnis auch ohne
angabe des relativ-Pfades ausführbar waren. Das soll so ja nicht sein.
:(
Bei der Überprüfung von $PATH:
fällt dann sofort der einzelne Punkt am Schluss auf.
Nun kann ich aber die Datei nicht finden, welche für diesen Eintrag
verantwortlich ist.
In /etc/profile , in /etc/bash.bashrc und in ~/.bashrc steht´s nicht.
Wenn ich $PATH als "root" lese, dann fehlt der Punkt. Folglich müsste es
irgendwo in der Einstellungen für den normalen Benutzer stehen.
Der Befehl
1
2
grep PATH *
vom Benutzerverzeichnis aus bringt gar nichts
Weiß jemand, wo ich noch suchen könnte?
mfg Giuseppe
mfg
Giuseppe
leider nur meine eigenen versuche aus der .bash_history
in der ~/.profile leider (fast) nur ein verweis auf /etc/profile.
(Editiert)
Dort nichts auffälliges...
Giuseppe B. schrieb:> mitgrep PATH .*>> leider nur meine eigenen versuche aus der .bash_history>> in der ~/.profile leider (fast) nur ein verweis auf /etc/profile.
such mal in ind ganz /etc nach zeugs.
Teilweise komme da Pfade noch aus ganz aderen Dateien
die dann included werden.
hast du den "." nur im X Terminal oder Konsole in deiner GUI ?
Oder auch auf der Standart Konsolen ? (globales init script von anmelde
Manager oder deiner Gnome/kde/fvmw2/...... Datei.
...wenn alles nichts hilft:
find / -type f | xargs grep -lI "PATH"
Das sucht auf der ganzen Platte in allen non-binary files...
Aber ich vermute es eher in etc...
Werden evtl. noch Sachen aus /etc/profile.d/... gezogen?
Grüße
Markus
suse.... lange nicht in der hand gehabt...habe yast und seine 10000
Dateien immer gehasst.
aber das ist dann wohl auch der beste erste Angriffspunkt...
Ich meine mich erinnern zu können das es da ne Option gab den "." in
path zu haben.
Wenn ich mich recht erinnere sollte das dann nur als user der fall sein.
Root hat dann einen anderen Path ohne den Punkt.
Des Rätsels Lösung:
Hier ein Auszug aus der etc/sysconfig/suseconfig:
1
## Type: yesno
2
## Default: yes
3
#
4
# Do you want to have "." in the path for normal users?
5
# Defaults to "yes" since this has been the case for years.
6
#
7
CWD_IN_USER_PATH="yes"
Bin ich total bescheuert, oder wieso bemerke ich das erst vor n paar
Wochen ?
Was machen die da ? Wusste Jemand von euch, daß das seit n paar Jahren
normal sein soll ?
marc schrieb:> Wenn ich mich recht erinnere sollte das dann nur als user der fall sein.> Root hat dann einen anderen Path ohne den Punkt.
Ja, das stimmt. Der root bekommt einen eigenen Eintrag, welcher in der
Erklärung auf "NO" empfohlen wird.
Also gesehen hatte ich schon gelegentlich :. am Ende des PATH (eher im
Unterbewußtsein ;-)
Kann Dir aber jetzt nicht sagen, ob das auf irgendeiner Möhre auf Arbeit
war, oder sonst wo - habe eben nie darauf geachtet ...
Uhu Uhuhu schrieb:> Giuseppe B. schrieb:>> Das soll so ja nicht sein.>> Wieso eigentlich nicht?
Angenommen jemand sendet Dir per Mail ein ausführbares Programm namens
"ls" und du legst das in dein Homeverzeichnis. Irgendwann gibst Du "ls"
ein, hast den Punkt als erstes Element im Pfad und das "falsche" Binary
wird ausgeführt.
Deswegen wird davon abgeraten den Punkt im Pfad zu haben.
Viele Grüße,
Simon
Simon Budig schrieb:> Angenommen jemand sendet Dir per Mail ein ausführbares Programm namens> "ls" und du legst das in dein Homeverzeichnis. Irgendwann gibst Du "ls"> ein, hast den Punkt als erstes Element im Pfad und das "falsche" Binary> wird ausgeführt.
Du musst noch dazu sagen, dass das falsche ls sehr böse sein kann, ein
Virus oder ein Trojaner oder sowas.
Rolf schrieb:> Du musst noch dazu sagen, dass das falsche ls sehr böse sein kann, ein> Virus oder ein Trojaner oder sowas.
Na ja, daß per EMail irgendwas bösartiges ohne Users Zutun direkt in ~
oder seine Unterverzeichnisse kommt, ist doch ziemlich unwahrscheinlich
- deswegen haben die suse-Leute auch diese Option eingebaut.
Uhu Uhuhu schrieb:> Rolf schrieb:>> Du musst noch dazu sagen, dass das falsche ls sehr böse sein kann, ein>> Virus oder ein Trojaner oder sowas.>> Na ja, daß per EMail irgendwas bösartiges ohne Users Zutun direkt in ~> oder seine Unterverzeichnisse kommt, ist doch ziemlich unwahrscheinlich> - deswegen haben die suse-Leute auch diese Option eingebaut.
In einem Mehrbenutzersystem kann man ja auch ein ls in /temp oder
ähnlich legen. Dann noch schön die Funktionalität vom normalen ls
einbauen plus versteckt die böse Funktion. Dann merkt man es erst
später.
Rolf schrieb:> In einem Mehrbenutzersystem
OK, dort macht das Standardverhalten auf jeden Fall Sinn.
Rolf schrieb:> Die Suse-Leute haben von Sicherheit und Vorsicht keine Ahnung.
Und warum haben sie dann eine Option in yast dafür eingebaut?
Uhu Uhuhu schrieb:>> Die Suse-Leute haben von Sicherheit und Vorsicht keine Ahnung.>> Und warum haben sie dann eine Option in yast dafür eingebaut?
Weil es viel Tipparbeit bei der Arbeit erspart. Nehmen wir z.B.
Softwareentwicklung in C unter Linux. Du schreibst den Quelltext,
kompilierst und dann führst Du aus.
In einem sicheren System führst Du aus mit "./ausfuehrdatei", im
unsicheren Suse mit "ausfuehrdatei". Du sparst also im Suse das ./
vorweg. Das alles auf Kosten der Sicherheit.
Früher vor etlichen Jahren war . in $PATH mal üblich und beliebt.
Heutzutage ist das anders aus Sicherheitsgründen. Nur die Suse-Leute
haben das noch nicht mitbekommen wie mir scheint.
Simon Budig schrieb:> Uhu Uhuhu schrieb:>> Giuseppe B. schrieb:>>> Das soll so ja nicht sein.>>>> Wieso eigentlich nicht?>> Angenommen jemand sendet Dir per Mail ein ausführbares Programm namens> "ls" und du legst das in dein Homeverzeichnis. Irgendwann gibst Du "ls"> ein, hast den Punkt als erstes Element im Pfad und das "falsche" Binary> wird ausgeführt.>> Deswegen wird davon abgeraten den Punkt im Pfad zu haben.
Genauso sieht´s nämlich aus...
Rolf schrieb:> Früher vor etlichen Jahren war . in $PATH mal üblich und beliebt.
Heh, ich erinnere mich daran, ja.
Und es war immer eine schlechte Idee ein Testprogramm "test.c" zu
nennen.
Plötzlich funktionieren dann diverse Shellskripte nicht mehr...
Viele Grüße (und frohe Feiertage)
Simon
Giuseppe B. schrieb:> Genauso sieht´s nämlich aus...
Den . hinten anzufügen ist relativ gefahrlos, das Horroscenario mit dem
falschen ls wird damit nicht auftreten, so lange es ein ls in den vor
dem . aufgeführten Pfaden gibt.
Zudem ist dieses "Sicherheitsfeature" inkonsequent: Es gibt keinen
Schutz davor . oder sonst irgendwas an den PATH an- oder einzufügen.
Das Ganze gehört wohl eher in die Kategorie Snakeoil.
Uhu Uhuhu schrieb:> Zudem ist dieses "Sicherheitsfeature" inkonsequent: Es gibt keinen> Schutz davor . oder sonst irgendwas an den PATH an- oder einzufügen.
Naja, es ist ja kein Security-Feature der Shell, sondern es ist eine
etwas sicherere Defaultkonfiguration. Und über das Ausmaß der gewonnenen
Sicherheit lässt sich sicher streiten. Mich hat in der Vergangenheit das
"test"-Problem tatsächlich gebissen :)
Ich habe mich inzwischen an das Tippen von "./" gewöhnt, meine eigenen
Sachen packe ich in $HOME/bin (welches im $PATH ist) und fahre damit
ganz gut.
Viele Grüße,
Simon
Simon Budig schrieb:> Mich hat in der Vergangenheit das> "test"-Problem tatsächlich gebissen
Dann hattest du aber den . vorne im PATH - das ist wirklich keine gute
Idee, das aber nicht unbedingt aus Sicherheitsgründen, sondern weil man
als User von einer bestimmten Hierarchie der Namensräume ausgeht, die
damit gestört wird.
Aber man könnte den Schwachsinn mit dem ./ ja für politisch korrekt
erklären... (auf englischen Tastaturen sind die beiden Zeichen auch
besser zu greifen - da weiß der deutsche Michel dann gleich, daß der
gegen die letzte Welt-Supermacht niemals im Leben einen Stich macht.)
Uhu Uhuhu schrieb:> Dann hattest du aber den . vorne im PATH
Mag sein, ist inzwischen ein paar Jährchen her.
> - das ist wirklich keine gute> Idee, das aber nicht unbedingt aus Sicherheitsgründen, sondern weil man> als User von einer bestimmten Hierarchie der Namensräume ausgeht, die> damit gestört wird.
Sagen wir so: Ich sehe keinen wirklich guten Grund, den "." in $PATH zu
haben. Entweder man braucht ein Programm regelmäßig, dann ist es in
$HOME/bin gut aufgehoben, oder man bastelt gerade daran rum, dann kann
man die explizite Pfadangabe "./" mit angeben (bzw. wieder und wieder
aus der History abrufen). Aber wenn für Dich nützlich ist: Biddeschön.
> Aber [...] Schwachsinn [...] politisch korrekt [...] englischen> Tastaturen [...] deutsche Michel [...] Welt-Supermacht [...] Stich macht.)
Achso, du bist auf einem Kreuzzug :)
Viele Grüße und fröhliche Feiertage,
Simon
Simon Budig schrieb:> Sagen wir so: Ich sehe keinen wirklich guten Grund, den "." in $PATH zu> haben.
Na, wenn Fingergymnastik gut ist, dann darf dort natürlich kein "."
stehen, denn der würde nur dem inneren Schweinehund zuarbeiten und die
Sitten würden im Sauseschritt verlottern.
Jetzt sagen wir´s doch einfach mal so...
Sicherlich haben die Leute von SuSE irgendwas dabei gedacht als Sie den
. in $PATH kurzerhand zum Standard erklärten. Vermutlich wollten Sie
Linux-Anfängern den Wechsel von anderen Systemen wenigstens ein Bisschen
erleichtern indem Sie Ihnen das ... Fingerturnen ... für jeden
einzelnen Script-Start abnehmen. Mag ja ok sein.
Nun hatte sich aber in der Zeit davor bereits der Standard etabliert,
nachdem man eben grundsätzlich KEINEN Punkt im Pfad hat.
Warum ich es erst so spät bemerkt habe ? Ich hatte nicht damit gerechnet
und somit immer schön brav ./ vor die Scripte oder Programme (ausserhalb
der Suchpfade) getippt.
Das Szenario mit dem falschen ls mag ja tatsächlich ziemlich
unwahrscheinlich sein. Daher geht´s einfach um´s Prinzip...
mfg
Giuseppe
p.s. frohe Weihnachten allerseits
Hallo Simon,
Simon Budig schrieb:>> Wieso eigentlich nicht?>> Angenommen jemand sendet Dir per Mail ein ausführbares Programm namens> "ls" und du legst das in dein Homeverzeichnis. Irgendwann gibst Du "ls"> ein, hast den Punkt als erstes Element im Pfad und das "falsche" Binary> wird ausgeführt.
Erstens: niemand, ich wiederhole: absolut niemand kann einem Linux per
E-Mail ein ausführbares Programm senden. Man kann zwar einen Anhang mit
Programmcode versenden, aber auch der wird erst ausführbar, wenn jemand
den Anhang in eine Datei speichert und deren Execute-Bit setzt.
Zweitens steht der Dot nicht als erstes, sondern als letztes Element in
der PATH-Umgebungsvariable. Im lokalen Verzeichnis wird also erst
gesucht, wenn alle anderen Pfade bereits erfolglos durchforstet sind.
Richtig ist daher, daß der Dot nicht als erstes Element in den Suchpfad
gehört. Richtig ist auch, daß er gar nicht in den Pfad von root gehört.
Aber ebenso richtig ist, daß es auf einem Desktopsystem kein besonderes
Sicherheitsproblem darstellt, das aktuelle Verzeichnis als letzte Angabe
in den Pfad zu übernehmen. Alles andere hat weniger mit Sicherheit zu
tun, als mit einer totalen Paranoia.
Freundliche Grüße,
Klaus
Hallo nochmal, Simon,
Simon Budig schrieb:> Rolf schrieb:>> Früher vor etlichen Jahren war . in $PATH mal üblich und beliebt.>> Heh, ich erinnere mich daran, ja.
Nein, eigentlich ist es genau andersherum: früher mal, als Linux auf dem
Desktop eher die Ausnahme und vor allem auf Servern im Einsatz war,
wurde aus Sicherheitsgründen dringend von der Angabe des working
directory in den Suchpfad abgeraten. Das war zum Beispiel bei
fehlerhaften CGIs mit Dateiupload-Funktion nämlich durchaus gefährlich.
Seitdem Linux häufiger auf dem Desktop und vermehrt von unerfahrenen
Usern eingesetzt wird, kann man das aktuelle Verzeichnis bei
Desktop-Systemen durchaus ohne größere Probleme in den Suchpfad
eintragen. Es sei denn, man hat Benutzer auf dem System, die wild auf
alles klicken, das nicht schnell genug auf den Bäumen ist. Aber dann hat
man ohnehin ganz andere Probleme.
> Und es war immer eine schlechte Idee ein Testprogramm "test.c" zu> nennen.>> Plötzlich funktionieren dann diverse Shellskripte nicht mehr...
Nein, das ist überhaupt kein Problem. Wenn man das Testprogramm nämlich
mit "gcc test.c" übersetzt, dann heißt das resultierende Binary "a.out".
Zum Problem wird das nur dann, wenn man das Programm in eine ausführbare
Datei namens "test" übersetzt -- also: "gcc text.c -o test" -- und diese
ausführbare Datei zudem in einem Verzeichnis gespeichert ist, das im
Suchpfad vor dem Systemverzeichnis für das ausführbare Kommando "test"
(/usr/bin) eingetragen ist. Dann, und nur dann, kann es nämlich
passieren, daß ein fehlerhaftes Shellskript das eigene Programm "test"
statt "/usr/bin/test" verwendet und dann -- wenn das eigene Programm
eine andere Funktion hat als "/usr/bin/test" -- nicht mehr funktioniert.
Dann wäre aber das Shellskript fehlerhaft, denn wenn ein Shellskript
"/usr/bin/test" nutzen will, dann soll es das gefälligst mit absoluter
Pfadangabe referenzieren. Aber trotzdem kann das heute in den meisten
Fällen nicht mehr passieren, denn die meisten Linux-Systeme (außer
Ubuntu und ein paar Exoten) verwenden die Bourne Again Shell (bash) oder
Busybox als Shell, und die haben ein eigenes Builtin Command namens
"test", das auch vom [[]]-Shortcut verwendet wird.
Freundliche Grüße,
Klaus
Klaus Maus schrieb:> denn die meisten Linux-Systeme (außer> Ubuntu und ein paar Exoten) verwenden die Bourne Again Shell (bash) oder> Busybox als Shell,
Ubuntu nutzt auch die bash - [[]] funktioniert jedenfalls. Wäre das bei
Ubuntu so, wie bei den "paar Exoten", dann wäre es auch bei Debian so,
denn davon stammt Ubuntu direkt ab und erhält auch von dort die Mehrheit
der Updates.
Ich habe bisher nur beim at-Kommando bemerkt, daß das mit der
Bourne-Shell arbeitet - es warnt bei jedem Aufruf davor.
Diese Szenarien mit ls und test, die mit dem Punkt im PATH plötzlich ein
kriminelles Eigenleben entwickeln sollen, sind einfach nur an den Haaren
herbeigezogener Quatsch, der auf dem falsch plazierten '.' im PATH
zurückzuführen ist. Wie
Giuseppe B. schrieb:> Daher geht´s einfach um´s Prinzip...
und dem ist mit Argumenten nicht beizukommen, sondern höchstens mit
Ironie und Sakasmus.
Nachtrag: Die Idee der SuSE-Leute, den '.' kontrolliert und optional an
die richtige Stelle im PAATH zu plazieren, ist sehr gut, weil so
Erweiterungen des PATH überwacht werden und der '.' immer am Ende
eingefügt wird.
Hallo Uhu,
Uhu Uhuhu schrieb:> Klaus Maus schrieb:>> denn die meisten Linux-Systeme (außer>> Ubuntu und ein paar Exoten) verwenden die Bourne Again Shell (bash) oder>> Busybox als Shell,>> Ubuntu nutzt auch die bash - [[]] funktioniert jedenfalls. Wäre das bei> Ubuntu so, wie bei den "paar Exoten", dann wäre es auch bei Debian so,> denn davon stammt Ubuntu direkt ab und erhält auch von dort die Mehrheit> der Updates.
Im Gegensatz zu Debian verwendet Ubuntu standardmäßig die dash. Da
funktioniert [[]] zwar auch, greift dabei jedoch meines Wissens nicht
auf ein Builtin, sondern auf das externe Programm "test" zurück.
Freundliche Grüße,
Klaus
Und wenn man dann den Leuten den Umstieg von $OTHEROS einfach gemacht
hat, dann fluchen sie nämlich, wenn sie dann mal die
SuSE-Wattebauschumgebung verlassen und auf einem anderen Linux den
ganzen Kram nicht vorfinden. s. auch Aliase wie ll="ls -l" oder ..="cd
.."
Sind die paar Zeichen denn so schwer zu tippen, dass man das jedem von
Anfang an vorsetzen muss? Wenn $POWERUSER das selbst macht, dann ist das
wenigstens ne qualifizierte Entscheidung für die Bequemlichkeit.
Klaus Maus schrieb:> Im Gegensatz zu Debian verwendet Ubuntu standardmäßig die dash.
Wie kann man das herausbekommen?
Malte S. schrieb:> Wenn $POWERUSER das selbst macht, dann ist das> wenigstens ne qualifizierte Entscheidung für die Bequemlichkeit.
Nur daß die Option von SuSE doch etwas mehr ist, als "selbermachen": Es
wird sichergestellt, daß der '.' auch nach den nächsten (automatischen?)
Pfaderweiterung auch noch am Ende steht.
Hallo Uhu,
Uhu Uhuhu schrieb:> Klaus Maus schrieb:>> Im Gegensatz zu Debian verwendet Ubuntu standardmäßig die dash.>> Wie kann man das herausbekommen?
Wenn Du eine Ubuntu-Installation zur Hand hast, kannst Du ja mal
Klaus Maus schrieb:> Wenn Du eine Ubuntu-Installation zur Hand hast, kannst Du ja mal> ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mär 29 2012 /bin/sh -> dash
> echo $0
bash
Interessant. Dort wo sh aufgerufen wird - also z.B. in at - wird die
dash benutzt. In dem bei der Installation angelegten User ist es die
bash.
Wenn man einen neuen User anlegt, dann bekommt der auch automatisch die
bash.
Uhu Uhuhu schrieb:> Nur daß die Option von SuSE doch etwas mehr ist, als "selbermachen": Es> wird sichergestellt, daß der '.' auch nach den nächsten (automatischen?)> Pfaderweiterung auch noch am Ende steht.
Ja schon, so magic ist das jetzt auch nicht, es wird halt in
/etc/profile.d/profile.sh sichergestellt, dass der Punkt bei
eingeschalteter Option ans Ende gestellt wird. Kann man auch in
~/.bashrc sehr einfach machen.
Ich will das Feature auch gar nicht schlechter machen als es ist, es ist
an sich ja eine nette Sache. Aber als Standardeinstellung fällt es für
mich schon klar in die Kategorie der SuSE-Spezialitäten, die einen dann
beißen, wenn man sie - da Standard - ohne nachzudenken als gegeben
ansieht, wenn man es mal mit einer nicht per default so eigenwillig
durchkonfigurierten Distro zu tun hat :)
Hallo Klaus.
Klaus Maus schrieb:> Simon Budig schrieb:>>> Wieso eigentlich nicht?>>>> Angenommen jemand sendet Dir per Mail ein ausführbares Programm namens>> "ls" und du legst das in dein Homeverzeichnis. Irgendwann gibst Du "ls">> ein, hast den Punkt als erstes Element im Pfad und das "falsche" Binary>> wird ausgeführt.>> Erstens: niemand, ich wiederhole: absolut niemand kann einem Linux per> E-Mail ein ausführbares Programm senden. Man kann zwar einen Anhang mit> Programmcode versenden, aber auch der wird erst ausführbar, wenn jemand> den Anhang in eine Datei speichert und deren Execute-Bit setzt.
...oder man es auf einem gemounteten DOS-Filesystem abspeichert, das so
gemounted ist, dass bei allen Dateien automatisch das x-flag gesetzt
wird.
...oder das "bösartige" ls in einem tar-archiv ist und der Nutzer die
Anweisung bekommt, das auszupacken und der sich dann mal mit "ls" den
Inhalt angucken will.
Oder was auch immer. Natürlich sind das konstruierte Beispiele wo auf
mehreren Ebenen etwas schiefgehen muss, damit das Problem zum Tragen
kommt.
Der Punkt (pun intended) ist doch, dass man mit dem Punkt im Pfad ein
Stück weit die Kontrolle darüber aufgibt, wo die ausführbaren Programme
hergenommen werden. Und damit automatisch die Schilde ein Stück weit
senkt. Ob das für einen relevant ist oder nicht, muss man letztlich
selber bewerten. Ich bin der letzte, der hier anderen Leuten den Punkt
im Pfad verbieten will.
> Zweitens steht der Dot nicht als erstes, sondern als letztes Element in> der PATH-Umgebungsvariable.
Du meinst in dem System was Du kennst ist es so. Und Du kennst kein
Gegenbeispiel. Bei mir damals (tm) war es ein AIX, welches man erstmal
mit selbstgestrickten Startup-Skripten in einen benutzbaren Zustand
bringen musste. Und natürlich habe ich mir damals keine Gedanken
darüber gemacht, ob der Punkt vorne oder hinten hingehört.
Solche Policies wie "der Punkt gehört nicht in den Pfad" sind immer für
die Nutzer die keine Ahnung haben. In dem Moment was man weiß was man
tut kann man die gepflegt ignorieren.
> Alles andere hat weniger mit Sicherheit zu tun, als mit einer totalen> Paranoia.
Ach was. Ich habe mir schon so oft selber in den Fuß geschossen, dass
ich solche Guidelines gerne annehme um mich vor mir selbst zu schützen.
Das hat mit Paranoia nix zu tun.
> Nein, das ist überhaupt kein Problem. Wenn man das Testprogramm nämlich> mit "gcc test.c" übersetzt, dann heißt das resultierende Binary "a.out".
Wie gut dass Du besser weißt als ich, wie ich damals den Compiler
aufgerufen habe. Bestimmt habe ich mir das komische Verhalten damals nur
eingebildet... :-)
(Natürlich habe ich es "test" genannt, und natürlich war der "." vor
allem anderen in meinem Pfad. Natürlich bin ich selber schuld.)
> Aber trotzdem kann das heute in den meisten Fällen nicht mehr passieren,> denn die meisten Linux-Systeme (außer Ubuntu und ein paar Exoten)> verwenden die Bourne Again Shell (bash) oder Busybox als Shell, und die> haben ein eigenes Builtin Command namens "test", das auch vom> [[]]-Shortcut verwendet wird.
Klar, und SuSE ist Industriestandard und für alle Linux-Systeme
vorgeschrieben. Wie sollen sich auch Systeme durchsetzen können, wenn
die "." nicht im Pfad haben???!? Und außer Linux gab es eh nie was
anderes.
Im Ernst: Wir diskutieren hier doch über Sinn und Unsinn von "." im
Pfad. Und um zu verstehen, wie eine solche Guideline wie "kein Punkt im
Pfad" entstehen konnte und warum die mindestens mal sinnvoll war macht
es doch keinen Sinn, a) nur Systeme zu betrachten die sich aus deiner
Sicht vernünftig verhalten und b) einen vernünftigen Nutzer
vorauszusetzen.
Wir reden hier von historisch gewachsenen "Regeln". Und die kommen eben
typischerweise mit einem Batzen Geschichte, in diesem Fall tonnenweise
wechselseitig inkompatible Shells, obskure Administrationstools, DAUs
etc. pp. Und auch wenn das Angriffspotential inzwischen vielleicht
wieder geringer ist können sie immer noch durchaus sinnvoll sein,
insbesonders wenn man von Nutzern ausgeht, die keine 100%igen Cracks
sind.
Viele Grüße,
Simon
Hallo Uhu,
Uhu Uhuhu schrieb:> Klaus Maus schrieb:>> Wenn Du eine Ubuntu-Installation zur Hand hast, kannst Du ja mal>> ls -l /bin/sh> lrwxrwxrwx 1 root root 4 Mär 29 2012 /bin/sh -> dash>>> echo $0> bash
Du bist sicher, daß Du da nichts umkonfiguriert hast? Welche Login-Shell
ein User bekommt, steht in /etc/passwd. Der User kann das per chsh(1)
ändern, als Sysop kannst Du das beim useradd(8) mit dem Parameter -s
angeben (oder systemweit per default: siehe unten).
De facto haben dash(1) und bash(1) jedoch eine ähnliche Funktionalität
und so ziemlich dieselbe Syntax, nur daß die bash(1) eben noch einen
Haufen feine Sachen für den interaktiven Modus mitbringt wie Tab
Completion, die Readline-Bibliothek und die Builtin Commands. Das macht
die bash(1) zwar ziemlich fett, was ihren Ressourcenverbrauch angeht,
prädestiniert sie aber andererseits für den interaktiven Modus, in dem
sie deutlich mehr Komfort bietet als die dash(1).
Da man diese interaktiven Funktionen bei der Abarbeitung von Skripten
aber nicht braucht, ist die dash(1) da besser geeignet als die fette
bash(1), weil die dash(1) deutlich kleiner und daher viel
ressourcenschonender ist. Das zeigt sich dann auch im einfachen
Vergleich:
1
kl@us:~$ for i in $(which bash) $(which dash); do du -hs $i; ldd $i | sort; done
Ziemlich eindeutig, oder?
> Interessant. Dort wo sh aufgerufen wird - also z.B. in at - wird die> dash benutzt. In dem bei der Installation angelegten User ist es die> bash.>> Wenn man einen neuen User anlegt, dann bekommt der auch automatisch die> bash.
Das wird in /etc/default/useradd mit der Variablen SHELL festgelegt.
Freundliche Grüße,
Klaus
Klaus Maus schrieb:> Du bist sicher, daß Du da nichts umkonfiguriert hast? Welche Login-Shell> ein User bekommt, steht in /etc/passwd. Der User kann das per chsh(1)> ändern, als Sysop kannst Du das beim useradd(8) mit dem Parameter -s> angeben (oder systemweit per default: siehe unten).
Ja. Ich habe extra in einer VM mit Ubuntu 12.04 einen neuen User
angelegt und mit echo $0 im Terminal bash bekommen. Das System ist
natürlich für meine Vorlieben konfiguriert - Gnome und rails ist drauf -
welche shell man als user bekommt, habe ich jedoch nicht geändert.
> nur daß die bash(1) eben noch einen> Haufen feine Sachen für den interaktiven Modus mitbringt wie Tab> Completion, die Readline-Bibliothek und die Builtin Commands.
Das sind Dinge, die ich schon lange unter Ubuntu nutze, ohne mir groß
Gedanken gemacht zu haben, ob ich dafür eine andere shell brauche.
> Das wird in /etc/default/useradd mit der Variablen SHELL festgelegt.
Merkwürdig: dort ist nur die Zeile
1
SHELL=/bin/sh
nicht auskommentiert. Trotzdem habe ich die bash als loginshell.
Das mit dem Speicherplatz ist ja heutzutage nicht mehr so das Problem.
Hi Simon,
Simon Budig schrieb:> Oder was auch immer. Natürlich sind das konstruierte Beispiele wo auf> mehreren Ebenen etwas schiefgehen muss, damit das Problem zum Tragen> kommt.
Der Punkt (pun stolen) ist justament, daß da auf mehreren Ebenen etwas
schief gehen muß und bei den Sicherheitsproblemen, die dadurch
entstehen, das CWD im PATH noch das mit Abstand kleinste Problem ist.
Wovor soll es schützen, das CWD nicht in den PATH aufzunehmen? Davor,
daß ein Angreifer, der schon a) Code auf unserem System platzieren und
diesen b) ausführbar machen konnte, uns nicht auch noch c) dazu bringen
kann, den Code unter unserer UID auszuführen. In dem Szenario, in dem
uns der Inhalt von PATH uns vor einem Angriff schützt, haben wir also
längst verloren und einen Angreifer nebst seinem Code auf dem System.
Anders gesagt: zu einem Zeitpunkt, in dem uns die Einstellung von PATH
mehr Sicherheit geben kann, ist es längst zu spät und das System bereits
kompromittiert.
Was die Nichtaufnahme des CWD in den PATH nun also bewirkt, ist
allenfalls eine Verbesserung der gefühlten Sicherheit. Das ist aber
noch schlimmer, denn ein User, der sich sicher fühlt, wird im
Zweifelsfalle dazu neigen, höhere Risiken einzugehen. Eine echte
Auswirkung auf das Sicherheitsniveau des Systems hat die Einstellung
aber nicht -- denn sie kann ja wie gezeigt erst greifen, wenn das Kind
bereits im Brunnen liegt.
Statt nun also über solche Kinkerlitzchen zu hyperventilieren, sollte
man sich vielmehr darauf konzentrieren, zu verhindern, daß ein Angreifer
Code auf dem System ablegen und ihn ausführbar machen kann. Denn im
Zweifel legt unser Angreifer seinen Code ohnehin in einem Verzeichnis
ab, das im systemweiten PATH enthalten ist -- oder er kann den
systemweiten PATH so manipulieren, daß das Verzeichnis mit seinem Code
darin enthalten ist.
Freundliche Grüße,
Klaus
Hi Uhu,
Uhu Uhuhu schrieb:> Ja. Ich habe extra in einer VM mit Ubuntu 12.04 einen neuen User> angelegt und mit echo $0 im Terminal bash bekommen.
Ähm, okaaay... /me äußert Befremden.
>> Das wird in /etc/default/useradd mit der Variablen SHELL festgelegt.>> Merkwürdig: dort ist nur die Zeile>
1
> SHELL=/bin/sh
2
>
> nicht auskommentiert. Trotzdem habe ich die bash als loginshell.>> Das mit dem Speicherplatz ist ja heutzutage nicht mehr so das Problem.
Hmmm... legst Du Benutzer mit dem GUI-Tool von Ubuntu an? Unter
(K)Ubuntu trägt useradd(8) nämlich tatsächlich das ein, was in
/etc/default/useradd steht. Wenn das GUI-Tool (das ich nicht benutze,
ich bin ein bekennender Kommandozeilenjunkie) nicht die Einstellung aus
/etc/default verwendet, würde ich das allerdings für einen Bug im
GUI-Tool halten.
Freundliche Grüße,
Klaus
Hallo Uhu,
Uhu Uhuhu schrieb:> Klaus Maus schrieb:>> Hmmm... legst Du Benutzer mit dem GUI-Tool von Ubuntu an?>> Nein, das hatte ich mit adduser im Terminal gemacht.
OK, das zieht seine Config offenbar aus /etc/adduser.conf, und da ist
als DSHELL tatsächlich /bin/bash eingetragen. Weiß der Himmel, warum die
Ubuntu-Leute das so machen...
Freundliche Grüße,
Klaus
@Klaus Maus (Gast)
>kl@us:~$ for i in $(which bash) $(which dash); do du -hs $i; ldd $i | sort; >done>940K /bin/bash> /lib64/ld-linux-x86-64.so.2 (0x00007f6b66267000)> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b65a52000)> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6b65e12000)> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 >(0x00007f6b66016000)> linux-vdso.so.1 => (0x00007fffd244f000)>112K /bin/dash> /lib64/ld-linux-x86-64.so.2 (0x00007f14729dc000)> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f14725f3000)> linux-vdso.so.1 => (0x00007fff885ff000)>>Ziemlich eindeutig, oder?
Nicht wirklich. bash mag zwar mehr Libs anziehen als dash, aber die
zusätzlichen Libs sind wahrscheinlich/möglicherweise bereits von anderen
Prozessen geladen worden. Und wenn schonmal von einem Prozess geladen,
dann wird diese Lib nicht mehr für weitere Prozesse nochmal geladen. Die
ganze Sache relativiert sich also ganz kräftig, und ist für gewöhlich
(zumindest bei den Standard-Libs) bezüglich Ressourcen/Speicher nicht
die Rede wert.
Wenn Du die Bash zweimal startest, belegt der Code ja nicht den
zweifachen Platz im Speicher.
Thread beobachten
Seitenaufteilung abschalten