Чим sudo безпечніше, ніж безпосередньо використовувати su, якщо користувачеві надається доступ до всіх команд?


40

Тож я читав про відмінності між використанням suта sudo, і, здається, всі згодні з тим, що sudoпідхід безпечніший, ніж дозволяти доступ до самого кореневого облікового запису. Вони кажуть, що за допомогою кореневого облікового запису ви могли зламати всю систему лише однією командою. Це я розумію. АЛЕ початковий користувач, створений у системі, також має доступ до всіх команд, що використовують sudo. Це я можу з’ясувати, запустившись su -l. Якщо це так, то я можу просто бігти, sudo <game-ending command>щоб зруйнувати свою систему. Тож як цей підхід кращий чи безпечніший, а потім дозволяє мені отримати прямий доступ до суперкористувача? Я можу запускати всі ті самі команди ...

Це тому, що sudoв командному рядку явно кажу комп’ютеру, я думаю, що знаю, що роблю? Вони думають, що люди забудуть, що вони знаходяться під обліковим записом супер користувача, якщо вони прямо не скажуть це?

Люди також заявляють, що якби система була піддана компрометації та вступила хтось із закордонних, знаходження під кореневим рахунком дозволило б їм робити жахливі речі для моєї системи. Але мені здається, якщо вони вже мають доступ до мого облікового запису та знають мій пароль, вони можуть робити ті самі жахливі речі, використовуючи sudo та вводячи мій пароль, оскільки їм навіть не потрібно знати пароль суперкористувача. Чого я не потрапляю сюди?



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

Відповіді:


40

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

Переваги (не в певному порядку):

  • Судо має чудову лісозаготівлю. sudo записує кожну команду.
  • sudo дозволяє більш тонкий контроль зерна. Можна настроїти sudo, щоб надати root доступ до деяких, але не всіх команд.
  • sudo використовує пароль для входу. Це захищає необхідність вводити корінний пароль (як це було б із су) і пов'язане з пунктом вище щодо тонкого зернистого контролю / доступу до кореня.
  • У Ubuntu за замовчуванням кореневий рахунок заблоковано. Це стримує сухариків щодо входу в систему (віддалено через сказати ssh), вони повинні вгадувати і ім’я користувача, і пароль. Якщо кореневий обліковий запис не заблокований, як у випадку з su, їм потрібно лише зламати пароль root.
  • sudo -i- це, мабуть, найкращий спосіб ізолювати змінні середовища root від вашого користувача. Це час від часу з'являється, але є помірно езотеричним. Дивіться https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
  • Деякі люди вважають, що введення sudo перед кожною командою, яку вони бажають запустити як root або мати час судо-виходу, дозволяє їм зупинитися і думати чіткіше, а також зменшує їх помилки або виконання помилкових команд. Якщо це допоможе вам, це також буде користю.

Переваги є, ймовірно, більше, але це основні, ІМХО.

Дивіться також - https://help.ubuntu.com/community/RootSudo

Щоб спробувати відповісти на деякі ваші інші думки:

  • Ні про су, ні про судо не заважає запускати шкідливий код, доки ви знаєте пароль. Ні безпечніше, ні краще.
  • Крекери можуть отримати доступ до оболонки за допомогою ряду методів. Якщо ви побачите "запустити довільний код" у повідомленні про безпеку - https://usn.ubuntu.com/usn/ - це означає, що зломщик може запускати / bin / bash або будь-який інший код. Таким чином, зломщик, за допомогою різних подвигів, може отримати доступ до оболонки, не знаючи свого імені для входу або пароля. Ні судо, ні су не допомагають у цьому.
  • Якщо зловмисник має доступ до оболонки, вони можуть завдати великої шкоди без кореневого доступу. Наприклад, програмне забезпечення, яке шифрує всі ваші особисті дані.
  • Якщо зловмисник має оболонку доступу до облікового запису з кореневим доступом через su або sudo, він може отримати кореневий доступ за допомогою ряду методів, що виходять за межі цього обговорення. Ні судо, ні су в цьому плані не є вищими.

