Массачусетский Институт Технологий.
Курс лекций №6.858. «Безопасность компьютерных систем».
Николай Зельдович, Джеймс Микенс.
2014 год Безопасность компьютерных систем — это курс, посвященный проектированию и внедрению безопасных компьютерных систем.
Лекции охватывают модели угроз, атаки, ставящие под угрозу безопасность, а также методы обеспечения безопасности, основанные на последних научных работах.
Темы включают безопасность операционной системы (ОС), возможности, управление информационными потоками, языковую безопасность, сетевые протоколы, аппаратную безопасность и безопасность веб-приложений.
Лекция 1: «Введение: модели угроз» Часть 1 / Часть 2 / Часть 3 Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3 Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3 Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3 Что еще у нас есть в этом списке? Процессы.
Память — это то, что происходит одновременно с каким-то процессом.
Таким образом, если вы не находитесь в этом процессе, вы не сможете получить доступ к его памяти.
Виртуальная память отлично помогает нам усилить эту изоляцию.
Кроме того, механизм отладки позволяет вам «подглядывать» в память другого процесса, если у вас тот же идентификатор пользователя.
Далее у нас есть сети.
Сети в Юникс не совсем соответствуют описанной выше модели, отчасти из-за того, что операционная система была разработана первой Юникс , а затем появилась сеть, которая вскоре стала популярной.
Там немного другой набор правил.
Таким образом, операции, о которых нам действительно нужно позаботиться, — это подключение кого-либо к сети, если вы управляете сетью, или прослушивание какого-либо порта, если вы действуете в качестве сервера.
Возможно, вам потребуется читать или записывать данные по этому соединению или отправлять и получать сырой -пакеты.
Таким образом, сети в Юникс в принципе не связан с ID пользователя .
Правила таковы, что любой всегда может подключиться или открыть соединение с любой машиной или любым IP-адресом.
Если вы хотите прослушивать порт, то единственное отличие состоит в том, что большинству пользователей запрещено прослушивать порты ниже магического значения 1024. В принципе, вы можете прослушивать такие порты, но в этом случае вы должны быть специальным пользователем с именем «суперпользователь» имея идентификатор = 0 .
И вообще, в Unix есть понятие администратора, или суперпользователя, которое представлено идентификатором uid=0, что позволяет обойти практически все эти проверки, поэтому если вы работаете с root-правами, вы можете читать и писать файлы, изменить права доступа к ним.
Операционная система позволит вам это сделать, поскольку считает, что у вас должны быть все привилегии.
А вам действительно нужны такие привилегии для прослушивания портов < 1024. What do you think about such a strange restriction? Аудитория: он определяет конкретные номера портов для определенных соединений, например.
http на порту 80. Профессор: да, протокол по умолчанию HTTP использует порт 80. С другой стороны, другие сервисы могут использовать порты выше 1024, так зачем же это ограничение? В чем выгода? Аудитория: потому что вы не хотите, чтобы кто-нибудь случайно прослушал ваше HTTP .
Профессор: Да.
Я думаю, причина этого в том, что раньше на одной машине было много пользователей.
Они заходили под своими логинами, запускали свои приложения, поэтому хотелось сделать так, чтобы какой-нибудь случайный пользователь, зайдя на компьютер, не смог захватить управление работающим на нем веб-сервером.
Потому что пользователи, подключающиеся извне, не знают, кто работает на этом порту, и они просто подключаются к порту 80. Если я хочу войти на этот компьютер и запустить свой собственный веб-сервер, я просто перенесу весь трафик веб-сервера.
к этой машине.
Возможно, это не очень хороший план, но это способ сетевой подсистемы Unix предотвратить мониторинг известных служб, работающих на этих малых номерах портов, случайными пользователями.
Это и есть основание для такого ограничения.
Кроме того, с точки зрения чтения и записи данных соединения, если у вас есть дескриптор файла для определенного сокета, то Юникс позволит вам читать и записывать любые данные по этому соединению TCP или УТП .
В процессе отправки сырой -пакеты Юникс ведет себя как параноик, поэтому не позволит отправлять произвольные пакеты по сети.
Это должно быть внутри специального контекста соединения, если только у вас нет корень -права и ты можешь делать все, что хочешь.
Итак, вы можете задать один интересный вопрос: где все это ID пользователя ? Мы говорим о процессах, которые имеют ID пользователя или идентификатор группы .
Когда ты бежишь ПС на своем компьютере вы обязательно увидите ряд процессов с разными значениями жидкость .
Откуда они пришли? Нам нужен какой-то механизм для загрузки всех этих значений.
ID пользователя .
В Юникс Для этого существует несколько системных вызовов.
Итак, для загрузки этих значений идентификаторов существует функция под названием setuid (uid) , чтобы вы могли назначить номер жидкость некоторый текущий процесс этого значения.
На самом деле это опасная операция, как и все в традиции.
Юникс потому что ты можешь сделать это только в том случае, если ты идентификатор = 0 .
По крайней мере, так должно быть.
Итак, если вы являетесь пользователем root и у вас есть идентификатор = 0 , то можешь позвонить setuid (uid) и переключить пользователя на любой процесс.
Есть еще пара подобных системных вызовов для инициализации.
гид связанные с процессом: это setgid И набор групп .
Таким образом, эти системные вызовы позволяют вам настроить привилегии процесса.
Что вашим процессам предоставляются правильные разрешения при входе на компьютер.
Юникс , происходит не потому, что у тебя то же самое ИДЕНТИФИКАТОР , как процессы, потому что система еще не знает, кто вы.
Вместо этого в Юникс существует какая-то процедура входа в систему, когда протокол защищенной оболочки SSH запускает процесс для всех, кто подключается к компьютеру и пытается аутентифицировать пользователя.
Итак, первоначально процесс входа в систему начинается с идентификатор = 0 как пользователь root, а затем, когда он получает определенное имя пользователя и пароль, он сверяет их со своей собственной базой данных учетных записей.
Как правило, в Юникс эти данные хранятся в двух файлах: /etc/пароль (по историческим причинам в этом файле пароли больше не хранятся), а в файле /etc/тень , в котором хранятся пароли.
Однако в файле /etc/пароль Существует таблица, в которой каждое имя пользователя в системе отображается как целочисленное значение.
Таким образом, ваше имя пользователя сопоставляется с определенным целым числом в этом файле.
/etc/пароль , а затем процесс входа проверяет правильность вашего пароля в соответствии с этим файлом.
Если он найдет ваше целое число жидкость , то он установит функции setuid в этом смысл жидкость и запустите оболочку командой исполнительный (/bin/sh) .
Теперь вы можете взаимодействовать с оболочкой, но она работает под вашим жидкость , поэтому вы не сможете случайно повредить эту машину.
Аудитория: можно ли начать новый процесс с идентификатор = 0 если ваш жидкость на самом деле не 0? Профессор: если у вас есть root-права, вы можете ограничить себя другими жидкость , понизьте разрешения, но в любом случае вы сможете создать процесс только с таким же жидкость , Как вы.
Но бывает, что по разным причинам вы хотите повысить свои привилегии.
Допустим, вам нужно установить пакет, для чего вам потребуются привилегии.
корень .
В Юникс Есть два способа установить привилегии.
Мы уже упоминали дескриптор файла.
Поэтому, если вы действительно хотите повысить свои привилегии, вы можете поговорить с кем-нибудь, работающим под учетной записью root, и попросить его открыть для вас файл.
Или вам нужно установить какой-то новый интерфейс, тогда этот помощник откроет вам файл и вернет вам дескриптор файла с помощью передачи ФД .
Это один из способов повысить свои привилегии, но он неудобен, поскольку в некоторых случаях выполняются процессы с большим количеством привилегий.
Для этого Юникс имеет хитрый, но в то же время проблематичный механизм под названием "установка двоичных файлов" .
Этот механизм представляет собой обычные исполняемые файлы в файловой системе.
Юникс , за исключением случаев, когда при запуске вы делаете руководитель в двоичном файле setuid , Например, /бин/су на большинстве машин или судо .
В типичной системе Юникс есть куча двоичных файлов setuid .
Разница в том, что когда вы запускаете один из этих двоичных файлов, он фактически переключается.
ID пользователя процесс владельцу этого двоичного файла.
Этот механизм кажется странным, когда вы впервые его видите.
Как правило, способы его использования заключаются в том, что этот «бинарный файл», скорее всего, имеет жидкость владелец равен 0, потому что вы действительно хотите восстановить множество привилегий.
Хотите восстановить root-права, чтобы можно было выполнить эту команду? Су , и ядро при выполнении этого бинарника переключится жидкость процесс на 0, поэтому теперь эта программа будет выполнять некоторые привилегированные действия.
Аудитория: если у вас есть идентификатор = 0 и ты меняешься жидкость все эти двоичные файлы setuid за что-то не равное 0, сможете ли вы восстановить свои привилегии? Профессор: нет, многие процессы не смогут восстановить привилегии при понижении уровня доступа, поэтому вы можете застрять на этом этапе.
Этот механизм не привязан к идентификатор = 0 .
Как и любой пользователь системы Юникс , вы можете создать любой двоичный файл, собрать программу, скомпилировать ее и установить этот бит setuid в саму программу.
Он принадлежит вам, пользователю, вашему идентификатору пользователя.
А это означает, что любой, кто запустит вашу программу, будет запускать этот код с вашим идентификатором пользователя.
Есть ли с этим проблемы? То, что должно быть сделано? Аудитория: то есть, если бы в вашем приложении была ошибка, кто-то мог бы с ней сделать что угодно, действуя с вашими привилегиями? Профессор: да, это происходит, если мое приложение «глючит» или позволяет запускать все, что вы хотите.
Предположим, я мог бы скопировать системную оболочку и сделать ее setuid для меня, но тогда любой сможет запустить эту оболочку под моей учетной записью.
Вероятно, это не лучший вариант действий.
Но такой механизм не создает проблемы, ведь установить биту сможет только человек setuid в двоичном файле является владельцем этого файла.
Вы, как владелец файла, имеете право жидкость , поэтому вы можете передать свою учетную запись другому человеку, но этот человек не сможет создать двоичный файл.
setuid с вашей ID пользователя .
Этот бит setuid хранится рядом с этими битами разрешения, то есть в каждом индексный дескриптор есть еще немного setuid который говорит, должен ли этот исполняемый файл или эта программа переключаться при выполнении на жидкость владелец.
Оказывается, что это очень умный механизм, если его правильно использовать, и он позволяет ядру правильно реализовать программу.
На самом деле это довольно легко сделать, потому что есть только одна проверка: если этот бит setuid существует, то процесс переключается на жидкость .
Это довольно просто.
Но использовать ее безопасно довольно сложно, потому что, как только что было указано, если эта программа содержит ошибки или делает что-то неожиданное, то вы получаете возможность делать произвольные действия под идентификатор = 0 или под любым другим жидкость .
В Юникс при выполнении программы вы наследуете многие вещи от родительского процесса.
Например, вы можете передавать переменные среды в двоичные файлы.
setuid .
Дело в том, что в Юникс вы можете указать, какую общую библиотеку использовать для процесса, установив переменную среды и двоичные файлы setuid не беспокойтесь о фильтрации этих переменных среды.
Например, вы можете запустить бен/су , но при этом использовать общие библиотеки для функции печать , поэтому ваш печать начнется, когда бен/су что-нибудь напечатает, и вы сможете запустить оболочку вместо выполнения печать .
Есть много тонкостей, которые вы должны правильно понимать, относительно недоверия программы к данным, которые вводит пользователь.
Поскольку вы обычно доверяете пользовательскому вводу, механизм setuid никогда не был самой безопасной частью всей системы Юникс .
Есть вопросы по этому поводу? Аудитория: setuid это также относится к группам или только к пользователю? Профессор: есть немного setgid , симметрично биту setuid , который вы тоже можете установить.
Если файл имеет определенный гид и этот бит setgid установлен при запуске программы, вы его получите.
Сетгид особо не используется, но может быть полезен в случаях, когда вы хотите предоставить очень специфические привилегии.
Например, в бин/су вероятно, для этого требуется много привилегий, но может быть какая-то программа, которой потребуются небольшие дополнительные привилегии, например, для записи чего-либо в специальный файл журнала.
Поэтому вы, вероятно, захотите назначить ему группу и создать для него файл журнала, доступный для записи этой группой.
Так что даже если программа «глючит», вы ничего, кроме этой группы, не потеряете.
Это полезно как механизм, который почему-то используется не слишком часто, ведь люди должны больше использовать root-права.
Аудитория: существуют ли ограничения на то, кто может изменить доступ? Профессор: Да.
Различные реализации Юникс для этого есть разные проверки.
Общее правило заключается в том, что только root может изменить владельца файла, поскольку вы не хотите создавать файлы, которые будут принадлежать кому-то другому, и вы, конечно же, не хотите становиться владельцем чужих файлов.
Поэтому, если ваш жидкость не равно 0, то вы застряли.
Вы не сможете изменить владельца любого файла.
Если ваш идентификатор = 0 , у вас есть root-права и вы можете сменить владельца на кого захотите.
Есть некоторые сложности, если у вас двоичный файл setuid и ты переключаешься с одного жидкость с другой стороны, это довольно сложно, но по сути вы не сможете изменить владельца файла, если у вас нет root-прав.
Судя по всему, это немного устаревшая система.
Вероятно, вы могли бы представить множество способов упростить описанные выше процессы, но на самом деле наиболее совершенные системы выглядят именно так, потому что они развиваются с течением времени.
Но вы прекрасно можете использовать эти механизмы в качестве «песочницы».
Это просто базовые принципы Юникс , которые появляются почти в каждой Unix-подобной операционной системе: в Mac OS X , Линукс , FreeBSD , В Солярис , если им пользуется кто-то другой и так далее.
Но в каждой из этих систем есть более сложные механизмы, которые вы могли бы использовать.
Например, в Линукс есть песочница установить КОМП , Mac OS X использует песочницу Ремень безопасности .
На следующей неделе я приведу вам примеры песочниц, которые есть в каждой системе на основе Юникс .
Итак, один из последних механизмов, который мы рассмотрим, прежде чем углубиться в ОКВС , объясняет, что нужно делать с двоичными файлами setuid и показывает, как можно защититься от существующих дыр в безопасности.
Проблема в том, что у вас неизбежно будут какие-то двоичные файлы.
setuid в вашей системе, например /бин/су , или судо , или что-то еще, и вполне вероятно, что в ваших программах будут ошибки.
Это может позволить кому-то выполнить двоичный файл setuid и процесс сможет получить доступ корень , чего вы не хотите.
Механизм Юникс , который часто используется для предотвращения выполнения двоичных файлов потенциально вредоносным процессом.
setuid , заключается в использовании пространства имен файловой системы для его изменения с помощью системного вызова chroot – операции по изменению корневого каталога.
ОКВС , будучи веб-сервером, специализирующимся на создании быстрых и безопасных веб-сервисов, использует это довольно широко.
Итак, в Юникс ты можешь сделать chroot в определенном каталоге, так что, возможно, вы можете сделать и то, и другое chroot("/фу") .
Есть два объяснения тому, что он делает. chroot .
Первый просто интуитивно понятен, это означает, что после запуска chroot , корневой каталог или каталог, следующий за косой чертой, в основном эквивалентен тому, что используется /фу прежде чем ты позвонил chroot .
Это похоже на ограничение пространства имен ниже вашего.
/фу .
Итак, если у вас есть файл, который раньше назывался /фу/х , затем после звонка chroot вы сможете получить этот файл, просто открыв /Икс .
Так что просто ограничьте пространство имен подкаталогом.
Это и есть интуитивная версия.
Конечно, в безопасности важна не интуитивная версия, а то, что именно делает ядро с этим системным вызовом? И он делает по сути две вещи.
Во-первых, оно меняет значение этой косой черты, поэтому всякий раз, когда вы получаете доступ или когда вы начинаете имя каталога с косой черты, ядро будет включать любой файл, который вы предоставили для операции.
chroot .
В нашем примере это файл /фу прежде чем ты позвонил chroot , то есть мы получаем это / = /фу .
Следующее, что попытается сделать ядро, — это защитить вас от возможности «ускользнуть» от вашего / если ты это сделаешь /.
/ .
Потому что в Юникс Я мог бы попросить вас дать мне, например, /.
/etc/пароль .
Итак, если бы я просто дополнил эту строку следующим образом: /foo/.
/etc/пароль , это было бы нехорошо, потому что я мог бы просто уйти /фу и приступаем к получению /etc/пароль .
Второе, что ядро делает с системным вызовом: Юникс , это когда ты звонишь chroot для этого конкретного процесса меняется способ его оценки /.
/ в этом каталоге.
Поэтому он меняется /.
/ так что /фу указал на себя.
Таким образом, он не позволяет вам «убежать», и это изменение касается только этого процесса и не затрагивает другие.
Какие у вас есть идеи, как «сбежать» от окружающей среды? chroot используя способ его реализации? Интересно, что ядро отслеживает только один каталог.
chroot так что, возможно, вы могли бы выполнить операцию chroot = (/фу) , но оказались бы «приклеенными» к этому месту.
Итак, вы хотите получить /etc/пароль , но как это сделать? Вы можете открыть корневой каталог прямо сейчас, набрав открыть (*/*) .
Это даст вам дескриптор файла, описывающий, что /фу .
Тогда вы можете позвонить chroot еще раз и выполнить chroot (`/бар) .
Итак, теперь ядро меняет план: корень больше не надо /фу , А /фу/бар и это /.
/ перенаправление применяется только к /фу/бар/.
Но знайте, что у вас все еще есть дескриптор файла для /фу .
Итак, теперь вы можете менять каталоги в этом файловом дескрипторе.
fchdir (фд) на этот открытый конкурс (*/*) и теперь ты можешь получить чдир (.
) .
То есть сначала вы находились в /фу , а теперь идем /.
/ .
Он больше не заставляет меня /фу покажи на себя и не возвращайся, потому что у тебя есть кто-то другой корень , так что теперь ты можешь сбежать отсюда.
Возможно, это хорошая иллюстрация того, почему важен точный механизм реализации.
В этом смысле это не интуитивное объяснение.
Поэтому в Юникс звонить может только пользователь с root правами chroot , в противном случае chroot было бы совершенно бессмысленным занятием.
Таким образом, в Юникс Вы должны иметь идентификатор = 0 чтобы выполнить операцию над процессом chroot .
Это немного разочаровывает. Потому что, если вы хотите построить систему с действительно общими привилегиями, где каждый имеет только минимальный набор необходимых привилегий, вам нужно использовать chroot , создавать новое ID пользователя и так далее.
Но чтобы сделать это в Юникс , у вас должен быть запущен процесс от имени корень , который имеет множество привилегий.
Итак, это пример неудачного компромисса, но, вероятно, это наиболее разумный способ проектирования системы.
Один из способов настройки среды chroot без создания большого количества копий файлов создается каталог с жесткими ссылками.
Это довольно хорошее решение.
Аудитория: что если программа постепенно генерирует индексные дескрипторы Я киваю но не дает вам дескриптор файла? Профессор: Это очень важная деталь! Вы можете получить доступ к файлу, только пройдя по пути к каталогу, соответствующему его имени, а не, например, сказав: «Я хочу открыть индексный дескриптор номер 23", потому что это может быть какой-то странный файл вообще за пределами вашей среды.
шрут .
Таким образом, в Юникс ты не можешь открыть индексный дескриптор по номеру индексный дескриптор , если, конечно, у вас нет root-прав.
Я думаю, у нас достаточно машин, чтобы увидеть, как это работает. ОКВС .
Давайте кратко рассмотрим, чего следует опасаться при работе ОКВС .
Альтернативный дизайн, которому следует почти каждый веб-сервер, заключается в том, что вы можете иметь в Интернете веб-браузеры, которые будут подключаться к вашему серверу.
А внутри вашего сервера в основном будет работать один процесс, скажем, httpd , например, на Апач .
И этот процесс будет работать как один ID пользователя под именем www В /etc/пароль .
Он принимает все ваши соединения, выполняет все процессы, включая обработку SSL , включая выполнение кода приложения и PHP и так далее, это все части одного и того же процесса.
И при необходимости этот процесс подключается к серверу базы данных, возможно MySQL , который может работать на том же компьютере или в другом месте.
И этот процесс MySQL фактически записывает данные на диск.
Но подключиться к этому MySQL , вам, вероятно, следует указать имя пользователя и пароль.
Но, как правило, приложения пишутся так, что на сервере MySQL есть одна общая учетная запись, для которой приложение знает имя пользователя и пароль, поэтому вы просто подключаетесь к ней и получаете доступ ко всем своим данным.
Таким образом, это решение очень удобно для написания программы, поскольку вы просто пишете любой код и имеете доступ к любым данным в базе данных, которые вам нужны.
Реальной изоляции нет, но есть проблемы с безопасностью, возможно, связанные с ошибками в Апач или в SSL , а может быть в коде приложения или в интерпретаторе PHP .
А если есть ошибки, то по ним можно получить всё содержимое приложения.
52:30 мин.
Продолжение: Курс MIT «Безопасность компьютерных систем».
Лекция 4: Разделение привилегий, часть 2 Доступна полная версия курса Здесь .
Спасибо, что остаетесь с нами.
Вам нравятся наши статьи? Хотите увидеть больше интересных материалов? Поддержите нас, разместив заказ или порекомендовав друзьям, Скидка 30% для пользователей Хабра на уникальный аналог серверов начального уровня, который мы придумали для вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от 20$ или как правильно расшарить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40 ГБ DDR4).
Dell R730xd в 2 раза дешевле? Только здесь 2 x Intel Dodeca-Core Xeon E5-2650v4 128 ГБ DDR4 6x480 ГБ SSD 1 Гбит/с 100 ТВ от 249 долларов США в Нидерландах и США! Прочтите об этом Как построить корпоративную инфраструктуру класса, используя серверы Dell R730xd E5-2650 v4 стоимостью 9000 евро за копейки? Теги: #информационная безопасность #программирование #ИТ-инфраструктура #Разделение привилегий #Разделение привилегий #Разделение привилегий #бинарные файлы setuid
-
Apple Принесла Извинения Samsung
19 Oct, 24 -
Пульсометры Для Nasa: Знакомимся С Salutron
19 Oct, 24 -
Эмуляторы Терминала
19 Oct, 24 -
Топ-10 Квестов «Века». (Опрос+Результаты)
19 Oct, 24 -
Отчет О Роботах На Gdd Europe 2017
19 Oct, 24
