| С точки зрения обывателя, Линукс обладает невероятным иммунитетом к компьютерным инфекциям. Даже в стандартной конфигурации, без вмешательства пользователя, современные дистрибутивы невосприимчивы к вирусам и вредоносному софту. Если же приложить руку и ограничить доступ извне (добавить строчку ALL: ALL в /etc/hosts.deny и очистить hosts.allow), то с гарантией почти в сто процентов никакая сетевая зараза — живая или программная — на вашу машину уже не пролезет. Попробуйте теперь объяснить это коллегам/одноклассникам, реакция вас впечатлит. Не так просто и «свалить» свободные программы неправильным запросом: по статистике, софт с открытыми исходниками содержит меньше программистских ошибок, чем софт проприетарный. Слабые места у свободной операционной системы конечно есть, но принцип «нашёл — исправь» периодически отправляет на свалку истории и случайные баги, и целые архитектурные решения, державшиеся десятилетиями, но оказавшиеся неудачными. Об одном из таких фундаментальных «недосмотров» и пойдёт речь сегодня. Впрочем, прежде чем перейти к основной теме, не поленитесь, откройте консоль и запустите такую команду: find / -user root -perm -4000 Пусть работает фоном, чуть позже она нам понадобится. А пока давайте вспомним теорию. У каждого файла и каталога в Linux имеются так называемые права доступа или атрибуты — свойства, определяющие возможность производить с данным объектом некоторые действия. Там же, в атрибутах выставляется и то, кому разрешено производить оговоренные действия (владелец файла и пользовательская группа, в которой он состоит). Посмотреть полный список можно через Midnight commander (mc), командой меню Файл -> Права доступа. Самыми простыми атрибутами являются права на запись и чтение. А установив флажок «запуск», вы покажете системе, что файл следует считать исполняемым (программой).
О чтении/записи знают конечно все. Но там же есть и ещё один любопытный пункт, обозначенный UID. Расшифровывается это сокращение как User Identifier (идентификатор пользователя) и часто именуется SUID (Set UID — установить пользовательский идентификатор). Включив этот атрибут, вы разрешите исполнение файла не только его владельцу, но и всем пользователям системы. Для того, чтобы понять, зачем это понадобилось, стоит вспомнить, что права доступа достались Linux в наследство от UNIX, архитектура которой формировалась аж сорок лет назад. В конце 60-ых годов, когда UNIX ещё называлась UNICS (намёк на предшествующую ОС Multics), один из её авторов, Деннис Ритчи, придумал UID для упрощения администрирования системы. К слову, это тот самый Ритчи, написавший язык C. Но не будем отвлекаться. UNIX и Linux так надёжны потому, что большинство задач, касающихся ядра системы, разрешено выполнять только её администратору (также известен как суперпользователь или root). У простого пользователя нет права устанавливать и удалять программы, управлять сетевыми соединениями, и прочее подобное, что может затронуть других пользователей и систему в целом. Паранойя хороша, когда речь идёт о сохранности данных, но жизнь рядового юзера в нарисованной обстановке тотального запрета приятной не назовёшь. Ведь пользователь не вправе запустить даже безобидную утилиту ping, которая работает с сетью на низком уровне, а потому требует администраторских полномочий! Тут и приходит на помощь UID. Администратор может включить этот атрибут для принадлежащих ему программ (вроде ping), использование которых хоть и требует root-доступа, но не может причинить вред системе. Кроме того, есть хитрость: выполняя программу с флагом UID, пользователь получает права её владельца лишь в пределах этой самой программы. Вот так отцы-основатели Юникс решили древнюю задачку о сытых волках и целых овцах. И следуюшие двадцать лет прошли тихо и спокойно: UNIX полнела и множилась, помогала формировать Интернет, завоевала славу надёжной и мощной операционной системы. А в 1988 году грянул гром. Первая глобальная компьютерная эпидемия, устроенная американским студентом Робертом Моррисом, вывела из строя каждый десятый узел из числа подключенных к молодой тогда ещё Сети. Написанный Моррисом вирус был непростой программой, но секрет его «успеха» оказался до невозможного прост. Тот самый флажок UID.
По иронии судьбы, сегодня Моррис - профессор MIT, того же вуза, в котором выпустил свой вирус Как было сказано выше, принадлежащая администратору программа с включенным атрибутом UID теоретически не представляет угрозы для системы. Ведь права администратора даются пользователю только временно, в рамках одной программы — они не могут быть переданы другим процессам, и автоматически аннулируются после того, как программа нормально завершит работу. Но представьте, что в такой программе имеется ошибка и пользователь ухитрился эту ошибку задействовать. К примеру, переполнить текстовый буфер. Приложение будет аварийно прервано и пользователь останется с root-полномочиями. Именно так работал червь Морриса. Обнаружив на очередном компьютере почтовик sendmail или «социальный» сервис finger (UID для них в те времена был включен почти повсеместно), он заставлял их завершиться с ошибкой и получал в результате полный доступ к системе. Червь Морриса не удалял файлы. Его деструктивное влияние сводилось к перегрузке процессора в результате неконтролируемого размножения. Может быть поэтому использованная в нём схема атаки стала общеизвестной лишь через десять лет, после легендарной публикации в электронном журнале Phrack («Smashing The Stack For Fun And Profit», Aleph One). Однако и после этого, и до сих пор SUID периодически светится в новостях, посвящённых киберкриминалу (вот пример из октября 2010). Так почему же разработчики UNIX-совместимых операционок не задумались хотя бы над тем, как укрепить это слабое звено? К чести юниксоидов и особенно сторонников Linux стоит заметить: задумывались неоднократно и близки к полному решению. Linux первой из юниксов ограничила влияние UID на систему, игнорируя действие этого атрибута для каталогов и скриптов. Кроме того, наработан арсенал средств для вывода из под UID-угрозы значительной части системы одним махом: смонтировав, в частности, пользовательские каталоги (/home) с ключиком nosuid, а каталог /tmp ещё и с ключом noexec (программы и скрипты из этой папки не смогут быть исполнены), вы дополнительно обезопасите свой Линукс. Конечно, хорошо было бы насовсем избавиться от SUID-программ, но до сих пор возможным было лишь уменьшение их количества. А те программы, которые освободились от UID-флага, но всё же требуют администраторских прав, можно запускать с помощью правильно настроенной утилиты sudo. Кстати, самое время вспомнить о консоли, которую вы запустили десять минут назад. Теперь, когда вы знаете, что такое атрибут UID и чем он опасен для программ, принадлежащих администратору, посмотрите, сколько их на вашем компьютере. Если вы используете стабильную версию одного из популярных дистрибутивов, список будет включать порядка двадцати имён. Что ж, это неплохо, учитывая, что исходники каждой из этих программ вылизаны до блеска, дабы смесь администраторской принадлежности и включённого UID не стала гремучей. Но именно сейчас, спустя четыре десятилетия со дня изобретения, атрибут UID наконец близок к полному исчезновению.
Openwall Linux очищен от SUID-приложений Разработчики специализированных Linux-дистрибутивов, для которых информационная безопасность превыше всего, уже смогли одолеть эту задачку. И, к примеру, свежий серверный Openwall 3.0 не содержит ни единой root-программы с включенным флагом UID. В том же направлении, хоть и другой дорожкой, движутся авторы Fedora 15 Lovelock и Ubuntu Linux. Там, где стопроцентное избавление от UID не планируется, пытаются сократить количество содержащих его приложений. Хитроумные способы избавления от древнего флага сами по себе заслуживают отдельного рассказа, но в конце концов пора уже и остановиться. Безопасность Линукса теперь обеспечивается без ущерба для удобства. Так что не обязательно разбираться в хитросплетениях Ядра, чтобы использовать преимущества свободной системы на полную катушку. С наступающим! :-)
|
