USB-Devices abschalten

[phill971]

Hallo zusammen,

ich baue gerade ein Livesystem mit dem Debian Live Builder. Dieses soll automatisiert eine Hardwarediagnose durchführen. Nun stehe ich allerdings vor dem Problem, dass niemand den Rechner in der Zeit bedienen soll. Ich kopiere dafür /bin/false nach /bin/login, damit springt er bei jedem Anmeldeversuch immer wieder zurück auf das ursprüngliche Login-Fenster.

Nun habe ich mir gedacht, um das wilde Probieren von Fremden an dem Rechner zu unterbinden, könnte ich die USB-Schnittstellen für Maus und Tastatur abschalten. (es handelt sich um öffentlich zugängliche PCs) Habt ihr eine Idee, wie ich das effektiv lösen kann? Das ganze soll in einem Bashskript vollautomatisch ablaufen.

Edit: Weiterhin wäre es super, wenn ich den Anmeldeprompt auf dem Loginscreen wegbekommen würde. Jemand da eine Idee?

Besten Dank und viele Grüße
Phill

[NAB]

USB-Treiber nicht laden?

[phill971]

USB-Treiber nicht laden?

Ich habe versucht über rmmod sämtliche Module, die (scheinbar) mit USB zu tun haben zu entfernen, das hat mich allerdings nicht zu dem gewünschten Erfolg geführt.

[NAB]

Code: Alles auswählen

echo "Windows is installing Updates. Do not power down!" > /dev/tty*

?

[phill971]

Code: Alles auswählen

echo "Windows is installing Updates. Do not power down!" > /dev/tty*

?

Dann saagt er mir

Code: Alles auswählen

/dev/tty* ambiguous redirect

Gebe ich z.B. tty0 an, so gibt er einfach den Text aus.

[smutbert]

Kinderspiel:

Unter »/sys/bus/usb/drivers/usbhid« gibt es symbolische Links zu den (USB-)Geräten, die Eingabegeräte sind, also genauer zu den jeweiligen sysfs-Verzeichnissen, bei mir zB

Code: Alles auswählen

$ ls -l /sys/bus/usb/drivers/usbhid
total 0
lrwxrwxrwx 1 root root    0 Apr 25 16:21 3-6:1.0 -> ../../../../devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0
lrwxrwxrwx 1 root root    0 Apr 25 16:18 3-8:1.0 -> ../../../../devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8:1.0
lrwxrwxrwx 1 root root    0 Apr 25 16:18 3-8:1.1 -> ../../../../devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8:1.1
--w------- 1 root root 4096 Apr 25 16:20 bind
lrwxrwxrwx 1 root root    0 Apr 25 16:18 module -> ../../../../module/usbhid
-rw-r--r-- 1 root root 4096 Apr 25 16:18 new_id
-rw-r--r-- 1 root root 4096 Apr 25 16:18 remove_id
--w------- 1 root root 4096 Apr 25 16:18 uevent
--w------- 1 root root 4096 Apr 25 16:20 unbind

Das wären hier also die ersten drei Dateien/Links

• 3-6:1.0
• 3-8:1.0
• 3-8:1.1

Es ist etwas lästig herauszufinden welches Gerät was ist, aber wenn du eh alle (de)aktivieren willst, ist das uninteressant. Denn du musst nur diese IDs in die Datei unbind schreiben und schwupps fühlt sich der Treiber für USB-Eingabegeräte »usbhid« nicht mehr für diese Geräte zuständig. Aktivieren kann man sie wieder indem man dieselben IDs in die Datei bind schreibt.
Meine Maus kann ich also mit

Code: Alles auswählen

# echo 3-6:1.0 > /sys/bus/usb/drivers/usbhid/unbind

deaktivieren und mit

Code: Alles auswählen

# echo 3-6:1.0 > /sys/bus/usb/drivers/usbhid/bind

wieder aktivieren. Allerdings wird zu keinem Punkt irgendein Gerät oder Bus oder Anschluss wirklich abgeschaltet.

[NAB]

smutbert, wenn du deine Maus raus- und wieder reinsteckst, müsste sie aber wieder funktionieren.

phill971, richtig ... wenn du es auf allen Terminals haben willst, muss da noch ein "tee" rein.

Gib die Zeile im Sekundentakt aus ... ich wette, da loggt sich niemand mehr ein.

