Як увійти до команди «sudo su -»?

Якщо я:

[user@notebook ~] sudo echo 123456uu
123456uu
[user@notebook ~] 

Тоді я можу побачити це в журналах:

[root@notebook /var/log] grep 123456uu *
auth.log:Jan  9 17:01:51 notebook sudo: user : TTY=pts/3 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo 123456uu
[root@notebook /var/log] 

але якщо я:

[user@notebook ~] sudo su -
[root@notebook ~] echo 1234567zz
1234567zz
[root@notebook ~] 

Я не бачу його в журналах:

[root@notebook /var/log] grep 1234567zz *
[root@notebook /var/log] echo $?
1
[root@notebook /var/log] 

Моє запитання: Як я можу включити вхід для команд у межах "sudo su -"?

ОС - це Ubuntu 12.04, але питання взагалі.

ОНОВЛЕННЯ №1:

[user@notebook ~] sudo su -
[sudo] password for user: 
[root@notebook ~] echo zizizi
zizizi
[root@notebook ~] cd /var/log
[root@notebook /var/log] grep -iIR 'zizizi' *
[root@notebook /var/log] grep 'COMMAND=/bin/su -' *
auth.log:Jan 10 15:42:42 notebook sudo: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/bin/su -
[root@notebook /var/log]

Оскільки ви перебуваєте на Ubuntu 12.04, ознайомтеся з можливостями реєстрації вводу / виводу, активованими за допомогою параметрів log_inputта log_output.

log_input

Якщо встановлено, sudoзапустіть команду в псевдотипі та записуйте весь вхід користувача. Якщо стандартний вхід не підключений до tty користувача через перенаправлення вводу / виводу або через те, що команда є частиною конвеєра, цей вхід також фіксується і зберігається в окремому файлі журналу.

Вхід записується в каталог, визначений iolog_dirопцією ( /var/log/sudo-ioза замовчуванням), використовуючи унікальний ідентифікатор сеансу, який включений у звичайний рядок журналу sudo з префіксом TSID=. Ця iolog_fileопція може використовуватися для керування форматом ідентифікатора сеансу.

Зауважте, що введення користувача може містити конфіденційну інформацію, таку як паролі (навіть якщо вони не перегукуються на екрані), яка зберігатиметься у файлі журналу незашифрованим. У більшості випадків необхідне ведення журналу виведення команди через log_output.

log_output

Якщо встановлено, sudoвиконується команда в псевдотипі і записує весь вихід, який надсилається на екран, аналогічно команді script (1). Якщо стандартний вихід або стандартна помилка не пов'язані з tty користувача через перенаправлення вводу / виводу або через те, що команда є частиною конвеєра, цей вихід також фіксується і зберігається в окремих файлах журналу.

Вихід записується до каталогу, визначеного iolog_dirпараметром ( /var/log/sudo-ioза замовчуванням), використовуючи унікальний ідентифікатор сеансу, який входить у звичайний рядок журналу sudo з префіксом TSID=. Ця iolog_fileопція може використовуватися для керування форматом ідентифікатора сеансу.

Журнали виводу можуть переглядатися за допомогою утиліти sudoreplay (8), яка також може використовуватися для списку або пошуку доступних журналів.

ВПРОВАДЖЕННЯ: Версія судо принаймні: потрібна 1.7.4p4.

/etc/sudoersмодифікація: все, що вам потрібно зробити, - це додати два теги до всіх необхідних записів sudoers (де вказано "su", або з командою, або псевдонімом). LOG_INPUT і LOG_OUTPUT.

Приклад:

%admins         ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL

Додайте таку структуру dir журналу за замовчуванням до sudoers:

Defaults iolog_dir=/var/log/sudo-io/%{user}

Якщо ви grepробите sudo su -не вдається, тому що ви не працюєте echo 1234567zz, ви працюєте su -, що запускає оболонку. Потім оболонка працює за вашим echo.

Це навмисно, і реєстрація кожного запуску команди заповнить ваш системний журнал непотрібною інформацією (зазвичай є безліч програм, які запускаються за лаштунками, які ви зазвичай не бачите).

Якщо ви зміните свою грепку, grep 'COMMAND=/bin/su -' *ви побачите її.

sudo su -також є марним використанням su. sudo -iробить те саме.

Збільшуючи складність, ось три способи реєстрації команд, виданих у межах "sudo su -":

1. Покладайтеся на історію команд bash
2. Встановіть обгортку журналу execve
3. Використовуйте аудит SELinux

Що стосується того, що підходить, то насправді залежить від того, що ви намагаєтеся виконати з веденням журналу.

1) Історія команд Bash

Ви хочете налаштувати фактичність історії, щоб забезпечити збереження достатнього рядка, не перезаписи з різних сеансів, не ігнорування команд та відповідних часових позначок. (Див. HIST * змінні у посібнику з bash ). Легко підривається, редагуючи файл історії, маніпулюючи середовищем або запускаючи іншу оболонку.

2) виконувати обгортку

snoopylogger - це один. Додайте перевірку, чи знаходиться /etc/profileбібліотека журналів у карті пам'яті процесу ( /proc/<pid>/maps), а якщо ні, встановіть LD_PRELOADі перезапустіть (з exec $SHELL --login "$@"). Крім того, ви можете додати запис до /etc/ld.so.preload з $LIB/snoopy.soабо еквівалентними шляхами до своїх 32/64-бітних версій snoopy.so.

