Як я можу встановити пароль для команди 'rm'?


29

Мої друзі продовжують видаляти мої файли за допомогою терміналу. Тому, будь ласка, допоможіть мені, пояснивши, як зробити пароль для rmкоманди.


50
Ви хочете захистити паролем обліковий запис користувача, щоб ті "друзі" не мали доступу до нього в першу чергу.
Андреа Лацаротто

14
Справді слід спробувати дізнатися, як працює система та використовувати її функціональність.
AlexP

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

4
Також пам’ятайте про unlinkкоманду. Також про mvкоманду, тому що ви можете ефективно перезаписати файли за допомогою неї. Також ...
Кос

17
З такими друзями, яким потрібні вороги?
kasperd

Відповіді:


46

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

(Інший варіант - це індивідуальні облікові записи користувачів для кожного користувача, а потім Списки контролю доступу, як це детально описано в іншій відповіді , опублікованій Videonauth )

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


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


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

Ось як би це зробити:

Скажімо, мене звуть "Foo", і я хочу, щоб друг "Bar", друг, використовував мою систему, але не мав доступу до моїх файлів. Перший крок - заборонити доступ будь-кому, крім мене, до мого домашнього каталогу. Це дозволяє дозволити іншим користувачам не видаляти ваші файли, а також запобігти переслідуванню інших користувачів у вашому домашньому каталозі та перегляді, які типи матеріалів у вашому домашньому каталозі:

chmod 750 /home/Foo

Другий крок - створити обліковий запис користувача для "Бар" (НЕ вводити те, що в дужках нижче, це лише з інформацією). Таким чином, ми можемо переконатися, що він має свій окремий набір прав доступу:

sudo adduser --create-home --user-group --shell /bin/bash Bar
sudo passwd Bar
(set a temporary password - you will not see characters as you type though)

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

sudo chmod 750 /home/Bar

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


ВЖЕ ПАМ’ЯТАЙТЕ ЦЕ: Надаючи комусь фізичний доступ до машини чи доступ взагалі, ви збираєтесь наражати свої файли та дані на небезпеку. Це загальновизнаний факт у світі ІТ-безпеки і той факт, який продовжує діяти. Надання вашим друзям доступу до вашого комп’ютера завжди піддаватиме вашим даним ризик, тому або надайте їм свою власну систему, щоб зіпсуватись, або просто не надайте їм доступ до вашої машини.


Просто примітка про шифрування диска

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

  1. Якщо система увімкнена, диск уже розшифрований, тому ви ризикуєте.
  2. Деякі системи порушили підходи до шифрування диска. Наприклад, деякі системи Acer використовують ваш пароль лише для авторизації шифрування / розшифровки та використання жорстко закодованих паролів або використання слабкого шифрування, яке легко зламається.
  3. Завжди є методи, щоб зламати «клавіші» або спробувати витягнути їх з пам’яті відразу після вимкнення системи, але до того, як дані оперативної пам’яті «пропали» або погіршилися. (Я не буду вдаватися в глибину на них, але ці ризики роблять існують).
  4. Фізичний доступ до машини, незалежно від того, зашифрована вона чи ні, завжди буде ставити під загрозу ваші дані. Не надайте фізичний доступ (або віддалений доступ до мережі) людям, яким ви не хочете потенційно надати повний доступ до вашої системи.

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

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

Однак, якщо ваша система не зашифрована, цей розділ не має для вас релевантності.


Мій ноутбук має зашифрований жорсткий диск. Дозволити доступ до інших людей все ще є ризиком?
Тім

2
@Tim Так, якщо система включена та розшифрована. І навіть коли він вимкнений, все-таки можливо за допомогою потрібної технології, часу та відданості знайти ключі розшифровки, які потенційно все ще зберігаються в оперативній пам’яті. Шифрування диска не є 100-відсотковим захистом - є способи його вирішення, це більше питання "Чи готовий поганий хлопець реально вкласти в нього стільки часу і сил". І судячи з питання ОП, їх система вмикається і не шифрується (повністю або частково), тому ризик видалення існує.
Thomas Ward

3
@Tim Щоб додати відповідь Томаса, деякі ноутбуки порушили реалізацію шифрування диска (якщо ви покладаєтесь на апаратне FDE). Ноутбуки AFAIR Acer насправді не використовують ваш пароль для шифрування, вони використовують його лише для авторизації шифрування / розшифрування за допомогою жорсткого коду.
gronostaj

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

