Вопрос: Linux. Есть ли способ предотвратить / защитить файл от удаления даже root?


У меня есть очень важный файл, который использует приложение на моем рабочем месте, мне нужно убедиться, что он не удаляет все, как я могу это сделать?


86
2017-12-02 16:02


Источник


Сделайте резервную копию, чтобы вы могли ее восстановить ... Кроме этого, chattr +i может помочь, но сделает файл доступным только для чтения (и его можно переопределить chattr -i), также вы можете попытаться защитить его с помощью SELInux и т. д. - Sven♦
Может ли root создать процесс, который даже root не может убить? - Mark Gabriel
@MarkGabriel Да. Взрывная бомба. :) - reirab
Бог, корень, какая разница? - Dan Neely
Администратор HW может приходить и удалять диск, уничтожать его, записывать остатки и кормить их для hoghs. Или, лучше, некоторые программисты C (++) могут вызывать некоторых носовых демонов. Независимо от того, что важно для вас, поддержите его. Дважды. - Pavel


Ответы:


Да, вы можете изменить атрибуты файла только на чтение.

Команда:

chattr +i filename

И отключить его:

chattr -i filename

Из man chattr:

Файл с i атрибут не может быть изменен: его нельзя удалить или переименовать, никакая ссылка не может быть создана для этого файла, и никакие данные не могут быть записаны в файл. Только суперпользователь или процесс, обладающий CAP_LINUX_IMMUTABLE возможность может установить или очистить этот атрибут.


127
2017-12-02 16:04



Для заинтересованного эквивалент bsd chflags schg - Andrew Domaszek
Обратите внимание, что пользователь с правами root может отключить этот флаг, а затем удалить файл. Это вряд ли произойдет случайно, но оно не противится намеренному удалению. - Grant
@Grant, если Уровень защиты устанавливается достаточно высоко. Процесс загрузки устанавливает безопасный уровень до 2, прежде чем сеть будет включена, поэтому для сброса флага требуется доступ к локальной машине (но это означает, что файлы, используемые в процессе загрузки до этого времени, также должны быть неизменными). - Simon Richter
@Grant. Если кто-то хочет довести это до крайности, вы не можете предотвратить удаление раздела или диск помещается в печь или распад протонов через 10-30 лет ... - Hagen von Eitzen
@Itai Ganot man Мне жаль, что я не прочитал его 4 дня назад. Я был на экзамене, который я взял = / - vfbsilva


Запишите его на компакт-диск. Поместите компакт-диск в дисковод для компакт-дисков и откройте его.


80
2017-12-03 15:18



+1 для мышления из коробки. И, afaik, он также использовался до этого в некоторых случаях (черный ящик cdrom с компакт-диском в нем отправлен в пункт назначения). В любом случае может быть неуместным, если кто-то может отключить диск. - Alex Mazzariol
ПОЦЕЛУЙ. Я люблю это! +1 - MonkeyZeus
Я думаю, что это правильный ответ на этот вопрос. Изменение атрибута файла (chattr -i) не может предотвратить вредоносные действия. - Bruno von Paris
В этот день полноразмерная SD-карта на встроенном кард-ридере может быть лучшим решением - более низкое энергопотребление, быстрый доступ во многих случаях и более долговечный при использовании без записи. - Chris H
@ jpmc26, следовательно, привод CD-ROM. Это только чтение / только. - Thorbjørn Ravn Andersen


  1. Создайте образ файловой системы.
  2. Установите изображение.
  3. Скопируйте файл на смонтированное изображение.
  4. Отключите изображение и перемонтируйте его как только для чтения.
  5. Теперь вы не можете удалить его.

Пример:

# dd if=/dev/zero of=readonly.img bs=1024 count=1024
# mkfs.ext2 readonly.img
# mkdir readonlyfolder
# mount readonly.img readonlyfolder/
# echo "can't delete this" > readonlyfolder/permanent.txt
# umount readonlyfolder
# mount -o ro readonly.img readonlyfolder
# cat readonlyfolder/permanent.txt 
can't delete this
# rm readonlyfolder/permanent.txt 
rm: cannot remove `readonlyfolder/permanent.txt': Read-only file system

28
2017-12-03 20:33



mount -o remount,rw readonlyfolder/ && rm readonlyfolder/permanent.txt - Kaz Wolfe
Принимая это немного дальше, вы можете использовать squashfs или cramfs которые сжаты и доступны только для чтения. Для создания файловой системы нужен специальный инструмент. - Zan Lynx


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

Таким образом, даже если им удастся переопределить защиту chattr, данные останутся, и вы сможете легко восстановить их там, где ваше приложение ищет его.


6
2017-12-03 05:15



Жесткие ссылки не будут защищать содержимое файла. - 200_success
Однако они будут обеспечивать дополнительную защиту от DELETION, что было исходным вопросом. - barbecue
@barbecue Если файл отсоединен от имени, которое приложение ищет в нем, не имеет значения, что содержимое файла существует под каким-то другим именем. Для того, чтобы найти файл с ожидаемым именем, файл все еще был удален. - Michael Kjörling


Linux имеет так называемые связать монтаж вариант, который является довольно мощной и полезной функцией знать:

%  cd $TMP && mkdir usebindmountluke && cd usebindmountluke
%  echo usebindmountluke > preciousfile
%  sudo mount -B preciousfile preciousfile
%  sudo mount -oremount,ro preciousfile
%  echo sowhat > preciousfile
zsh: read-only file system: preciousfile
%  rm preciousfile
rm: cannot remove ‘preciousfile’: Read-only file system

- то, что делается здесь, - это файл привязки-привязки к самому себе (да, вы можете это сделать в Linux), затем он снова монтируется в режиме R / O. Конечно, это можно сделать и в каталоге.


6
2017-12-06 23:40





Другие ответили на ваш вопрос, как вы его просили. Как пояснил @Sven в комментарии, общее решение вопроса: «Как я могу убедиться, что я никогда не теряю файл?» заключается в создании резервной копии файла. Сделайте копию файла и сохраните его в нескольких местах. Кроме того, если файл чрезвычайно важен, и у вашей компании есть политика для резервного копирования важных данных с помощью службы резервного копирования, вы можете посмотреть, включил ли этот файл в службу.


5
2017-12-03 07:02



Ну, конечно, файл постоянно подкрепляется, мне просто нужен еще один уровень защиты от пользователей, которые иногда работают на ящике с правами пользователя root.


В комментарии к ответ Кевина, Джерри упоминает:

Ну, конечно, файл постоянно подкрепляется, мне просто нужен еще один уровень защиты от пользователей, которые иногда работают на ящике с правами пользователя root. -

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

Все предложения по использованию устройства только для чтения имеют одинаковую проблему - это делает PITA для вас, чтобы сделать законные изменения, когда вам нужно. В случае блокируемого накопителя, такого как SD-карта, вы сталкиваетесь с проблемой, что вы внезапно уязвимы, когда вы ее разблокируете, чтобы внести изменения.

Вместо этого я бы рекомендовал настроить другой компьютер в качестве сервера NFS и обмен файлами с важными файлами на машине (машинах), на которых установлены пользователи. Поделитесь монтированием как доступным только для чтения, чтобы машины с пользователями, которых вы не доверяете, не могут вносить никаких изменений. Когда вам нужно законно вносить изменения, вы можете подключиться к серверу NFS и внести туда свои изменения.

Мы используем это для наших веб-серверов, так что успешный эксплойт против веб-сервера не сможет вставлять или изменять какие-либо файлы, которые сервер будет обслуживать, или изменить конфигурацию.

Обратите внимание, что это может быть исключено, так как все связанные с монтированием точки могут быть следующими:

  • Сделайте копию защищенного каталога
  • Размонтировать каталог
  • Переместите копию вместо монтирования или добавьте символическую ссылку, если у этого крепления недостаточно места.

3
2017-12-07 13:04



Почему это «действительно, действительно плохая идея» регулярно создавать важные файлы, а также прилагать усилия для защиты оригинала от случайного удаления? В исходном вопросе OP и из комментария OP к ответу, на который вы ссылались, ясно, что беспокойство - это не злонамеренная деятельность, а случайная / некомпетентная деятельность. - Craig
@Craig: неплохо иметь много пользователей с правами root, особенно если им не доверяют, чтобы не испортить критические файлы. - Joe H.
Ах ... ну, конечно. :-) Но это не было сутью вопроса ОФ. ОП утверждал, что там находятся пользователи с правами root, которые должны быть защищены от случайного удаления файла. - Craig
@Craig: это не может быть проблемой, но это является суть проблемы (проблема XY?) ... но я понятия не имею, что они делают как root, поэтому, если они могут использовать setuid и / или ограниченные привилегии sudo. И вы должны перечитать вопрос, поскольку Джерри не упоминает о том, что он только пытается защитить от непреднамеренного удаления («я должен убедиться, что это не удаляет вообще»), и он только дал одно наблюдение, что я см. (что вызвало мой ответ). - Joe H.
См. Ответ OP на этот ответ - Craig


В Linux неизменный флаг поддерживается только для некоторых типов файловой системы (большинство из них ext4, xfs, btrfs...)

В файловых системах, где он не поддерживается, другой вариант заключается в том, чтобы привязать файл к себе в режиме только для чтения. Это нужно сделать в два этапа:

mount --bind file file
mount -o remount,bind,ro file

Это нужно делать при каждой загрузке, например, через /etc/fstab,


3
2017-12-08 16:32



Я надеюсь, что кто-нибудь umount файл, чтобы снова получить разрешения на запись - whoan


Почему бы не создать образ ISO 9660, который доступен только для чтения по дизайну?

Установите образ ISO, и он будет выглядеть как CD-ROM, но с производительностью жесткого диска, а файлы на смонтированном изображении будут столь же безопасными, как удаление файлов на физическом компакт-диске.

Идея записать чувствительный файл на компакт-диск и запустить его с компакт-диска интересна, если предположить, что установка неизменяемого бита в файле не считается достаточной.

Есть потенциальные негативные проблемы с запуском его с физического компакт-диска, включая производительность (приводы CD-ROM намного, намного медленнее, чем жесткие диски или SSD). Существует вероятность того, что компакт-диск будет удален человеком с хорошим смыслом и заменен другим диском, к которому им нужен доступ. Вероятность того, что вредоносная сторона просто вынимает диск и бросает его в микроволновую печь (или мусор), таким образом, «удаляет» ваш файл. Существует неудобство наличия специального аппаратного CD-ROM-диска только для этого одного файла и других факторов.

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

Кажется, что выполнение файла с установленного образа ISO удовлетворяет этому требованию.


2
2017-12-06 23:03



Корень все еще может удалить файл, манипулируя изображением напрямую. Это обычный файл, который, как оказалось, монтируется. - Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Как так? ISO 9660 по дизайну является неизменным. Стороне, совершившей это изменение, придется удалить и заменить весь ISO-файл. Не то, чтобы они не могли этого сделать. Но они не могли войти и хирургически удалить один файл без огромных знаний, даже если и тогда. Было бы намного проще удалить физический CD-ROM с диска и перебросить его в корзину. ;-) - Craig
Не нужно быть сложным - просто перезапишите файл изображения нулями. - Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Я достаточно уступлю этому вопросу. Предостережение состоит в том, что для этого потребуется преднамеренно демонтировать изображение и перезаписать его. Тщательный shred это в этот момент. Но, если вы не отказываетесь от физического доступа к машине, все равно кажется, что просто вытащить физический компакт-диск из накопителя и выбросить его в корзину, а не демонтировать и перезаписать ISO-файл, хотя это и легко. И ОП заявила, что важный файл подкрепляется на регулярной основе, поэтому это всего лишь дополнительная мера против случайного ущерба, а не от вредоносного вреда. - Craig
Я указал, как изменить образ ISO9660, даже если он должен быть неизменным. Я хочу сказать, что если бит вообще доступен для записи, root может его написать. - Thorbjørn Ravn Andersen