Таким чином, хоча у вас спостерігаються проблеми або недоліки з sudo, su має такі самі вразливості, і su в цих аспектах не перевершує sudo, IMHO


Було б добре мати доступ, щоб дозволити всім користувачам живлення (потужність та перезавантаження) контролювати після зупинки інталяції, а не записи судерів або назви групи.
mckenzm

8
Я вважаю, що найбільша перевага полягає в тому, щоб виправдати кожну команду необхідністю дозволів суперпользователя. У своєму ранньому досвіді роботи з Linux я виявив, що, як правило, завжди працював як root як мінімум на одному терміналі, коли я працював у системі. На жаль, видати руйнівну команду на терміналі дуже просто шляхом нерозуміння чи помилки. Якщо це було у «кореневому терміналі», це може призвести до відновлення із резервної копії чи перевстановлення. Судо захистило мене від цього багато разів!
ролінгер

14
Не шкода кореневого пароля - це, мабуть, найбільша перевага sudo. Ви можете дати дозвіл кореня, не розкриваючи жодних секретів.
Thorbjørn Ravn Andersen

Ви не тільки можете обмежувати команди, але навіть можете обмежувати вказані аргументи. Але я не погоджуюся з тим, що заблокований корінь має щось спільне з цим; тому що ви можете налаштувати ssh, щоб заборонити вхід у систему root. Щось із su срещу sudo: є щось інше: sudo ви використовуєте свій пароль користувача, який є одним меншим числом паролів, щоб їх було порушено, і це, як правило, не дуже добре. Як і все в цьому світі, існують різні способи зробити щось, і це не означає, що один спосіб є більш правильним, ніж інші, 100% часу, якщо взагалі. Тоді є вподобання.
Прифтан

Але отох, якщо це більше ніж один користувач, який потребує кореневого доступу (це не те, що я буду вникати, тому що це просто - ну, це в кращому випадку гаряча дискусія), то sudo має перевагу.
Прифтан

10

Уявіть, у вас є 20 хвилин, щоб зробити щось складне. Ви трохи похмурі, і вам доведеться поспішати. "Давайте використовувати su" ви говорите. «Це заощадить час» - це ваше міркування.

Випадково набираєте текст