1
@LightnessRacesinOrbit apt-getпрацюєdpkg , яка запускає скрипти , які часто використовують rm. У моєму вікні Xenial cd /var/lib/dpkg/info; grep -P '\brm\b' *instвиводиться 344 рядки , з яких 333 виглядають як реальні способи використання rmкоманди - лише в сценаріях встановлення . grep -P '\brm\b' *rmпоказує ще більше у скриптах для видалення (для видалення конфігураційних файлів, а не пакунків).
Елія Каган

19

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

Вам потрібно контролювати доступ чи просто запобігати чесним помилкам?

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

  1. Вони могли робити це спеціально. У цьому випадку ваші друзі навмисно видаляють ваші файли, і ви навіть не можете довіряти їм, щоб спробувати виконати ваші побажання щодо того, як вони поводяться з вашими даними під час використання вашого комп'ютера. Єдине рішення цієї проблеми - використання фактично ефективного заходу безпеки , як детально пояснив Томас Уорд . Найчастіше найкращий такий захід - це утримати їх від використання комп'ютера. Але змушення їх використовувати власні облікові записи користувачів може забезпечити певний захист.

  2. Вони могли це зробити помилково. У цьому випадку ваші друзі надзвичайно схильні до нещасних випадків, і вони продовжують виконувати rmкоманди, які б хотіли, щоб їх не було. Вони хочуть з повагою ставитися до вас і до ваших даних, але насправді погано роблять це на практиці, оскільки вони продовжують виконувати неправильну команду, видаляючи неправильний файл ... або щось подібне. Хоча було б добре повірити, що саме це і відбувається, я застерігаю вас від того, щоб припустити, що люди, які продовжують видаляти ваші дані після того, як ви сказали їм припинити, діють без недоброї волі.

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

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

Я рекомендую вам запитати себе: "Чи в основному моя ситуація така, як ніби я, а не інші люди, які користуються моїм комп'ютером, використовували rmнеправильно?"

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

  • Освіта. Ваші друзі повинні знати, що вони роблять, і як цього уникнути.
  • Зміни інтерфейсу. Не позбавляючи фактичної можливості видалення файлів (для чого потрібні окремі облікові записи користувачів), ви можете ускладнити випадкове видалення файлів, зробивши так, що просто запущений сам по собі, без будь-яких подальших дій, не буде видалено негайно . Відповідь Відеонаута дає один підхід до цього. У цій відповіді я представляю іншу.rm filefile

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

Створення rmпідказки перед видаленням може допомогти запобігти деякі помилки.

Для того, щоб допомогти людям уникнути випадкового видалення файлів з rm, ви можете зробити оболонки псевдонім , який на самому ділі працює . Передача прапора викликає спонукання користувача до видалення кожного файлу (див. ).rmrm -i-irmman rm

Ви можете зробити це (для свого облікового запису користувача), додавши alias rm='rm -i'у свій файл .bash_aliasesчи .bashrcфайл. Дивіться це питання і що один для деталей. Це почне діяти для ваших нещодавно відкритих башмаків.

Це не забезпечує фактичної безпеки і не є надійною у запобіганні помилок, оскільки:

  • Вони можуть вибрати можливість продовжити видалення, коли з'явиться запит.
  • Вони можуть обходити псевдонім багатьма способами, в тому числі, запускаючи /bin/rmабо скасовуючи його ( unalias rm).
  • Є багато ситуацій, коли розширення псевдоніму не відбувається , і в цих ситуаціях rmне буде запущено -i.
  • Вони все ще можуть видаляти файли, використовуючи будь-яку техніку, для цього не потрібно rm(як це стосується підходу Videonauth - див. Нижче).
  • Вони все ще можуть пошкоджувати дані, не видаляючи файлів, наприклад, перезаписуючи їх чи іншим чином змінюючи їх вміст (як це стосується підходу Videonauth).