Хоча і складніше, LD_PRELOADзмінна середовище вищезгаданої версії все ще може бути зірвана шляхом маніпулювання середовищем виконання, щоб код snoopy більше не запускався.

Syslog слід надсилати поза скринькою, щоб вміст був надійним.

3) аудитор

Налаштувати трохи простіше, ніж обгортку execve, але важче витягнути інформацію з неї. Це відповідь на питання, яке ви, ймовірно, справді задаєте: "Чи є спосіб зареєструвати, який вплив користувач має на систему після їх видачі sudo su -". Syslog слід надсилати поза скринькою, щоб вміст був надійним.

Ця відповідь Serverfault відповідає досить вичерпною конфігурацією для використання з аудитом.

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

Чому?

Тому що це те, sudoщо ведуть лісозаготівлю; він реєструє судо-команди. У першому випадку sudo echoпроводиться реєстрація. У другому випадку sudo suвходить у систему (шукайте його /var/log/auth.log).

suє "переключити користувача", за замовчуванням на root. Все, що ви робите після цього , не проходить sudo. Це так само, як якщо б ви ввійшли як root; сам логін реєструється, але не кожна команда.

Як говорили інші, цього sudoне можна зробити.

Натомість використовуйте auditd. Якщо ви хочете записати все, що робиться під коренем (включаючи, наприклад, речі, зроблені crontab), використовуйте це:

sudo auditctl -a exit,always -F euid=0

ETA: Зауважте, що реєстрація все вплине на продуктивність, тому, ймовірно, ви хочете трохи обмежити це. Дивіться man auditctlприклади.

Якщо ви хочете реєструвати тільки syscalls, де початковий uid uid не є root, скористайтеся цим замість цього:

sudo auditctl -a exit,always -F euid=0 -F auid!=0

Журнали зазвичай закінчуються в /var/log/audit/audit.log. Ви можете шукати в них ausearch.

Там більше інформації на сторінках керівництва для auditctl, audit.rulesі ausearch.

sudo su -буде в тому ~/.bash_historyвипадку, якщо ваша шкаралупа забита

echo 1234567zzбуде в тому /root/.bash_historyвипадку, якщо оболонка кореня буде баш.

Пояснення цього вже було розміщено золотистими.

Ви хочете, щоб su ввійшов до системи, оскільки ви вважаєте, що це вада безпеки? Ви думали над цією командою? sudo bashтак само погано Імхо.

Якщо ви переживаєте, що люди можуть робити із судо, тоді вам потрібно буде обмежити його використання. Ви можете обмежити команди, які вони також можуть виконувати. Обмежте доступ до / bin / su, якщо це вас турбує.

Як що до цього:

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log'
sudo -E su
unset PROMPT_COMMAND

або

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' 
sudo -E su --preserve-environment -
unset PROMPT_COMMAND

або довгий одноводковий:

HISTTIMEFORMAT="%d/%m/%y %T " PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su

sudo -E зберігає середовище PROMPT_COMMAND виконується перед кожним запитом

Якщо це допоможе, ви можете скористатись опцією "NOEXEC" надувних верфі.

Потрібно визначити це як

USER_NAME         ALL=(ALL) NOEXEC : ALL

Це запобіжить уникненню оболонок і користувач не зможе використовувати sudo -i або sudo -s або sudo su -

Це пов'язано зі зворотним боком, однак, будь-яке втеча з оболонки буде вимкнено. для виконання сценарію всередині сценарію також буде відмовлено.

Не давайте цього ускладнювати: щоразу, коли sudoйого викликають, він повідомляє про цей факт у якомусь файлі в /var/log(у вашій системі є auth.log, у моєму вікні OS X це system.log). sudoповідомляє про свої аргументи командного рядка, але він не знає, що може статися всередині такої інтерактивної команди su.

Це не означає, що немає запису про те, що відбувається в кореневій підзахисті: команди Shell зберігаються в історії оболонки. У моїй системі збереження історії кореневих файлів увімкнено за замовчуванням, тому все, що мені потрібно було б зробити, це шукати ~root/.sh_historyзапис про те, що було зроблено (якщо, звичайно, хтось із цим не підробляв, але вони могли однаково добре підробити /var/log).

Я думаю, що це найкраще рішення для вас. Якщо ні, їдьте до міста auditd, як запропонував @Jenny.

PS. Якщо історія root вже не ввімкнена, включення залежить від того, яку оболонку вона використовує. Для bash, встановіть HISTORYі HISTFILESIZEдостатньо велику кількість (за замовчуванням 500, моє керівництво). За бажанням можна вказати, де зберігається історія, встановивши HISTFILEшлях (за замовчуванням $HOME/.sh_history)

Ви можете створити машинопис вашого сеансу, використовуючи script(1):

$ sudo su -
# script -t /tmp/my_typescript 2> /tmp/my_typescript.timing
Script started, file is /tmp/my_typescript
# echo foobar
foobar
# echo hello world
hello world
# exit
exit
Script done, file is /tmp/my_typescript

Тепер ви можете grep(зауважте, що #запити фактично записані в /tmp/my_typescript):

$ grep echo /tmp/my_typescript
# echo foobar
# echo hello world

Крім того, ви можете навіть переглянути цілий сеанс знову за допомогою scriptreplay(1):

$ scriptreplay -t /tmp/my_typescript.timing /tmp/my_typescript

Файл /tmp/my_typescript.timingмістить інформацію, коли кожна команда викликана. Є й інші інструменти , такі як ttyrecабо shelrщо ще більше наворотів.