Чи є простий спосіб реєстрації всіх виконаних команд, включаючи аргументи командного рядка?

Я намагаюся знайти, як записати конкретну інстанцію, rrdtoolщоб побачити, чи невірний він шлях.

Я знаю, що міг би обернути виконуваний файл у скрипт оболонки, який би реєстрував параметри, але мені було цікаво, чи існує більш специфічний для ядра спосіб контролю за цим, можливо, зворотний виклик файлової системи, який бачить, коли конкретний / proc / pid / exe відповідає заданому двійковій?

Так, є об'єкт ядра: підсистема аудиту. auditdДемон робить вирубку, а команда auditctlвстановлює правила ведення журналу. Ви можете реєструвати всі дзвінки до певної системи, з деякою фільтрацією. Якщо ви хочете записати всі виконані команди та їх аргументи, введіть execveсистемний виклик:

auditctl -a exit,always -S execve

Щоб спеціально простежити виклик певної програми, додайте фільтр до виконуваного програми:

auditctl -a exit,always -S execve -F path=/usr/bin/rrdtool

Журнали відображаються у /var/log/audit.logбудь-якому місці, де вони розміщуються. Вам потрібно мати root для управління підсистемою аудиту.

Після того, як ви закінчите дослідження, використовуйте той же командний рядок, -dа -aне видаляйте правило реєстрації, або запустіть, auditctl -Dщоб видалити всі правила аудиту.

Для цілей налагодження заміна програми скриптом для обгортки дає більше гнучкості для реєстрації таких речей, як оточення, інформація про батьківський процес тощо.

Ви можете використовувати snoopy .

Snoopy - це більш легке рішення, оскільки не потребує співпраці з ядром. Все, що потрібно, - це динамічний завантажувач (dl), який попередньо завантажує бібліотеку snoopy, шлях до якої вказаний в /etc/ld.so.preload.

Розкриття: Я поточний супровідник снупи.

Підсистема "аудит" ядра Linux може робити все, що вам потрібно.

наприклад, якщо ви виконуєте ці команди:

auditctl -a exit,always -F arch=b64 -S execve
auditctl -a exit,always -F arch=b32 -S execve

Потім кожен подія виконання реєструється, і навколо цього подається багато інформації

наприклад, це результат мене працює tail /var/log/audit/audit.log

exit=0 a0=7f0e4a21e987 a1=7f0e4a21e6b0 a2=7f0e4a21e808 a3=8 items=2 ppid=906 pid=928 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="tail" exe="/usr/bin/tail" subj=kernel key=(null)
type=EXECVE msg=audit(1543671660.203:64): argc=2 a0="tail" a1="/var/log/audit/audit.log"
type=CWD msg=audit(1543671660.203:64):  cwd="/home/sweh"
type=PATH msg=audit(1543671660.203:64): item=0 name="/usr/bin/tail" inode=266003 dev=fd:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=unlabeled objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1543671660.203:64): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=273793 dev=fd:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=unlabeled objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1543671660.203:64): proctitle=7461696C002F7661722F6C6F672F61756469742F61756469742E6C6F67

Є кілька цікавих цінностей, які можна побачити; наприклад, "auid" - 500, що є моїм ідентифікатором для входу, хоча "uid" дорівнює нулю ('тому що я біжу під su). Тож незважаючи на те, що користувач, можливо, перемикав облікові записи suабо sudoми все ще можемо відстежувати їх "аудиторський ідентифікатор"

Тепер ці auditctlкоманди будуть втрачені при перезавантаженні. Ви можете помістити їх у файл конфігурації (наприклад, у /etc/audit/rules.d/каталозі, на CentOS 7). Точне місце розташування залежатиме від вашої версії ОС. Сторінка auditctlпосібника повинна допомогти тут.

Однак остерігайтеся ... це призведе до генерації безлічі повідомлень журналу. Переконайтеся, що у вас є достатньо місця на диску!

При необхідності правила можуть бути обмежені певним користувачем або певною командою.

А також остерігайтеся; якщо користувач введе пароль при виконанні команди (наприклад mysql --user=username --password=passwd), він буде зареєстрований.