Але якщо вам не потрібна реальна безпека (див. Вище), то це може бути шлях. У порівнянні з підходом запобігання друзям використовувати надану системою rmкоманду:

  • Дозвіл rmна rm -iменш ефективний для запобігання помилок - поки вони не перейдуть до використання іншої техніки для видалення файлів. У цей момент утримання їх від використання rmбуде абсолютно неефективним, навіть якщо вони не намагаються зробити щось не так, оскільки, імовірно, вони будуть використовувати unlink(або будь-яку з безлічі інших команд, що видаляють файл) з однаковою бездумністю.

  • З іншого боку, оскільки розширення псевдоніму відбувається лише в деяких ситуаціях - грубо кажучи, звичайне інтерактивне використання оболонки - ваші друзі можуть подумати, що їм буде запропоновано, коли вони насправді не підкажуть (тому що команда в сценарій, наприклад, або виданий з іншої оболонки). У шляху Відеонаута немає цієї проблеми, що є об'єктивною перевагою цього методу над alias rm='rm -i'.

  • Коли сценарій працює, якщо він не написаний навмисно для використання псевдонімів, ваші псевдоніми в ньому не розширюються. Це означає, що злучення rmз rm -iвеликою ймовірністю нічого не порушить. Це об'єктивна перевага alias rm='rm -i'.

rm не може зробити нічого, що не могла зробити інша абсолютно звичайна програма.

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

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

/usr/bin/sudoі /usr/bin/passwdможе це зробити, тому що у них встановлено встановлений біт , як показано, sщо з’являється у крайньому лівому стовпчику при запуску ls -l:

ek@Io:~$ type -a sudo passwd rm
sudo is /usr/bin/sudo
passwd is /usr/bin/passwd
rm is /bin/rm
ek@Io:~$ ls -l /usr/bin/sudo /usr/bin/passwd /bin/rm
-rwxr-xr-x 1 root root  60272 Feb 18  2016 /bin/rm
-rwsr-xr-x 1 root root  54256 Mar 29  2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 136808 Aug 17 09:20 /usr/bin/sudo

Зверніть увагу , що /bin/rmне має s: його права доступу -rwxr-xr-x, в той час як /usr/bin/passwdі /usr/bin/soмати -rwsr-xr-xзамість цього. Це робить так, що незалежно від того, хто працює passwdабо sudoвін фактично працює як користувач root, оскільки root є власником виконуваного файлу. (Існує також біт setgid, який при встановленні призводить до запуску виконуваних файлів із груповою ідентифікацією власника групи, а не з особою абонента.)

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

/bin/rmне працює таким чином. Це не налаштовано, тому що цього не потрібно. Дозволи в каталозііноді і дозволи на файли ) контролюють, які файли користувач може видалити, і для цього їм не потрібно ставати root. Щоб бути абсолютно зрозумілим, будь ласка, ніколи не вмикайте встановлений бітrm . Наслідки для безпеки були б згубними, оскільки тоді, незалежно від того, хто працює rm, це немов би рут керував ним! (Утиліти люблять sudoі passwdперевіряють, хто насправді працює ними, і переконайтеся, що щось дозволено, перш ніж це робити; rmчи не робить цього.)

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

Видалення файлів без rm

Очевидний спосіб видалити файл без rmUbuntu - перейти до його місця в браузері графічних файлів (Nautilus, якщо ви використовуєте Unity або GNOME Shell) та видалити файл. Існують також численні команди, за допомогою яких можна видалити файл із терміналу, не використовуючи жодного разу rm.

Наприклад, щоб видалити файл, викликаний foo.txtу поточному каталозі, цього досягнуть наступні команди, які працюють поза вікном Ubuntu та не потребують доступу до нього rm. (Просто для впевненості , після вилучення я протестував їх на мінімальній системі 16.04, встановленій лише стандартними системними утилітами /bin/rm.)

  • unlink foo.txt
  • busybox rm foo.txt
  • perl -e 'unlink("foo.txt")'
  • python3 -c 'import os; os.remove("foo.txt")'( pythonзамість python3старих версій)

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


2
Для фактичного використання, я як GNU rm«s -Iваріант. Це вимагає лише для видалення 4 або більше файлів або для рекурсивного видалення. Таким чином, ви не звикли завжди використовувати -f, \rmщоб уникнути розширення псевдоніму або введення тексту, yне читаючи. Але це все одно позбавить вас від поганих помилок, де ви повернетесь до того, як ви мали намір, або ваш глобус відповідатиме багатьом файлам.
Пітер Кордес

