Як працюють внутрішні судо?

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

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

Якщо ви подивитеся на виконуваний файл sudo:

$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun  3  2011 /usr/bin/sudo

Ви помітите, що він містить біти дозволу ---s--x--x. Їх можна розділити наступним чином:

-|--s|--x|--x
-      - first dash denotes if a directory or a file ("d" = dir, "-" = file)  
--s    - only the setuid bit is enabled for user who owns file
--x    - only the group execute bit is enabled
--x    - only the other execute bit is enabled

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

Приклад

Якщо я запускаю таку команду як saml користувача:

$ whoami
saml

$ sudo su -
[sudo] password for saml: 

Ви помітите, що виконання sudoфактично працює як root:

$ ps -eaf|grep sudo
root     20399  2353  0 05:07 pts/13   00:00:00 sudo su -

установочний механізм

Якщо вам цікаво, як працює SUID, погляньте man setuid. Ось уривок зі сторінки man, який пояснює це краще, ніж я міг:

setuid () встановлює ефективний ідентифікатор користувача процесу виклику. Якщо ефективний UID абонента є кореневим, також встановлюється справжній UID та збережений набір-ID користувача. У Linux, setuid () реалізується подібно до версії POSIX з функцією _POSIX_SAVED_IDS. Це дозволяє програмі set-user-ID (крім root) скидати всі свої привілеї користувача, виконувати деякі непривілейовані роботи, а потім знову захищати оригінальний ефективний ідентифікатор користувача в безпечний спосіб.

Якщо користувач має root або програма встановлена-user-ID-root, слід бути особливо обережним. Функція setuid () перевіряє ефективний ідентифікатор користувача абонента, і якщо він є суперпользователем, всі ідентифікатори користувачів, пов'язані з процесом, встановлюються на uid. Після цього програма не зможе відновити кореневі привілеї.

Ключова концепція тут полягає в тому, що програми мають реальний userid (UID) та ефективний (EUID). Setuid встановлює ефективний userid (EUID), коли цей біт увімкнено.

Отже, з точки зору ядра відомо, що в нашому прикладі samlвсе ще є початковим власником (UID), але EUID встановлюється тим, хто є власником виконуваного файлу.

суцільний

Я також повинен зазначити, що коли ми розбиваємо дозволи на команду sudo, друга група бітів була для групових дозволів. У групі бітів також є щось подібне до setuid під назвою set group id (ака. Setgid, SGID). Це робить те саме, що і SUID, за винятком того, що він запускає процес із груповими обліковими даними замість облікових даних власника.

Список літератури

• сторінка вікіпедії
• сторінка налаштованого чоловіка

Справжній sudoбінарний файл має встановлений корінь , і ви не можете просто створити файли, встановлені таким чином.

setuid і setgid (скорочення "встановити ідентифікатор користувача після виконання" та "встановити ідентифікатор групи при виконанні" відповідно) [1] - це прапори прав доступу Unix, які дозволяють користувачам запускати виконуваний файл з дозволами власника або групи відповідної версії, і відповідно змінити поведінку в каталогах.

Щоб відповісти на частину системних дзвінків, яку, схоже, ніхто не торкався, одним із важливих системних викликів є або setresuid (), або setresgid (). Я впевнений, що є й інші, але ці 2 виглядають досить специфічно для setuid / sudo.