Sonst schau dir /etc/default/console-setup an oder guck dich in /etc/systemd/* um.

[smutbert]

stimmt, wenn das auch nicht gehen soll könnte man ja eine udev-Regel schreiben. Ich würde mir da etwas wie

Code: Alles auswählen

SUBSYSTEM=="usb", DRIVER="usbhid", RUN="/bin/sh -c 'test -f /var/run/etwas_ist_im_Gange && echo -n $kernel > /sys/bus/usb/drivers/usbhid/unbind'"

vorstellen. Dann müsste man nur eine Datei »/var/run/etwas_ist_im_Gange« anlegen damit Ab- und wieder Anstecken der Eingabegeräte nichts hilft.

(Habs aber nicht getestet)

[pferdefreund]

Man könnte auch die entsprechenden USB-Treiber mal per lsmod ermitteln und - wenn der Rechner nicht befingert werden soll,
diese per rmmod entladen, aus /lib/modules... wegmoven und danach wieder
zurückmoven und wieder laden. Hat den Vorteil - was der Kernel nicht findet, kann er - auch über udev, müller meier oder was auch immer - eben nicht laden. Wo nix ist, hat der Kaiser sein Recht verloren - galt schon im Mittelalter.

[smutbert]

Ja, das geht auch. Ein einfaches »rmmod usbhid« genügt (zusätzlich zur Umbennungs- oder Verschiebeaktion, damit niemand das Modul mehr laden kann).

[phill971]

Vielen vielen Dank schonmal für alle eure Antworten!

Das rausnehmen des USB-Moduls funktioniert soweit, danach ist keine Tastatureingabe mehr möglich.

Nochmal zurück zur Anmeldeprompt...

@NAB, wo genau muss das tee hin? Passieren tut da allerdings nicht viel.. Nämlich gar nichts. Ich bin leider noch ziemlicher Anfänger was das ganze angeht, deshalb stehe ich da auch gerne mal auf dem Schlauch.
Kann ich, wenn ich diese Umlenkung von Echo auf /dev/tty* machen möchte, das ganze einfach in eine Whileschleife machen? Nach dem Motto "solange i kleiner 1 mache echo usw..", i stelle ich in dem Fall auf 0 ohne es zu verändern. Dann sollte das ganze ja ins endlose laufen?

[NAB]

Code: Alles auswählen

while [ 1 ]; do echo "ERROR: PHIL971 Infection" | tee /dev/tty*; sleep 1; done

Bei [ 1 -eq 1 ] kommt halt 1 raus

[phill971]

Code: Alles auswählen

while [ 1 ]; do echo "ERROR: PHIL971 Infection" | tee /dev/tty*; sleep 1; done

Bei [ 1 -eq 1 ] kommt halt 1 raus

Ok, die Meldung wird ausgegeben. Zusätzlich kommt

Code: Alles auswählen

tee: /dev/ttyS0: Input/output error
tee: /dev/ttyS1: Input/output error
tee: /dev/ttyS2: Input/output error
tee: /dev/ttyS3: Input/output error

Kurze weitere Frage, ich habe leider gerade keinen Rechner mit PS2 Tastatur zur Hand, welches Kernel Modul muss rausgeworfen werden, um den gleichen Effekt wie bei der USB-Tastatur zu erzielen? Google führt mich da gerne zu Themen zur Playstation 2

[smutbert]

Die Unterstützung für PS/2-Tastaturen ist direkt in den Kernel kompiliert - da gibt es kein Modul, das man entladen könnte und ich glaube daran kann man nicht einmal etwas ändern indem man sich seinen eigenen Kernel kompiliert.

[NAB]

Was passiert eigentlich, wenn man
killall getty
macht?

[smutbert]

Wie wäre es mit

Code: Alles auswählen

# systemctl stop getty@tty1.service

nur die weiteren gettys startet systemd erst dynamisch. dh erst wenn jemand auf VT Nummer 2 (Strg+Alt+F2) wechselt wird getty@tty2.service erzeugt (?) und gestartet. Danach kann man es zwar genauso beenden, aber es wird automatisch wieder gestartet, wenn man erneut auf dieses VT wechselt.

Gegen die VT > 1 könnte man aber in der »/etc/systemd/logind.conf« den Wert von NAutoVTs auf 0 setzten, dann sollte es imho nur das erste VT mit einem Textlogin geben, das man mit obigen Befehl leicht deaktivieren und mit

Code: Alles auswählen

# systemctl start getty@tty1.service

wieder aktivieren kann.
Das ist natürlich keine Lösung, wenn mehrere VTs benötigt werden.

[NAB]

nur die weiteren gettys startet systemd erst dynamisch.

Genau das habe ich befürchtet. Mit SysVInit ist das anders.

Soweit ich phill971 verstanden habe, braucht er gar keinen VT. Darum lenke ich die Aufmerksamkeit ja die ganze Zeit auf die VTs

[phill971]

Genau, ich brauche wirklich GAR KEINE Möglichkeit mich anzumelden. Das System soll von außen tutti kompletto unbedienbar sein.

Da das ganze in einem Livesystem verwendet wird, welches u.A. die verbaute Hardware auslesen soll, ist das Entfernen des USB-Moduls aber auch eher die Holzhammermethode, daher bin ich für weitere Vorschläge gerne noch offen. Das mit

Code: Alles auswählen

systemctl stop getty@tty1.service

ist eine Idee, werde ich probieren.

Aber wird dann überhaupt noch etwas angezeigt? Hab so einen schlauen Text in /etc/issue drin, der ja auf'm Loginscreen gezeigt wird.


Gibt es eine Möglichkeit, die Loginprompt zu ändern? Derzeit steht dort

Code: Alles auswählen

Debian Login:

Das verleitet natürlich einen Fremden/Angreifer dazu, es mal zu probieren. Und wer weiß wie weit da jemand kommt, der tatsächlich mal Ahnung von Linux hat.
Gelegenheit macht Diebe, wie man so schön sagt.
Kann man dieses Loginprompt ändern? Ersetzen? Entfernen?

Allerdings wäre es auch nicht so "schön", wenn die komplette Anzeige flöten geht, sonst denkt man "Ach, der scheint ja eh abgestürzt zu sein" und flupps, ist die Kiste ausgeschaltet. Das wäre natürlich auch kontraproduktiv.

Vielen vielen Dank nochmal für eure Antworten und Ideen

[smutbert]

Ok, ich hab da vielleicht etwas falsch verstanden. Soll

1. das Live-System über überhaupt keinen Login-Bildschirm verfügen oder
2. soll der Login-Bildschirm nur so lange fehlen, solange irgendeine Aufgabe durchgeführt wird und danach oder nach einem Neustart wieder verfügbar sein?

[phill971]

Wenn man es genau nimmt, soll am Ende alle Skripte die Kiste runtergefahren werden.

Dementsprechend sollte in irgendeiner Form, wie auch immer, zumindest etwas wie

"Dieser Computer wird derzeit gewartet. Bitte nicht ausschalten!"

stehen. Am liebsten wäre es mir natürlich, wenn es keinen Login-Bildschirm zeigt, sondern etwas völlig anderes. Oder eben dieses doofe "Debian Login" verschwindet, dann drückt mal jemand wild auf der Tastatur rum, aber es fällt nicht weiter auf, dass sich dort eigentlich angemeldet wird. (Durch das überschreiben von /bin/login springt er ja immer wieder auf den Loginscreen zurück).

Wie gesagt, das Livesystem muss während dem Vorgang überhaupt gar nicht von außen bedienbar sein.

[NAB]

phill971, wenn du schon so radikal bist, /bin/login zu überschreiben, guck dir mal "man agetty" an, was das Programm macht. Das könnte man durch eine Endlosschleife ersetzen ... ob das die richtige Fährte ist, weiß ich nicht.

[smutbert]

[…]
Wie gesagt, das Livesystem muss während dem Vorgang überhaupt gar nicht von außen bedienbar sein.

Danach aber schon wieder?
(Das Livesystem könnte ja auch nur diesem einen Zweck dienen...)


Nach etwas Überlegung bleibe ich aber bei meinem Vorschlag:
Wahrscheinlich brauchst du eh auch im Normalbetrieb keine 7 VTs mit Login, daher würde ich wie bereits beschrieben einmal mit der Zeile

Code: Alles auswählen

NAutoVTs=0

in der »/etc/systemd/logind.conf« den Login auf tty2 bis tty7 deaktivieren.

Den verbliebenen Login-Prompt auf tty1 kannst du wie beschrieben mit

Code: Alles auswählen

# systemctl stop getty@tty1.service
# systemctl start getty@tty1.service

nach Belieben Aktivieren und Deaktivieren.

Bleibt nur noch die gewünschte Ausgabe eines Texts auf zumindest tty1 und das könntest du mit einem Befehl wie

Code: Alles auswählen

# echo -e "\033\0143" > /dev/tty1
# echo "Vorübergehend außer Betrieb!" > /dev/tty1

machen. Der erste Befehl löscht den Inhalt und damit die eventuell vorhandene Ausgabe eines gerade eben beendeten getty/agetty und mit dem zweiten schreibst du den Text auf das VT.

Wenn du also im Normalbetrieb auf den Login von tty2 bis tty7 verzichten kannst, sollte das alles sein was du brauchst.

[NAB]

smutbert, er hat gemeiner Weise nicht verraten, dass er über die rc.local in den Bootprozess eingreifen will. Das weiß man erst, wenn man seinen zweiten Thread kennt:
viewtopic.php?f=34&t=160581

Und ich hab kein Ahnung, ob und an was Systemd die rc.local synchronisert. tty1 müsste ja schon laufen, damit man ihn stoppen kann. Besser wäre es, ihn gar nicht erst zu starten.

Mal abgesehen davon, dass wir gar nicht wissen, ob er Systemd verwendet ...

[smutbert]

Deshalb habe ich ja gefragt ob Phill971 auf diesem Live-System überhaupt einen Login braucht.


agetty auf tty1 lässt sich jedenfalls durch Löschen der Datei »/etc/systemd/system/getty.target.wants/getty@tty1.service« deaktivieren. Gemeinsam mit dem »NAutoVTs=0« hätte man dann nach dem Boot erst einmal überhaupt keine gettys mehr.
Bei Bedarf kann man das auf tty1 immer noch mit »systemctl start getty@tty1.service« starten.

Das sollte sich mit der rc.local vertragen und von systemd gehe ich einfach einmal aus solange mir Phill971 nicht widerspricht.

[NAB]

Ich vermute, nach dem Löschen wird's schwer mit dem Starten, hmm? Aber jupp, "nicht starten" klingt besser als "beenden", dann macht die Synchronisierung keinen Ärger.

phill971, du kannst übrigens auch aus deinen Scripten heraus auf /dev/tty1 schreiben ... und das für Statusmeldungen oder das Debugging benutzen.