Unix от юзера и до администратора
Табели о рангах

pic

Представьте себе, что стоит некое здание с вывеской «Unix» и множеством входов. Каждое помещение в этом здании — это директория (каталог), в которой могут быть выходы в другие директории или внутри каждой комнаты могут храниться документы — файлы, а также работники, способные выполнять различные задания — процессы.

У каждого входа в здание стоят секьюрити — процессы с именами *getty (getty, mgetty и т.д.). Прежде чем войти, им необходимо сообщить свой логин. Секьюрити сравнивает логин с содержимым списков, находящихся в файле /etc/passwd, и при необходимости также запрашивает и пароль. После чего для вас выделяется специальный служащий — процесс, который будет выполнять все ваши распоряжения внутри здания «Unix», например shell (указывается в /etc/passwd). Его препровождают в то помещение, которое указано в качестве домашнего каталога — личного кабинета или офиса (как вам угодно), указанного в /etc/passwd, и выдают бейджик, на котором указан ваш логин. Все здание «Unix» устроено в виде эдакой древовидной системы, начинающейся с корневого помещения /, от которого во все стороны расходятся выходы в помещения иные. Впрочем, чтобы каждый раз не возвращаться к корневой прихожей, могут быть предусмотрены и прямые переходы в виде (символических) ссылок на другие удаленные помещения. Для выполнения любых действий необходимо дать задание соответствующему работнику — через shell или другого посредника запустив процесс, те, в свою очередь, также могут запускать другие процессы, отдавая соответствующие распоряжения другим работникам. Причем каждый из них получает именное распоряжение и выполняет свои задачи, используя ваш логин. Логин и является тем самым пропуском ко всему, что доступно в здании — ресурсам. Он же является и ограничением.
Например, чтобы перейти в другое помещение, вашему представителю необходимо вызвать работника с именем cd и сообщить ему о том, куда желательно переместиться. Он сначала открывает все двери из помещения, в котором вы сейчас находитесь или от /, если нет более прямого пути и до точки назначения, открывая каждую из них посредством предъявления бейджика с вашим логином. Если для всех дверей на пути предъявленный логин является отмычкой, тогда cd проведет вашего представителя в нужное место. Но если хоть одну дверь открыть не удастся, тогда он останется там же, где и был. В принципе, переходить не обязательно, можно дать любому работнику задание, которое он должен выполнить в определенном помещении. Он возьмет ваш логин и, предъявляя его на каждом шагу, отправится выполнять. Работник может отказаться от задания, если ваш логин не является пропуском или разрешением на выполняемую работу, а также нужно учесть, что здесь следует соблюдать иерархию и не всякий юзер может дать распоряжение всякому служащему в здании. Проще говоря, у каждого ресурса в Unix есть непосредственный начальник (хотя в более точном переводе владелец), который и решает в конечном итоге, что именно и для кого служащий должен выполнять или кто имеет доступ к помещению — директории или документу — файлу. Помимо начальника может быть указана и группа пользователей — своего рода подразделение, имеющее особые права. Впрочем, права могут быть указаны и для всех остальных, так называемых посторонних, которым либо «Вход запрещен», либо «Добро пожаловать». В любом случае всю работу выполняют процессы от имени вашего логина, каждый раз, скрупулезно проверяя наличие прав доступа. А что в данном случае означают права? Они подразделяются на три категории:

• права владельца ресурса
• права группы — подразделения пользователей
• права для посторонних, которыми могут воспользоваться все, кто не является владельцами и не входит в группу пользователей ресурса.

Права задаются тройками: rwx. Их можно посмотреть с помощью команды:

#ls -l

В ответ на которую мы получим список, состоящий из строк типа:

-rw-r—r— 1 owner workgroup 505 Mar 13 19:05 anyname

где первые десять символов -rw-r—r и есть информация о ресурсе с именем anyname. Следом идут количество копий, логин владельца, название группы, размер в байтах, месяц, дата и время последней модификации и название ресурса.

Из десяти символов прав доступа первый показывает, с чем мы имеем дело, и если он обозначен в виде тире, то это обычный файловый поток, или символ «d», если ресурс является директорией. Далее идут тройки rwx. Первая — права для процесса, запущенного из-под логина владельца ресурса, вторая — для логинов группы и третья — для всех прочих. Установленный символ — разрешение соответствующего права, а тире — запрет.

pic

Давайте разберемся с аббревиатурой rwx? Это сокращение от трех английских глаголов: r (read) — читать, w (write) — писать и x (execute) — запустить. Следовательно, и права могут быть трех видов, а именно разрешающие или запрещающие:

