Чому su до root, а не входити як root?


33

Я часто чув, що краще використовувати su root, а не входити безпосередньо як користувач root (і звичайно, люди також кажуть, що навіть краще використовувати sudo). Я ніколи не розумів, чому одне краще, ніж інше, прозріння?


2
Ви думаєте про вхід в систему ssh або також реєстрацію з фізичної машини?
Телемах

Відповіді:


43

Висновок - лише suабо sudoколи потрібно.

У більшості повсякденних завдань не потрібна оболонка кореня. Тож добре використовувати непривілейовану оболонку як свою поведінку за замовчуванням, а потім підняти на корінь лише тоді, коли потрібно виконати спеціальні завдання.

Тим самим ви зменшуєте можливості для небезпечних помилок (поганого сценарію, неправильних скриптів тощо) та вразливості від будь-яких застосувань, якими ви користуєтеся. Особливо ті, хто підключається до Інтернету - дивіться старе прислів’я "Не IRC як корінь" .

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

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


1
Не могли б ви зрозуміти, чому віддалений корінговий логін - це "досить велика вразливість".
thepocketwade

5
Оскільки, враховуючи, що весь світ знає ім’я користувача ('root'), це лише питання з'ясування пароля. І вони можуть це зробити грубою силою і захопити ваш комп’ютер.
Шалом Креймер

2
Ще одна перевага sudo: Реєстрація виконаних команд.
Мануель Фокс

Ось аудит;)
Ден Карлі

1
Хоча sudoце перевершує, suтакож дозволяє використовувати -mпрапор, щоб зберегти змінні середовища однаковими під час кореневого терміналу. Ніщо не спонукає мене до більшої кількості бонкерів, а потім suтрохи викорінювати, лише робити щось із ~імені каталогу та не працювати.
tj111

27

Вам слід вимкнути кореневий доступ від віддаленого, щоб зловмисник не міг скомпрометувати root, не спершу скомпрометувавши користувача, а потім перейшов до root. Увімкнено кореневий доступ лише в консолі.

Плюс це створює відповідальність. :)


+1 короткий і до
суті

15

Основна причина - створити аудиторський слід. Якщо вам потрібно увійти в систему як звичайний користувач, а потім su, можна простежити, хто відповідає за дані дії.


Після того, як хтось запустив su-root, як визначити, які команди вони виконували? Це десь записано?
Dobes Vandermeer

10

sudo також автоматично реєструє кожну команду в syslog, і ви можете визначити команди, які може використовувати кожен користувач.


3
Що стосується ведення журналу: Це стосується кожної команди, якій передує 'sudo', але у випадку, коли sudo використовується для піднесення до кореневої оболонки, команди реєструються лише у традиційних областях (зокрема в історії оболонок).
Zenham

2
Дійсно, sudo vim foo.txtперехід на оболонку зсередини vim дасть вам кореневу оболонку без регулярного ведення журналу sudo.
Офідіан

Або просто sudo -iотримати інтерактивну сесію ...
Каміль Кісієль

Я не розумію проблеми з sudo vim foo.txt. Я запустив це, потім вийшов з vim і все ще був самим собою, чи щось мені не вистачає?
thepocketwade

ви можете «обдурити» sudo, щоб надати вам оболонку, ввівши sudo su - або sudo vim, а потім перейти до нової нижньої частини. Але якщо ви використовуєте sudo, тому що ви хочете, щоб все ввійшло в syslog (централізовано) і ви знаєте, що це також може бути використане для отримання іншої підпакеті, то я не бачу в цьому нічого поганого, це просто бонус, поки я не залежу тільки від цього.
Jure1873

9

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


4

Якщо ви хочете створити аудиторський слід і не хочете стати жертвою проблем, зазначених тут «sudo su -» або «sudo vim foo.txt», ви можете використовувати «sudosh». Роздайте кореневий доступ через sudo, але зробіть єдино допустиму команду для запуску "sudosh".

sudosh - це оболонка журналу, і ви можете пізніше відтворювати весь сеанс терміналу, показуючи, що саме бачив користувач у своєму терміналі.


Це, звичайно, припускаючи, що sudosh доступний у системі. Я щойно перевірив, і я не маю цього в жодній з моїх скриньок Linux.
Джон Гарденєр

Ви також можете використовувати новий ksh93 з увімкненим веденням протоколу аудиту. Перевірте цю статтю в IBM Developerworks: ibm.com/developerworks/aix/library/au-korn93 / ...
Mei

Досить просто обійти, просто запустивши скрипт оболонки (який потім витираєте). Створіть скрипт під невинним іменем, як користувач, який не перевіряється (або скопіюйте його зі своєї робочої станції), а потім надішліть його та запустіть його. Ви навіть можете дійсно приховати його, назвавши його "ls" або somesuch і помістивши його в $ PATH (змінюючи $ PATH, якщо потрібно), і змусити його робити свою брудну роботу, викликаючи / bin / ls, щоб це виглядало нормально. Протріть його після цього. Журнал аудиту не знатиме, що / home / anthony / bin використовується для "ls".
дероберт

Так, це не ідеально; ми це знаємо - але це проклятий сайт краще, ніж звичайний "sudo su -" IMHO. І так, це не встановлено за замовчуванням у будь-якому місці AFAIK. Однак він працює на Solaris та Linux досить легко.
mibus

1

Ви повинні глибоко практикувати безпеку.

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

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

В ідеальному світі ви повинні мати можливість публікувати свої кореневі паролі в Інтернеті, і це не має значення, навіть якщо ви давали людям доступ до вашої машини (але не поміщали їх у файл / etc / sudoers). Звичайно, ви не повинні публікувати кореневий пароль, але ідея полягає в тому, що ви захищаєте свої системи концентричними шарами захисту.


0

Ідея полягає в тому, щоб вимкнути вхід в систему, тому не мати облікового запису адміністратора за замовчуванням. Таким чином зловмисник повинен відгадати і ім’я користувача, і пароль (а не лише пароль).


0

Якщо ви використовуєте root на регулярній основі, то ваші дозволи можуть бути помилковими, або вам може знадобитися надати права sudo або нову групову прав на r / w / x файли чи каталоги.

Хороші схеми дозволів - це те, що навіть давно користувачі Linux помиляються або не усвідомлюють сферу їх використання.

Навіть не запускайте мене з того, що зробив Ubuntu!


-2

Це заважає вам запустити rm -r -f / Я щойно запустив це 2 дні тому (як непривілейований користувач, я мав на увазі запустити rm -r -f *)


У прийнятій відповіді вже була вся інформація.
Теуні
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.