Kann ein Sysadmin die Terminals seiner Benutzer abhören?

Wenn ich bei einem Computer angemeldet bin, kann ich die Pseudo-Endgeräte aller Benutzer aus der Ausgabe von herausfinden w. Kann ich als Sysadmin dieses Terminal abhören, ohne dass der Benutzer es merkt? Mit anderen Worten, ich möchte alles, was auf diesem Terminal ausgeführt wird, als Ausgabe auf meinem eigenen Terminal sehen.

Bitte beachten Sie Folgendes:

• Dies ist kein praktischer Anwendungsfall für die Überwachung von Benutzeraktivitäten: Ich bin mir bewusst, dass es dafür Systemüberwachungs-Tools gibt. Ich bin nur gespannt, ob es geht.
• Ich bin mir dieser Frage bewusst und es scheint nicht zu decken, wonach ich frage, da alle dort vorgeschlagenen Lösungen entweder invasiv sind (der Benutzer würde sich dessen bewusst sein, was ich tue) oder zu viel Lärm erzeugen (die) straceLösung). Die eine Lösung, die nahe kommt, ist die, die die Verwendung vorschlägt gdb. Damit sehe ich aber nur die stdout des anderen Terminals.

Was ich probiert habe

Ich habe das von meinem Terminal aus versucht:

tee /dev/pts/user_pts </dev/pts/user_pts

Dadurch kann ich jedes Zeichen sehen, das der Benutzer in das andere Pseudoterminal eingibt, während er es eingibt. Das Problem ist, alle paar Zeichen würde es "überspringen": Es würde ein Schurkenzeichen auf einem Endgerät zeigen, aber nicht das andere. Es verhindert auch die Ausführung von Befehlen vom Pseudo-Endgerät des Benutzers. Ich bin mir nicht sicher, warum dies geschieht und ob es einen Weg gibt, es zu verbessern.

Was ich gerne sehen würde

USER TERMINAL        |    MY TERMINAL
$ echo "Test"        |    # slick_command_here
Test                 |    echo "Test"
$                    |    Test

Es ist der FD zur Masterseite des Pseudoterminals im Terminalemulator, den Sie überwachen möchten, wenn Sie sehen möchten, was darauf angezeigt wird. Dieser Master fd simuliert den Draht, der zu einem realen Anschluss führt. Was darauf xtermschreibt, sind die Zeichen, die aus der von Ihnen gedrückten Taste generiert werden. Was es davon liest, ist das, was es anzeigt.

Zum Beispiel unter Linux:

$ lsof -ac xterm /dev/ptmx
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
xterm   15173 chazelas    4u   CHR    5,2      0t0 2131 /dev/ptmx

Und dann zum Beispiel:

stty -echo -opost
strace -e read -e read=4 -p15173 2>&1 | stdbuf -o0 sh -c '
  grep "^ |" | cut -b11-60 | tr -d " " | xxd -r -p'

Natürlich funktioniert es besser, wenn Sie das auf einem Terminal ausführen, das den gleichen Typ und die gleiche Größe hat wie das, das Sie überwachen möchten. Sie können die Größe erhalten mit:

stty size < /dev/pts/that-terminal

Das gibt aus, was von der Masterseite des Terminals gelesen wird xterm, also was dort angezeigt wird, einschließlich der lokalen echoEingabe.

Das -e read=4obige dient stracedazu, einen Hexdump von dem auszugeben, was xtermauf seinem fd 4 steht. Der Rest des Befehls besteht darin, dies in die tatsächlichen Zeichen umzuwandeln. Ich habe es versucht, peekfd -n -8 15173 4aber aus irgendeinem Grund gab es nur das, was geschrieben wurde.

Wir -opostdeaktivieren alle Nachbearbeitungen in unserem Überwachungsterminal, damit alle xxdSchreibvorgänge auf der Slave-Seite unverändert auf der Master-Seite ablaufen, sodass unsere Überwachung xtermmit der überwachten identisch ist. -echoWenn die Anwendung im überwachten Terminal eine Escape-Sequenz sendet, die eine Antwort vom Terminal anfordert (z. B. diejenigen, die die Cursorposition oder den Terminaltyp oder den Fenstertitel anfordern), gelangt dies zu unserer Überwachung xtermund unserem xtermTestament antworte auch. Wir wollen kein lokales Echo davon.

Sie können auch überwachen , was durch Verfolgen der getippt werden writeSystemaufrufe zu gleichen fd (ersetzen readmit writeoben). Beachten Sie, dass Enterder Terminalemulator beim Drücken von ein CR-Zeichen und nicht LF sendet. Da wir auf der Masterseite nachverfolgen, werden a<Backspace>balle 3 Tastenanschläge angezeigt, auch wenn sich das Endgerät im kanonischen Modus befindet, wenn der Benutzer tippt.

