Jak mogę śledzić pliki wykonywalne utworzone przez mojego użytkownika w systemie Linux?


11

Korzystając z Linuksa, chciałbym śledzić pliki wykonywalne wykonywane w moim imieniu, w tym całą linię poleceń (w praktyce każdy exec * () wykonywany jako mój własny użytkownik). Program, którego nie kontroluję, ma na celu wykonanie zadania, które przekazuję, ale chcę się upewnić, że to robi, i jakich opcji używa. Program, którego nie kontroluję, jest podstępny i wydaje się zmieniać zachowanie w zależności od nazwy programu, który ma wykonać dla zadania, więc nie mogę przekazać skryptu powłoki, który zarejestrowałby informacje i wywołałby prawdziwe program.

Czy mogę otrzymywać informacje o wszystkich exec * () wykonanych jako mój użytkownik w systemie Linux, w tym o pełnej linii poleceń? psTo znaczy, że brakuje biegu w pętli. Wolę to zrobić bezpośrednio w systemie, na którym pracuję, i nie wymagam dostępu do roota, ale w razie potrzeby mogę spawnować system, do którego mam dostęp root, zainstalować programy i tam zbadać.

Korzystanie z Ubuntu 12.4 LTS.


Pytam tutaj, a nie Zapytaj Ubuntu, ponieważ jest to bardziej pytanie Unix / Linux niż prawdziwe pytanie Ubuntu.
Pierre Lebeaupin,

1
Jak przebiegły jest ten program? Czy próbuje wykryć lub ominąć debuggery? Czy jest dynamicznie powiązany? Jeśli jest to zbyt podstępne, może być konieczne użycie maszyny wirtualnej, na której jesteś rootem. (To może być najprostsza strategia nawet dla programu, który nie jest szczególnie podstępny.)
Gilles „SO- przestań być zły”

@Gilles To jest rzeczywiście możliwość, spróbuję wypróbować maszynę wirtualną, a następnie zaktualizować pytanie, czy okaże się to wykonalne.
Pierre Lebeaupin,

Uwaga: wydaje się, że tak naprawdę chcesz nazwy programu i argumentów, które auditdaje odpowiedź , ale „cała linia poleceń” w powłoce może również wpływać na proces potomny za pomocą ustawień przekierowania / potoku i envvar, a także zawierających podstawienia / rozszerzenia, nieistotne cytowanie i odstępy i struktury kontrolne doa && dob, i nie dostaniesz ich.
dave_thompson_085

Odpowiedzi:


10

Musisz skonfigurować, auditdaby rejestrować execvezdarzenia. Przykład na RHEL5:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve
WARNING - 32/64 bit syscall mismatch, you should specify an arch
[root@ditirlns01 ~]#

Ignoruję ostrzeżenie o łuku i wydaje się, że to nie ma znaczenia, ale możesz go użyć -F arch=b64lub -F arch=b32ustawić, jeśli chcesz.

Wynikiem powyższego jest:

[root@ditirlns01 ~]# ls /tmp/whatever
ls: /tmp/whatever: No such file or directory
[root@ditirlns01 ~]# grep whatever /var/log/audit/audit.log
type=EXECVE msg=audit(1386797915.232:5527206): argc=3 a0="ls" a1="--color=tty" a2="/tmp/whatever"
type=EXECVE msg=audit(1386797927.133:5527241): argc=3 a0="grep" a1="whatever" a2="/var/log/audit/audit.log"
[root@ditirlns01 ~]#

To oczywiście szybkie i brudne, ale to podstawy tego, jak to robisz. To, co musisz zrobić dokładnie, prawdopodobnie zależy w dużej mierze od tego, co chcesz dokładnie zrobić. Możesz ograniczyć przepływ inspekcji za pomocą różnych filtrów w auditctlpoleceniu, ale nie znam żadnej z tych informacji, więc nie wiem, co uwzględnić. Jeśli potrzebujesz czegoś bardziej konkretnego, sugeruję sprawdzenie strony podręcznika lub opublikowanie komentarza do tej odpowiedzi, a ja ją zaktualizuję.

