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

Розумієте, я хотів би зберегти всі дії та майже всі існуючі привілеї кореневих користувачів так, як вони є зараз.

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

Одна з переваг цього дозволить мені запобігти встановленню певних небажаних файлів під час оновлень. Це лише приклад однієї можливої ​​переваги.

Оскільки оновлення apt-get запускаються під коренем або з привілеями sudo, apt-get має можливість замінювати певні непотрібні файли під час оновлень.

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

Крім того, я не можу не нагадати про рядок, про який було сказано в інтерв'ю одному з творців Ubuntu, коли хлопець сказав щось про те, як користувачі краще довіряють "нам" (маючи на увазі розробників Ubuntu) ", ​​оскільки у нас є root ", яка була посиланням на те, як виконуються оновлення системи з дозволом root.

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

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

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

Примітка. Хоча я вважаю, що прийнята відповідь найбільше відповідає критеріям, мені дуже подобається відповідь від @CR. також.

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

Крім того, я не намагаюся тут вибрати Ubuntu; Я б не використовував це як основний дистриб'ютор, якби я відчував це негативно.

Потрібного користувача називають LSM: Linux модулем захисту. Найвідоміші - SELinux та AppArmor.

Цим ви можете запобігти певним файлам файлів (та їх дочірнім процесам) робити певні речі (навіть якщо їх UID є root). Але ви можете дозволити ці операції gettyі дочірнім процесам, щоб ви могли це робити вручну.

Ви нерозумієте поняття rootкористувача.

Простий англійською мовою rootзнаходиться на «верхівці дерева».

Що робити, якщо ви одного дня вирішите мати "супер супер користувача", а потім наступного місяця "супер супер користувача" (!). Наскільки далеко "дерево" ви хотіли б зайти? Як би ви змінили всі дозволи та ієрархію, щоб це працювало? Хто завжди на вершині? Хтось повинен бути на вершині, і це root. Кінець історії.

Наведені тут рішення - включаючи AppArmor та SELinux - насправді цього не змінюють. Вони просто дозволяють тонший контроль зерна за rootдозволами та процесами.

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

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

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

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

chattr +i <file>

Навіть root не зможе зробити їм що-небудь, якщо прапор не буде знято. Також можна використовувати систему контейнерів / простору імен для запобігання доступу до коренів, але це здається зайвим для того, що вам потрібно.

• Замість того, щоб мати супер-суперкористувача, ви можете обмежити root. див. Які різні способи встановлення дозволів на файли тощо на gnu / linux

• Є також AppArmor та SELinux.

• І / або конфігуруйте sudoтак, щоб не надавати повних привілеїв root. Ви можете налаштувати його так, щоб користувач міг виконувати лише попередньо узгоджені команди з попередньо узгодженими аргументами.

• Ви також можете використовувати віртуалізацію для обмеження root:

  • групи, простори імен, chroot тощо (докер робить це)
  • Ксен
  • Virtualbox

• Дивіться також etckeeper: редакція цього інструменту керує /etcкаталогом та синхронізується з apt. За замовчуванням він не захищений, шкідливий інсталятор може його саботажу, але ви також можете змусити його перенести зміни до сховища резервного копіювання, захищеного стіною.

• Використання контролю версій в цілому, із сховищем резервного копіювання, захищеним від стін. Це допомагає при випадковій, навмисній корупції та несправності обладнання.

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

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

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

Щоб обмежити програми та користувачів, ви можете написати AppArmor або політику SELinux. Така політика, яка підтримується більше, залежить від вашого розповсюдження: на базі Debian є краща підтримка AppArmor, тоді як дистрибутиви на базі Fedora / RHEL включають SELinux за замовчуванням.

І AppArmor, і SELinux працюють над політиками білого списку , які містять правила, які дозволяють (або відмовляти) певні дії. Політика застосовується до процесу в exec , так само користувачі можуть бути обмежені, коли політика застосовується до їх процесів під час входу. Добре продуманої політики не можна обійти (якщо помилки ядра не враховуються). Обмежений процес, що працює як root (uid 0), обмежений налаштованою політикою і не може його змінити, якщо прямо не дозволено в політиці.

Мова політики AppArmor визначає правило заперечення , яке можна використовувати для створення політики чорного списку . Місце хороше , щоб почати з AppArmor це AppArmor сторінки людини , вики і шукає існуючу конфігурацію на вашому дистрибутиві в /etc/apparmor.d/.

Багато матеріалів для адміністрування та розробки SELinux надаються у вікі SELinux . Довідкова політика SELinux розміщується на github.

Я не можу повірити, що ніхто не згадав про влучне закріплення ...

Пару років тому Microsoft випустила патч, який зламав машини Windows 10 від спілкування з нашими старими контролерами домену Samba NT4. Коли проблему було знайдено, ми прикрепили пакет Samba, щоб залишитися в поточній версії, і aptвсе ще функціонували правильно.

Повний посібник Debian добре пояснює процес:

У /etc/apt/preferences(або новий файл внизу /etc/apt/preferences.d/) додайте текст, щоб вказати пакет та версію:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

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

ПРИМІТКА. Ця відповідь передбачає, що у вас проблема XY

Насправді це досить просто.

Корінь - ваш "супер супер користувач"

Створіть обліковий запис під назвою "адміністратор" і дайте йому всі права доступу root, крім тих, які ви не хочете.

Потім створіть користувача під назвою bob, і нехай він "стає адміністратором". Використовуючи su або навіть sudo.

Тепер у вас є звичайний користувач (bob), супер користувач, який може робити адміністратор (адміністратор) та супер супер користувач (root).

Якщо ви хочете змінити ім'я "корінь" на щось інше, ви навіть можете це зробити. Технічно має значення лише ідентифікатор користувача (0).

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

Справжнє питання, яке ви хочете задати:

Чи є спосіб запобігти установці APT певних файлів?

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

Що стосується цього питання, я не впевнений на 100%, але я знаю, що ряд інших менеджерів пакетів мають можливість запобігти встановленню конкретних файлів (наприклад, система Portage Gentoo має опцію INSTALL_MASK=, яка фактично приймає оболонку -стилі шаблони речей, які не встановлювати). Я б більше хотів зробити ставку на те, що такий варіант існує для APT (або, можливо, і самого dpkg).

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

Робота з встановленого приводу

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

Нехай система X є вашою робочою системою, а система Y іншою системою, якою ви керуєте

1. Змонтуйте каталог з Y як привід X
2. Налаштуйте права таким чином, щоб кореневий користувач X мав права на все на цьому встановленому диску, за кількома винятками

Тепер у вас є "робочий корінь", який може робити майже все, і у вас є "суперкорень", фактичний кореневий обліковий запис системи Y, який справді може зробити все.

Ви можете запустити подібний гіпервізор типу 1 гіперсенсор Xen, і мати хостинг звичайної ОС як віртуалізований гість. Гіпервізор контролює віртуальну гостьову ОС на рівні "глибшому", ніж кореневий, оскільки він має контроль над (віртуальним) обладнанням, на якому працює гостьова ОС.

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

Моє відчуття, що такий підхід, мабуть, є надмірним

Подивіться на контрольних групах і просторах імен Linux в якості альтернативного способу досягнення цього типу мети, а також інструментів , заснований на них , як Докер і LXD .

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

НЕУСТАНОВА sudo

Як про видалення sudoта лінк /bin/suдо /bin/false? З'єднайте це, переконавшись, що rootне можете увійти через систему, sshі ви заблокували систему.

Це робить rootкористувача Super * Super і всі інші підпорядковані цьому.

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