rm -rf /*

замість

rm -rf ./*

Ваша система тепер самозаймається, і у вас є 10 хвилин до закінчення терміну.

Якщо ви чітко вибираєте, коли вам потрібен корінь, ви можете мінімізувати ймовірність цього. Корінь може не знадобитися, rm -r ./*тому навіщо його використовувати? Навіщо ризикувати?

Ось що тут означає "безпека". Мінімізація ризику, коли користувачі (усі користувачі, а не лише початківці) роблять фатальну помилку.

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

Безпека розумних Є деякі речі, що судо теж краще. Як говорить @Panther - реєстрація, обмеження, пароль root є SPOF тощо)


4
Чорт, вам не потрібно чекати так довго, якщо ви просто зробите ... chown -R nobody:nobody /або навіть chown -R nobody ../як root. chmodЗвичайно, подібні проблеми є і в рекурсивному режимі. Але найкраще, що ви робите, - це те, що ви повинні мати корінь лише тоді, коли вам це потрібно; чим менше привілей вашого входу, тим краще для нормального використання.
Прифтан

2
+1, але для програмування, коли ви займаєтесь походом.
abhicantdraw

4
Отже, як це відрізняється sudo? Ви пишете sudo rm -rf /*замість sudo rm -rf ./*і знову бум.
ilkkachu

2
@ilkkachu з точки зору фактичної команди, вона має мінімальну різницю в тому, що відбувається. Але вам довелося чітко заявити, що ви хочете зробити це як root. В тім-то й річ. Безпека стосується управління ризиками. Звичайно, ви все одно можете цеглити систему. Але чим менше часу у вас є кореневі привілеї, тим менше шансів зробити фатальну помилку. Безпека полягає в мінімізації ймовірностей.
dijksterhuis

2
@ilkkachu Тому що ви НЕ вводити sudo rm -rf ./*. Імовірно, ви маєте доступ для запису до матеріалів у поточному каталозі, тому вам не потрібно судо для цієї команди. Таким чином , в typoed команди закінчує тим rm -rf /*, що дає довгий рядок «Відмовлено в доступі» повідомлення, даючи вам знати , що вам потрібно , ctrl-cперш ніж він потрапляє в матеріал ви можете видалити, замість того , щоб просто видалити всі в /bin, /boot, /dev, і половина /etcперед тим Ви навіть розумієте, що щось не так.
Рей

9

Я хочу додати трохи історичної точки зору до інших відповідей. На жаль, у мене немає готових джерел, крім моїх власних спогадів про дискусії Usenet та статті журналів.

Деякий час тому, у 90-х роках, дистрибуції полегшували установку Linux на власне обладнання, навіть не маючи знань на комп’ютері ». Таким чином, Linux почав залучати все більше людей, які напрочуд раніше не були підготовлені як адміністратори системи на деякий діалект UN * X. Натомість багато хто використовувався для систем (для одного користувача), таких як Windows 95/98. І вони дізналися, що більшість завдань системного адміністрування Linux змушує працювати під цим дивним "кореневим" обліковим записом.

Таким чином, деякі користувачі просто увійшли як root і використовували цей обліковий запис для всієї щоденної роботи. Чому вони повинні знову і знову вводити suі кореневий пароль або входити в новий tty лише для деяких команд адміністратора? Але використовувати root для всього - це, звичайно, не дуже гарна ідея, оскільки ви можете зробити набагато більше шкоди вашій системі, якщо невміла команда в неправильному місці. Це навіть призвело до деяких дистрибутивів (це був SuSE?) Для зміни фону робочого столу для кореневого користувача, щоб відображати велике попередження про те, що ви повинні використовувати цей обліковий запис лише для завдань адміністратора.

Отже, спосіб Ubuntu з sudoмає деякі переваги (крім тих, які вже перераховані Panther ).

  • Ви не можете безпосередньо увійти до кореневого облікового запису.² :-)
  • Процес установки не запитає у вас (додатковий) корінний пароль, вам потрібен лише один (ваш користувальницький) пароль.
  • sudoкешує ваші облікові дані, тому для декількох команд адміністратора послідовно вам потрібно ввести свій пароль лише один раз (на відміну від su). Це зменшує бажання просто відкрити оболонку або новий термінал з правами root .
  • Це полегшує інформацію користувачам в Інтернеті та в документації, які команди вони повинні вводити як адміністратор, а які ні

¹ А для тих, хто не наважився зробити це самі, були встановлені вечірки.
² Але ви можете використовувати команду на зразок sudo -iабо sudo su - rootотримати кореневу оболонку після входу в систему як звичайний користувач.
³ Але ви, звичайно, знаєте, що не слід просто копіювати та вставляти команди з Інтернету , правда?


Ви говорите в Ubuntu, що не можете цього робити: sudo su -або sudo su - root? Тому що я бачив подібні твердження, наприклад, що у MacOS X немає кореня, але це абсолютно неправильно, коли потрібно виконати лише першу команду ...
Прифтан

2
Звичайно, є кореневий рахунок. Я сказав, що ви не можете "безпосередньо увійти", тобто ви не можете ввести користувача rootта пароль у запиті про вхід або діалоговому вікні входу X та розпочати сеанс як корінь. Але ви можете використовувати одну зі своїх команд (я вважаю за краще sudo -i, що це коротше і я лінивий), щоб отримати кореневу оболонку.
Дубу

1
Будь ласка, прочитайте ще раз мій коментар :) Я сказав, що деякі кажуть, що у MacOS X немає кореневого облікового запису, але насправді це є, і це мені нагадало (я не прирівнював його до того, що в Ubuntu немає кореневого акаунта). Але я знаю, що розробники Ubuntu були досить божевільні, щоб наклеїти судо, щоб не допустити цього мого питання.
Прифтан

1
@Pryftan Як я вже говорив у своєму коментарі вище, обидві ваші команди працюють, і ви отримаєте кореневу оболонку. Я додам це до своєї відповіді.
Дубу

Так. Я це знаю :) Я не говорив, що це неправда чи ні. Я говорив, що це нагадувало мені те, що деякі люди кажуть, але неправильно сказати. Отже, зробіть сміливою цю частину.
Прифтан

2

Можна відключити вхід через root через ssh протягом десятиліть. Спосіб Ubuntu вимкнути кореневий рахунок і змусити людей судо все - це не що інше, як хитрість. Просто "sudo -s" і у вас є коренева оболонка. Вимкнути вхід у систему через ssh та залишити його там


8
... на цій замітці - чудова практика - лише для ключів для будь-яких sh логінів, а не лише для кореневого акаунта.
rackandboneman

Так. Я це зазначив у коментарі лише кілька хвилин тому. Ото, що має найменший привілей, краще за все, тому піднімайте лише тоді, коли вам потрібно, і це стосується того, чи ви ввійшли через ssh чи локально. І те, що говорить @rackandboneman, звичайно, занадто правильне, хоча для мене я відключаю віддалений root повну зупинку навіть за допомогою клавіш ssh незалежно від системи.
Прифтан

0

Залежно від конфігурації, sudo <game ending command>не обов’язково працювати. Звичайно, якщо в sudoersконфігурації звучить "user ALL = (ALL) ALL", sudoдодатковий захист не надасть. Однак ви можете вказати список привілейованих команд, які потрібно часто запускати, як, наприклад, встановлення нових пакетів, і залишати такі небезпечні команди, як rm.

Таким чином ви можете запускати всі команди, якщо ви входите в систему як root, але оскільки вам це знадобиться лише час від часу, ризик запуску <game ending command>істотно зменшиться.


1
І конкретні аргументи до команд теж.
Прифтан

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

0

Це судо дозволяє дозволити лише певні команди - не єдина перевага судо над су.

У більшості магазинів це навіть не найважливіша вигода.

З судо ви знаєте, хто виконував певну команду.

Тепер, можливо, це для вас не має значення. Наприклад, ви можете бути єдиним користувачем вашого комп’ютера. Якщо так, то, можливо, судо не краще, ніж су.

Але багато хостів мають більше одного адміністратора.

Тоді судо стає дуже корисним, тому що якщо хтось робить не так, судо дає вам знати, хто це зробив.

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

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

Судо не ідеально.

Якщо двоє людей одночасно "судо ш", то віднести команди до тих чи інших може бути важко.

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

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

Але це дає вам набагато кращі шанси запобігти рецидиву.


1. Тільки якщо ви знайдете час, щоб правильно його налаштувати. Що система Ubuntu за замовчуванням не робить (і не може зробити). 2. Тільки якщо користувач не має можливості редагувати журнали після факту, що він може, якщо тільки команди, які вони можуть запускати, обмежені. (Якого немає у випадку використання Ubuntu за замовчуванням)
ilkkachu

@ilkkachu, хоча у вас є хороші моменти, ваш аргумент тут не має сенсу. Справа не в налаштуваннях за замовчуванням, справа в тому, що можна настроїти і налагодити sudo. Ви взагалі не можете налаштувати su, щоб діяти цими способами. su все чи ні, немає ніякого способу обмеження команд, і справа в тому, що sudo забезпечує чудовий журнал. Ні su, ні sudo не пропонують жодної безпеки проти того, що зломщик може чи не може зробити на компрометованій системі, і ніхто таким чином не тримав судо. Журнали sudo мають велике значення для звичайних щоденних операцій.
Пантера

@Panther, ну а в заголовку питання написано "... якщо користувачеві надано доступ до всіх команд?" тому я припускав, що вони мають на увазі звичайну конфігурацію Ubuntu за замовчуванням, де sudoвсе дозволяє. Звичайно, ви можете налаштувати його для обмеження команд, яким користувач може запускати, але я не думаю, що це так у запитанні, як задається.
ilkkachu

Відповідь розширений.
Бен Авелінг

@ilkkachu - перечитайте мою відповідь "Особисто я не обов'язково вважаю це безпечнішим. Більшість переваг (судо) є на багатокористувацькій системі. Для єдиної користувацької системи це, ймовірно, миття". Потім я пояснив інші переваги sudo, одна з яких полягає в тому, що він налаштовується.
Пантера
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.