Защита файла в Unix

Можно искать "систему неизменный" флаг. Детали могут зависеть от точно, какую операционную систему Вы выполняете, но основная идея будет тем же. Вы захотите что-то вроде этого в BSD (или OSX):

# chflags schg /path/to/file

или эквивалент в Linux:

# chattr +i /path/to/file

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

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

Что относительно того, чтобы поместить файл на файловую систему NFS только для чтения сохранен на другом сервере?

Вероятно, легче выяснить лучшее решение этой проблемы XY.

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

OpenBSD и FreeBSD имеют понятие уровня безопасности, также известного как securelevel. securelevel является целочисленным значением. Если величина отрицательна или 0, только обычные правила безопасности Unix применяются. В securelevel 1 и выше, много ограничений въезжают в место в особенности:

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

Securelevels 2 и 3 добавляет дополнительные ограничения. Важная вещь состоит в том, что невозможно уменьшить уровень безопасности без перезагрузки, даже с корневым доступом. Таким образом securelevels вводят ограничения на то, что корень может сделать, за счет создания определенных невозможных задач обслуживания (таких как восстановление или реконфигурирование RAID-массива).

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

Может быть возможно настроить что-то вроде этого с концепциями безопасности Linux (AppArmor, SELinux, …), но это, прежде всего, инструменты для установки строгих политик для процессов, которые не работают как корень. Если бы это вообще возможно, требовался бы большой уход в определении политики (даже в обычном случае, разработка полезных политик трудна).

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

• Выполните систему в виртуальной машине и храните файл на хосте.
• Храните файл в другой системе, доступной через сеть.
• Храните файл на медиа физически только для чтения.

Кажется, что единственный допустимый путь состоит в том, чтобы использовать chattr команда следующим образом:

chattr +i /var/log/file

Этот путь даже базируется, не может изменить файл, если он не удаляет i атрибут из файла.

Таким образом, это - всего один шаг к лучшей защите, я думаю.

Файл будет заморожен, или необходимо ли продолжать писать в него? В первом случае Вы могли поместить файл в носитель только для чтения: CD-ROM, флеш-накопитель с медосмотром защищает переключатель от записи, и т.д. (Который защищает целостность файла, но не препятствовал бы тому, чтобы корень размонтировал его и/или замаскировал его с фальшивкой).

Если Вы хотите продолжить писать в файл журнала, нет никакого решения, если Вы не можете найти write-once-read-many физическую среду: Если файл может быть записан в, он может быть перезаписан. (Для полноты: возможно установить атрибут "только добавления" файла с chattr или chflags, который защитит содержание файла от того, чтобы быть перезаписанным. Но не возможно заблокировать корень от сбрасывания этого атрибута.)

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

Например, можно хотеть установить a атрибут, с помощью chattr +a filename:

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

Так как это, казалось бы, было бы файлом журнала, который может быть более подходящим вариантом. Или можно использовать i атрибут:

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

Обратите внимание, что суперпользователь может очистить эти атрибуты с соответствием chattr -X команда.

Это не дает точного ответа на заданный вопрос, но альтернативное решение - разместить журнал на другом сервере / виртуальной машине, сделав его доступным только для добавления, используя chattr + a , а затем смонтировать его по сети. Это не лишено недостатков, но, на мой взгляд, это один из лучших подходов к решению этой проблемы.