Насколько мы можем полагаться на разрешения файловой системы в вопросах безопасности?

Насколько мы можем полагаться на разрешения файловой системы в вопросах безопасности?

Мой вопрос касается разрешений файловой системы (в частности, разрешений в стиле Unix) и того, как они связаны с безопасностью.

Допустим, у меня есть доступ к компьютеру с гостевой учетной записью и пользователем по имени Боб. Я не знаю пароля Боба, но я могу использовать гостевую учетную запись. Гостевая учетная запись не имеет абсолютно никаких прав на чтение всех файлов Боба, поэтому я не могу читать ни один из файлов Боба, войдя в систему как гость.

Однако, с точки зрения настоящего «противника», у меня есть полный доступ к этому незашифрованному диску. Я мог бы создать его образ, сохранить его на потом, запустить какую-нибудь другую ОС, чтобы просто прочитать файлы Боба, игнорируя настройки разрешений файловой системы.

Отсюда я перехожу к вопросу:

  1. Настройка разрешения файловой системы на незашифрованном диске — это всего лишь флаг, верно? И единственное, что останавливает меня от чтения файлов, на которые у меня нет разрешения, — это то, что ОС скажет: «О, вы не можете это прочитать, у вас нет разрешения». Этот файл все еще находится на диске в сыром виде, и я мог бы прочитать его, просто игнорируя флаги файловой системы (например, через какую-нибудь теневую загрузочную ОС, которая просто игнорирует разрешения). Все это правильно?

Теперь предположим, что у меня нет прямого доступа к диску, и я просто подключаюсь к машине по ssh. У меня нет разрешения на чтение файлов Боба. Я ничего не могу с этим поделать, верно?

  1. Учитывая мои ограниченные права, я просто не могу получить доступ к файлам Боба, как бы я ни старался, не так ли? А что, если я использую какой-нибудь эксплойт, чтобы получить root-доступ? Могу ли я теперь обойти флаги разрешений ОС? Это когда-нибудь случается?

решение1

Более короткий ответ.

Если у вас есть физический доступ к компьютерной системе (ПК или системе хранения данных), а единственной «защитой» являются разрешения на доступ к файлам, то у вас нет 100% защиты.

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

И да,потенциальноНекоторые доказательные аспекты физического проникновения, возможно, должны быть учтены в доступе на физическом уровне; например, убедиться, что не осталось никаких отпечатков пальцев, и также разобраться с любыми «защищенными от несанкционированного доступа» печатями. Но, честно говоря, в подавляющем большинстве систем можно физически извлечь диски для физической копии данных, и конечный пользователь никогда не узнает ничего лучшего. Если у вас есть диск, у вас есть диск, а затем у вас есть данные, если они не зашифрованы.

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

Если диск не зашифрован, данные на нем — открытая книга, готовая к чтению. Эта концепция не ограничивается машинами Linux/Unix, а любой ОС где угодно; если у вас есть физический доступ к незашифрованной системе, у вас есть эта система.

Тем не менее, разрешения на доступ к файламявляютсяполезная мера безопасности для удаленных серверов всех типов.

Более развернутый ответ.

Мой вопрос касается разрешений файловой системы (в частности, разрешений в стиле Unix) и того, как они связаны с безопасностью.

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

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

Допустим, у меня есть доступ к компьютеру с гостевой учетной записью и пользователем по имени Боб. Я не знаю пароля Боба, но я могу использовать гостевую учетную запись. Гостевая учетная запись не имеет абсолютно никаких прав на чтение всех файлов Боба, поэтому я не могу читать ни один из файлов Боба, войдя в систему как гость.

Проблема здесь в контексте доступа. Если у вас естьфизический доступк компьютеру, в общем-точто-либовозможно. Но если вы подключены только через удаленное соединение — по сети какого-либо рода — то владение файловой системойопределенноэффективный метод безопасности. А в случае серверов Linux/Unix разрешения и владение являются эффективными формами безопасности для предотвращения удаленного вторжения.

Вот почему в мире Linux/Unix получение rootдоступа к удаленной системе считается таким большим призом. Получите доступ rootк удаленной системе, и тогда вы действительно сделаете что-то, что даст вам больший доступ без необходимости идти в центр обработки данных и клонировать диск.

Однако, с точки зрения настоящего «противника», у меня есть полный доступ к этому незашифрованному диску. Я мог бы создать его образ, сохранить его на потом, запустить какую-нибудь другую ОС, чтобы просто прочитать файлы Боба, игнорируя настройки разрешений файловой системы.

Да. Точно. Если у вас есть физический доступ к машине, то — как объяснялось в начале — все ставки отменены. Вы можете получить доступ к файлам и каталогам, принадлежащим другим, сделав образ диска — или даже просто просматривая исходное содержимое самого диска — с небольшими или вообще без серьезных технических усилий.

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

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

решение2

Ваши три пункта:

  1. Если вы подключаетесь по SSH как обычный пользователь, у вас нет доступа к устройству raw disk. Обычно вам нужно rootили разрешение для доступа к устройствам raw disk и logical disk.

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

  3. Физический доступ бьет root. Корень — это логический уровень. Вы можете игнорировать его с физическим доступом к диску. Это включает загрузку указанного диска в отдельной ОС, где вы являетесь root.

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

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

Связанный контент