2
Ще один цікавий спосіб від’єднати файли:, mv foo.txt /tmp/.goneпотім перезавантажити, відкинувши tmpfs, що створював резервну копію /tmp. Або просто використати mvдля перейменування декількох файлів на одне ім’я, так що залишився лише останній. Або просто приховати файли, перейменувавши їх незрозумілими іменами. Як зазначається в першій частині цієї відповіді, якщо ви намагаєтесь захиститись від злоби, а не некомпетентності, вам потрібно просто заблокувати людей зі свого облікового запису.
Пітер Кордес

16

Ви можете змінити дозволи для /bin/rmкоманди за допомогою наступного рядка, що не дозволить виконувати її без доступу sudo:

sudo chmod 750 /bin/rm

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

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

sudo chmod 750 /bin/rmdir

Нагадайте, що ви також можете використовувати ці команди лише з правами sudo.

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


Як зазначав @muru, вищесказане - дуже грубе рішення і може навіть порушити системні сервіси, які не працюють на кореневому рахунку. Тому я додаю сюди ще один варіант, використовуючи ACL (списки контролю доступу), щоб зробити те саме, і, ймовірно, набагато безпечніше ( добре читати, а ви можете пропустити включну частину, тому що ACL зазвичай встановлено в системах Ubuntu сьогодні):

Так що робити те саме, що було вище для користувачів, яких ви хочете заблокувати

sudo setfacl -m u:<user-name>:- /bin/rm /bin/rmdir

Просто замініть <user-name>фактичні імена користувачів, які ви хочете запобігти використанню файлів.

Як і у випадку chmod, використовуючи setfacl -mдля запобігання запуску конкретних користувачів rmі rmdirзастосовується лише до цих команд, що надаються системою. Це не заважає їм видаляти ваші файли та папки в Nautilus або використовувати інші термінальні команди.

Пояснення:

  • -mпрапор означає , що для зміни файлів ACL.
  • Перша частина зміни - це uкористувач. Він може мати такі значення uдля користувача, gдля групи та oдля всіх інших
  • середня частина <user-name>може містити фактичне ім’я користувача або ім’я групи відповідно до того, що ви хочете змінити. Для встановлення загальних змін ви залишаєте це порожнім.
  • третя частина містить тип дозволів, які ви хочете встановити. Тут у прикладі ми не хочемо встановлювати жодних дозволів, тому ми -можемо також містити наступні літери rдля дозволу на читання, wдля дозволу на запис та xдля виконання.

4
Було б краще використовувати ACL, ніж видаляти дозволи на виконання для інших - будь-яка системна служба, яка не працює як root, зараз перешкоджає.
муру

2
sudo setfacl -m u:<username>:- /bin/rm /bin/rmdir, ІІРК. Ви можете протестувати ACL зgetfacl /bin/rm /bin/rmdir
муру

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

4
@DavidFoerster Так. Існує фактично необмежена кількість способів видалення файлів без rm. Рішення, яке тут надав Videonauth, є можливим способом допомогти схильним користувачам припинити видалення речей, але це не забезпечує фактичної безпеки (що може бути нормально, якщо друзі ОП навмисно не намагаються підривати бажання ОП) . Videonauth: Я пропоную відредагувати цю публікацію, щоб вона чітко пояснила, що вона фактично не заважає людям видаляти файли, оскільки для цього їм не потрібна rmкоманда. (Я утримуюсь від її редагування самостійно, якщо ви цього не хочете сказати.)
Елія Каган

1
Не забувайте, що Perl, Python та всі компілятори в системі дозволяють іншим користувачам також видаляти файли. Заборона людям видаляти файли вимагає більше, ніж просто зміна дозволів на rmкоманду.
Джонатан Леффлер

8

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

Однак ви можете використовувати псевдонім, щоб змінити спосіб поведінки команди rm. Спробуйте:

alias rm="sudo -l >/dev/null && rm"

Це робиться, коли хтось вводить команду rm, він виконує команду sudo -l. Ця команда змушує користувача ввести свій пароль. Якщо вони зрозуміли це право, він перелічує їхні привілеї (ми відкидаємо цей вихід) і виходимо зі статусом 0, якщо вони помиляються, він існує з помилкою.

Потім ми слідуємо команді sudo з "&&", яка виходить з наступної команди - у цьому випадку "rm", тільки якщо попередня команда закінчується зі статусом 0 - тобто вони отримали правильний пароль.