Mam nadzieję, że pomożesz we właściwym kierunku.

EDYTOWAĆ:

Ponieważ twoje pytanie dotyczy konkretnego użytkownika, mogę ci pokazać, że:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F euid=16777216
WARNING - 32/64 bit syscall mismatch, you should specify an arch

Identyczny z powyższym, ale rejestrowany jest tylko execveprzez osobę działającą z efektywnym identyfikatorem użytkownika 16777216. Jeśli musisz podać wartość użytkownika loginuid(którego początkowo zalogował się w systemie jako), auidzamiast tego filtruj według :

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F auid=16777216
WARNING - 32/64 bit syscall mismatch, you should specify an arch

Filtry AUID / loginuid byłyby przydatne na przykład, jeśli użytkownik zrobi a sulub rootować sudo. W tej sytuacji będzie wiele rzeczy działających jako root, ale martwisz się tylko o rzeczy, które zostały wyrzucone przez danego użytkownika. auditctlumożliwia także układanie filtrów w stos, dzięki czemu możesz filtrować według obu tych elementów euidi auid:

[root@ditirlns01 ~]# auditctl -a always,entry -S execve -F auid=16777216 -F euid=0
WARNING - 32/64 bit syscall mismatch, you should specify an arch
[root@ditirlns01 ~]# ls /tmp/nashly -ltar
ls: /tmp/nashly: No such file or directory
[root@ditirlns01 ~]# grep nashly /var/log/audit/audit.log
type=EXECVE msg=audit(1386798635.199:5529285): argc=4 a0="ls" a1="--color=tty" a2="/tmp/nashly" a3="-ltar"
type=EXECVE msg=audit(1386798646.048:5529286): argc=3 a0="grep" a1="nashly" a2="/var/log/audit/audit.log"

1
„Pamiętaj, że nie mam dostępu do konta root”. (W przeciwnym razie byłaby to dobra odpowiedź.)
Gilles „SO- przestań być zły”

Cholera ... tak blisko ...
Bratchley,

Dzięki, działało. Powinienem dodać, że musiałem zainstalować audctl przez apt-get, nie był on wstępnie zainstalowany na Ubuntu.
Pierre Lebeaupin,

Dzięki. Ładne przykłady. Ale czy jest jakiś sposób na usunięcie kodu wyjścia z dziennika kontroli?
Kaos

0

Zadałeś coś prostego. Zrobiłem przykład, mplayerale myślę, że można go dostosować do innych sytuacji:

#! /bin/sh
# This executable must be used instead of /usr/bin/mplayer
# do not forget the chmod +x filename...
LOG=/tmp/mplayer.log
echo "$@" >> $LOG
if [ -n "$1" ] && [ -f "$1" ] ; then
        filename="$1"
        echo "$(date "+%F %T") $(basename "$filename")" \
        | tee -a "$(dirname "$filename")/mplayer.log"  >> $LOG
fi
/usr/bin/mplayer "$@"

Jak widać, jest to bardzo proste: parsuje pierwszy argument, ponieważ jest to plik, dziennik jest tworzony w pliku centralnym $LOGi łączony w plik (który ma zawsze tę samą nazwę mplayer.logw tym samym katalogu.

Tak więc użytkownik może uzyskać najnowszy film, który przeczytał w każdym katalogu.


Q konkretnie powiedział, że zastąpienie skryptu nie zadziała.
dave_thompson_085

Możliwe, ale to lepiej pasuje do mojej sytuacji: nie mam problemu z bezpieczeństwem i mogę wybrać skrypt, który uruchamiam. Choć wydaje się to niewiarygodne, myślałem o tym najprostszym najprostszym rozwiązaniu, być może ktoś inny będzie zainteresowany nie wchodzeniem w rzeczy tylko dla maniaków. Przyznaję, że poprzednie rozwiązanie jest bezpieczniejsze!
MUY Belgia,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.