• читать или получать информацию из потока
• писать или вносить изменения и дополнения, а также удалять информацию в потоке или даже сам поток
• запускать поток в качестве выполняемого процесса или подпроцесса — программы или подпрограммы.

Еще раз уточню, что под именем пользователя в Unix никогда не подразумевается человек. Права предоставляются запущенным процессам, предъявляющим логин пользователя для выполнения тех или иных действий.
Права доступа имеют различия для директорий и файлов. Опять же вернемся к образному описанию. Если директория — это помещение, то право x — это право на вход в эту комнату, а также во все остальные комнаты, в которые можно пройти через нее. Право r — просмотр содержимого данной комнаты в виде названий документов, имен служащих (процессы) или названий других комнат, выходящих из данных. Если права на просмотр нет, то можно через комнату транзитом перейти в другие, даже не зная, что находится в помещении, которое было пройдено. А вот право w позволяет в данной комнате наводить порядок по своему усмотрению:

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

Для файловых ресурсов права могут иметь иное значение. Если вернуться к образному описанию, то в помещении могут находиться служащие либо документы. И то, и другое в Unix представлено в виде файлов. Право r — это дает возможность ознакомиться с содержимым документа или теми действиями, которые может выполнять служащий. Право w — вносить изменения и дополнения в документы или корректировать действия служащих. Необходимо уточнить, что если вы имеете право хозяйничать — w внутри помещения, в котором находятся документы, то это еще не дает вам возможности ознакомиться с содержимым документов или изменять его, но разрешено их удалять, независимо от прав доступа к ним. А вот право корректировки документов разрешает менять в них информацию без права уничтожения документов. И, наконец, право — x для файла означает, что это не документ, а служащий — процесс. Имея права распоряжаться в помещении — w, вы в то же самое время можете не иметь права давать распоряжения служащим x, удалить (уволить) любого служащего, независимо от того, кто является его начальником или к какой группе он относится. А следовательно, право отдавать приказы служащему не позволяет его уволить.
Эти, мягко говоря, дурацкие правила игры и привели к тому, что Unix стал первой операционной системой, на которой были испытаны вирусы и хакерские атаки. Проще говоря, политика пользователей и групп в Unix имеет ряд тонкостей, несоблюдение которых может привести к нарушению безопасности. Печальный опыт киберпреступности показал, что законы Мерфи, повествующие о том, что если какое безобразие может случиться, то оно обязательно произойдет, в области информационных технологий шутками не являются. Хакеры всегда пытаются найти лазейку, и если она есть, то значит, будет использована. Более того, редкий хакер вручную ищет лазейки, а доверяет эту функцию программам, что не оставляет шансов для незадачливых администраторов. Даже в реальной жизни действует пословица, согласно которой доверять следует, лишь проверяя. Проверить, а тем более найти концы в майнфреймовой организации операционной системы Unix практически невозможно, поскольку пользователи не оставляют здесь следов. Конечно же, система ведет журналирование наиболее важных событий, но следует учесть, что, во-первых, разбор таких записей требует значительного времени и знаний, а во-вторых, здесь запросто можно, что называется, «подложить свинью».
Следует учитывать, что права хозяйничать в директории (w) и все права на корректировку файлов в ней следует назначать только одному-единственному пользователю — владельцу этого ресурса. Ни в коем разе не следует доверять его группе, а тем более посторонним. Ведь если в каком-либо месте имеют право распоряжаться более одного начальника, то все будет как в басне о лебеде, раке и щуке. Какой смысл создавать файлы в директории, в которой хозяйничают несколько пользователей, если каждый из них может в лучшем случае удалить чужой ресурс, а в худшем его подменить? Кому приятно быть начальником подчиненных, которых увольняют и заменяют другие? Какой смысл выполнять работу, результаты которой пойдут насмарку?
Поэтому, чтобы избежать недоразумений, то права на ресурсы следует устанавливать по минимуму: *rw*——, но ни в коем разе не *****w**w* (звездочка в соответствующем месте означает приемлемость для любого значения). Хозяин должен быть один, а следовательно, права w для группы или посторонних желательно было бы вообще исключить по причине их заведомой неоднозначности, которая может стать нарушением безопасности.

Установить права к ресурс(ам)у можно с помощью запуска процесса:

#chmod {a,u,g,o}{+,-}{r,w,x,s}