Щоб зробити це постійним, включіть команду псевдонім у ~/.bashrc.

Зауважте, це дуже легко перемогти (наприклад, вони можуть просто набрати /bin/rm.


5

Іноді це не наші друзі, ми самі страшні вороги

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

  • /
  • / додому
  • / бін

Редагувати: 5 березня 2017 р. - Змініть метод перевірки, чи працює у терміналі.


Створіть сценарій

Використовуйте gksu gedit /usr/local/bin/rmта копіюйте в цих рядках:

#!/bin/bash

tty -s;
if [ "0" == "$?" ]; then Terminal="Y"; else Terminal="N"; fi

if [ $Terminal == "Y" ] ; then
    # Running from terminal don't allow delete of / or /toplevel directory even if sudo
    for i in ${@:1}
    do
        # Skip options -i -r -v -d 
        if [[ ${i:0:1} != "-" ]] ; then
            # if parameter doesn't begin with '-' it's file or directory, so get real path.
            fullname=$(realpath "$i" 2>&1) # No error messages if file doens't exist
            # We must have at least two `/` in the full path
            levels=$(echo "$fullname" | tr -cd '/' | wc -c)
            if (( $levels == 1 )); then # Test for 1, will be zero when file doesn't exist.
                echo "Attempting to remove top level directory '$fullname'"
                echo "Use 'sudo /bin/rm $@' instead."
                exit 1 # error
            fi
        fi
    done
fi


if [[ $(id -u) != 0 ]]; then # Only non-root processes enter password (ie "sudo rm ..." is ok)
  if [ $Terminal == "Y" ] ; then
  # Only running from a terminal needs password (ie not cron)

    # log rm usage to /var/log/syslog
    PARENT_COMMAND="$(ps -o comm= $PPID)"   
    logger "$PARENT_COMMAND"" - rm command was used on file: ""$fullname"

    # Get password
    Password=$(zenity --password --title="Password for rm")
    encryptPassword=$(echo -n "$Password" | md5sum)

echo "md5sum: $encryptPassword" # Comment out after viewing one time and updating line below.

    if [[ "$encryptPassword" != "d2c30dc65e59558c852ea30b7338abbe  -" ]]; then
        echo "Invalid password!"
        exit 1
    fi
  fi # non-terminals can't enter password.
fi # root doesn't need to enter password.

# Call REAL rm command with parameters passed to this wrapper sript
/bin/rm "$@"

exit 0

Змініть пароль "WE2U" на все, що вам подобається, і збережіть файл.

Позначте новий rmсценарій як виконуваний

Позначити новий rmсценарій як виконуваний за допомогою:

sudo chmod +x /usr/local/bin/rm

Як це працює

rm пароль

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

Оскільки шлях /usr/local/binу списку вище, ніж називається /binнаша команда rm. Після отримання дійсного пароля він закликає /bin/rmзробити справжнє видалення.

Як зазначив Томас Уорд в іншій відповіді, якщо ви робите це, sudo apt-get install ...вам можуть попросити пароль тисячу разів. Сценарій перевіряє, чи sudoвикористовується, і не запитує пароль. Крім того, якщо rmдзвонити з програми GUI, пароль не потрібно.

Сценарій викликів loggerдля запису кожного разу rmбув викликаний вручну за допомогою терміналу. Використання команд записується до /var/log/syslog.


1
Ви можете замаскувати пароль, просто включивши в сценарій хешовану його версію, а потім, коли користувач вводить пароль, він може просто його хеш і перевірити його на жорсткому кодуванні хеша.
InitializeSahib

@InitializeSahib підтримка хешованих паролів (шифрування) додана до сценарію.
WinEunuuchs2Unix

3

Іншою альтернативою було б створити резервні копії будь-яких важливих файлів у каталозі, до якого некористувальні користувачі не мають доступу. Ви можете використовувати rsyncабо unisonсинхронізувати їх автоматично, просто переконайтеся, що принаймні одна директорія на шляху до місця резервного копіювання належить корінь та режим 700. Хоча це призведе до отримання двох копій усіх файлів. Було б безпечніше просто створити гостьового користувача для їх використання, за винятком того, що вам потрібно пам’ятати, щоб завжди блокувати або виходити з системи, перш ніж подавати їм комп'ютер або залишати його без нагляду.


3
Ви можете вказати, як уникнути поширення видалення? І в ідеалі спосіб вимкнути та ввімкнути так, щоби користувач робив щось, для чого потрібно видалити, щоб бути постійним, воно буде постійним.
ostergaard

@ajostergaard Моя думка полягала в тому, що кожного разу, коли він повертається до свого комп’ютера від своїх друзів, він вручну перевіряє, що нічого не вистачає, і відновлює все, що є. Але мій власний вподобаний інструмент - це унісон, який використовується в інтерактивному режимі gui, що дозволяє легко бачити (і реверсувати) видалення.
Випадково832

2

Не пряма відповідь на питання, яке ви шукаєте, але:

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

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

Він також має перевагу в тому, щоб зупинити "друзів" переходити до наступного кроку. Чи захочете ви також "захистити паролем" mvкоманду, якщо вони вирішать перемістити ваші файли до / dev / null, коли виявлять, що просте видалення не робить те, що вони хочуть? Коли ви в такій грі, єдиний виграшний хід - це не грати.


1

У мене є аналогічна можливість, яку я планував. На файловому сервері, якщо в основному сховищі фотографій можна записати, Somone в сім'ї (менш технічна чи випадково) може щось видалити, випадково перетягніть в gui, який переміщує каталог, або перезапись оригіналу з відредагованою версією, а не перейменуванням .

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

ZFS є рідним для FreeBSD. У Linux є btrfs, який також має знімки.


0

Дуже нерозумне вирішення дуже дурного питання.

Якщо ви не хочете chmod rm, rmdirабо mv(для mv filename /dev/null) або використання списків ACL, ви можете створити користувача манекена з паролем ніхто крім вас НЕ знає і псевдонім кожну команду sudo [user], а потім зробити псевдоніми для кожної команди , що ваші друзі не знають . Таким чином, коли ваші друзі наберуть rmсистему, вони запропонують їм ввести пароль (але, якщо ви вгадаєте, що пароль невідомий, буде записано невдалу спробу), і ви все одно можете просто набрати rmaliasабо все, що завгодно, фактично видалити файли.

Або ви просто можете створити гостьовий обліковий запис, який не має доступу до домашнього каталогу.


Це здається, що ви на правильному шляху. Вашу відповідь можна покращити, розробивши, як налаштувати псевдоніми, sudo [user]іdummy user
WinEunuuchs2Unix

0

Якщо ви хочете захистити паролем rm, рішенням буде зробити обгортку для rm, яка потребує кореневих привілеїв, і попросити пароль в іншому випадку. (ПРИМІТКА. Ця обгортка може піти, коли пакет Coreutils буде оновлено або перевстановлено.) Також врахуйте, що це забезпечує лише rm, є ще багато, багато інших способів видалення файлу.


Відкрийте термінал і станьте root. Потім запустіть, sudo mv /bin/rm /bin/rmoldщоб перемістити старий rm в інше місце.

Тепер біжи sudo nano /bin/rm щоб створити обгортку.

У Нано введіть таке:

#!/bin/bash
/bin/rmold "$@"
exit "$?"

Потім утримуйте CTRLта натисніть, Xщоб вийти. Натисніть, Yколи з'явиться запит, а потім натисніть, ENTERщоб зберегти файл.

Нарешті, нам потрібно надати цьому відповідні дозволи:

sudo chmod a+x /bin/rm

І ось ти йдеш.


1
Якщо у вас є дуже вагомі причини, змінні сценарію завжди повинні цитуватися: $@=> "$@". Ось, що ви пропонуєте, це дуже небезпечна версія оригінальної та безпечної rm: що робити, якщо є файл з назвою foo -i -r *( -iдоданий для захисту невинних користувачів)?
xhienne

Окрім- "цитування, $@як говорить @xhienne, я б закликав вас чітко попередити читачів, що це зовсім не забезпечує безпеку, оскільки є багато способів видалити файл. Одне - зателефонувати rmold, але існує безліч інших способів, про які йдеться в інших відповідях та коментарях до них. (Вже тоді це виникне проблема, яка rmбуде відчувати, що він видаляє файли як поточний користувач - він називається без sudo, а нормальний rmпрацює як абонент - але це робить як root! Якщо вони нещодавно sudoредагували, вони виграли " не помічайте, що вони можуть видаляти системні файли, навіть якщо вони знають про зміну.)
Eliah Kagan
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.