Warum funktioniert deins nicht?

tee /dev/pts/user_pts </dev/pts/user_pts

Beim Lesen vom Endgerät wird die Benutzereingabe gelesen, und beim Schreiben wird sie dem Benutzer angezeigt.

Sie möchten teevom Endgerät lesen. Das, was es liest (die Benutzereingabe), wird also nicht readvon der / den Anwendung (en) im Terminal ausgeführt (und umgekehrt, teeund das applicationkämpft um die Terminaleingabe). Schreiben auf das Endgerät, dient dort zur Anzeige, nicht zum Zurücklegen als Eingabe. Wenn Sie das tun

echo test

(wobei echostdout das Terminal ist), ist es nicht dasselbe, als ob Sie getippt hätten test.

Es gibt ein ioctl( TIOCSTI) zum Zurücksetzen von Zeichen als Eingabe, aber selbst das würde nicht wirklich funktionieren, da Sie es nach dem Lesen der Anwendung zurücksetzen könnten , so dass sich die Reihenfolge ändert, in der die Anwendung Eingaben liest. das würde bedeuten, dass Sie es immer und immer wieder lesen würden.

Wenn Ihr Betriebssystem dtrace unterstützt , sollten Sie mit einem einfachen Skript, shellsnoop , alles überwachen können, was auf einem bestimmten tty geschrieben / gedruckt ist.

Wenn Sie Linux verwenden, hat ttysnoop eine ähnliche Aktion ausgeführt , aber eine aufdringliche Konfiguration als Voraussetzung benötigt. AFAIK wird von den aktuellen Kernels sowieso nicht mehr unterstützt, was in Ihrem Fall keine Hilfe darstellt. Es gibt mehr oder weniger fortgeschrittene Versuche, eine dynamische Ablaufverfolgung mit Linux, systemtap, ktap und sogar dtrace bereitzustellen, damit Sie sie untersuchen können.

Edit: Vorsicht vor peekfd , die Manualpage besagt:

Bugs:

Wahrscheinlich viele. Seien Sie nicht überrascht, wenn der Prozess, den Sie überwachen, abbricht.

Dieser Ansatz beinhaltet ein wenig GDB und Tee. Ah, und es benutzt auch socat, um ein Pseudo-Terminal zu emulieren. Es könnte auch ohne funktionieren, aber der Benutzer wird bemerken, dass seine Ausgabe kein Terminal mehr ist (Programme wie vi werden sich beschweren).

Es macht Folgendes:

1. Erstellen Sie mit socat einen Interceptor, der sich als Pty ausgibt.
2. Der Interceptor ist mit tee verbunden, das Streams sowohl im $ sys-Terminal als auch im $ usr-Terminal dupliziert.
3. Gdb wird verwendet, um die stdout / stderr-Dateideskriptoren zu ersetzen und statt des $ usr-Terminals auf den Interceptor zu verweisen.

Mir ist aufgefallen, dass Bash zu schreiben scheint, was Sie in stderr eingeben. Ich bin mir nicht sicher, ob andere Programme dasselbe tun. In diesem Fall muss stdin nicht abgefangen werden.

Nennen Sie es wie folgt aus : chmod +x /path/to/script; sudo /path/to/script <usr> <sys-adm>. usrund sys-admsind die Namen der Terminals, zum Beispiel /dev/pts/1. So ein Beispielaufruf würde wie folgt aussehen: sudo /path/to/script /dev/pts/1 /dev/pts/2. Sie können Ihr Terminal mit dem ttyBefehl herausfinden . Und das Benutzerendgerät entweder mit woder ps.

#!/bin/sh

[ "$1" ] || exit 1
[ "$2" ] || exit 1

usr=$1
sys=$2
utty=${1#/dev/}

ps -e -o tty= -o pid= -o user= | { 
    found_it=

    while read -r tty pid_sh owner; do
        if [ "$utty" = "$tty" ]; then
            found_it=y
            break;
        fi
    done

    [ "$found_it" ] || exit 1

    tmp=$(mktemp)
    tmp_gdb=$(mktemp)

    trap 'rm "$tmp" "$tmp_gdb"' EXIT

    socat PTY,link="$tmp",echo=0,raw,openpty,user="$owner",mode=0600 SYSTEM:"tee $sys > $usr"      &

    printf 'call dup2(open("%s", 1), 1)\ncall dup2(open("%s", 1), 2)
            detach\nquit\n' "$tmp" "$tmp" > "$tmp_gdb"
    gdb -p "$pid_sh" -x "$tmp_gdb" >/dev/null 2>&1 &

    wait
}

Es gibt ein einfaches C-Programm namens xkey.c, das die Exploits von X11 zeigt. Ich lasse dich googeln. Sie können die Tastenanschläge auf einem xterm erfassen, ohne dass der Benutzer davon Kenntnis hat.