где символы a, u, g, o — означают all — для всех без исключения, user — только для владельца, group — только для группы, other — для всех прочих, кроме группы и владельца. Плюс и минус — добавить право доступа или убрать. А с r, w, x вы уже знакомы. Значение filenames — наименования ресурсов. Например:

#chmod go-w anyname

удалит права распоряжаться ресурсом anyname для всех, кроме владельца. Все остальные права доступа останутся без изменений. Если после имени процесса chmod поставить ключик «R» (рекурсивно), то применительно к директории будут заменены права для всех ресурсов, находящихся в ней или во всех ее поддиректориях.
Еще один символ «s» не просто разрешает запускать процессы, но еще и выполнять с правами их владельца (SetUID) или группы (SetGID). Поэтому его задают совместно с символами «u» или «g». C точки зрения безопасности — это наименее приятное право, поскольку позволяет повысить свой уровень доступа.
Если необходимо задать сразу все права, то вместо буквенных символов можно воспользоваться восьмеричными цифровыми. Права в этом случае кодируются с помощью четырех восьмеричных цифр, каждая из которых может принимать значения от 0 до 7. Принцип их расшифровки очень прост, поскольку каждое из прав имеет свое цифровое значение: r 4, w 2, x 1. Просуммировав их, мы и получим в качестве результата цифру от 0 (все права доступа отключены) до 7 (полный доступ). Первая цифра слева в четверке задает сумму прав для SetUID — 4, SetGID — 2 и Sticky bit — 1. Остальные три цифры слева направо — это права для владельца ресурса, группы и прочих. Если цифр менее чем четыре, то, как и в арифметике, все недостающие значения слева считаются нулями. Например, процесс:

#chmod 1754 anyfile

установит Sticky bit, все права доступа для владельца, запретит модификацию ресурса для группы, а всем прочим разрешит только ознакомиться с содержимым.

Также можно изменить права владения файлами с помощью процесса:
#chown {[newowner][:newgroup]}

где newowner — логин нового пользователя, а newgroup — наименование другой группы. Если мы не желаем менять либо владельца, либо группу, то соответствующий идентификатор можно опустить. Передать права владения ресурсом привилегированному пользователю от непривилегированного нельзя.
Неприятная особенность Unix — это процессы, выполняющиеся от имени логина того, кто их запустил. Если такой процесс запустит любой другой, созданный иным пользователем, то тот, в свою очередь, будет выполняться опять же с правами предыдущего логина. Этот же логин и записывается в журналы системы. Если запущенный таким макаром процесс был подменен и в нем содержались команды совсем не те, которые предполагались, то в результате все «шишки» достанутся вовсе не злоумышленнику. Еще хуже, когда привилегированный процесс заведомо должен запускать процессы, созданные другими пользователями. Например, печально известная и излюбленная хакерами служба отправки почты sendmail. Ее процесс не может быть непривилегированным, поскольку обязан заходить в каталоги всех пользователей системы, да еще и выполнять скрипты, содержащие правила рассылки почтовых сообщений, созданные этими самыми пользователями. Вполне понятно, что хакеров не столько интересовали правила для почты, сколько очень высокие привилегии, и потому в скриптах для sendmail частенько находились команды, которые к почте вообще никакого отношения не имели.
Неприятности есть и в передаче прав пользователя или группы для запускаемого процесса с помощью SetUID и SetGID. В определенной мере это кажется необходимым, поскольку непривилегированный пользователь не в состоянии получить доступ к определенным ресурсам, необходимым для выполнения задачи. С другой стороны, заведомо нарушается безопасность, поскольку запущенный таким образом процесс выполняется от имени пользователя более привилегированного. Опасность в том, что злоумышленник может в качестве аргумента для такого процесса подсунуть нежелательные команды, которые будут выполнены с высокими правами доступа. Одним из таких опасных процессов является демон модемного соединения pppd.
Конечно же, наиболее приемлемыми были бы правила, когда всякий вновь созданный процесс запускался от имени владельца ресурса, содержащего команды (скрипта или бинарника), что вполне разумно с точки зрения безопасности и отслеживания нарушений. Проблема подмены запускаемых процессов отпала бы сама собой.
В определенной мере часть проблем можно снять, если установить версию Unix без суперпользователя, например взяв OS Linux или OS Solaris компании Sun Microsystems. Но это не панацея, а всего лишь перекладывание проблем, поскольку в этом случае все функции администрирования придется переложить на плечи групп пользователей, а следовательно, политика групп усложнится.
Так что пока приходится мириться с тем, что есть, воспринимать его, как есть, и решать проблемы безопасности накладыванием различных заплат.

pic

Orphus system