Загрузки системы. В процессе загрузки будет запущена основная управляющая программа ядро



страница9/16
Дата22.11.2016
Размер6.23 Mb.
Просмотров829
Скачиваний0
1   ...   5   6   7   8   9   10   11   12   ...   16

Пример 7. Работа с файлами в разделяемом каталоге

Убедившись, что любой доступ в каталог /tmp открыт всем, Мефодий захотел удалить оттуда все файлы. Затея гораздо более хулиганская, чем заведение файла: а вдруг они кому-нибудь нужны? Удивительно, но удалить удалось только файл, принадлежащий самому Мефодию...

Дело в том, что Мефодий проглядел особенность атрибутов каталога /tmp: вместо “x” в тройке «для посторонних» ls выдал “t”. Это ещё один атрибут каталога, наличие которого как раз и запрещает пользователю удалять оттуда файлы, которым он не хозяин. Таким образом, права записи в каталог с ярлыком “drwxrwxrwt группа хозяин” и для членов группы группа, и для посторонних ограничены их собственными файлами, и только хозяин имеет право изменять список файлов в каталоге, как ему вздумается. Такие каталоги называются разделяемыми, потому что предназначены они, как правило, для совместной работы всех пользователей в системе, обмена информацией и т. п.

При установке атрибута “t” доступ на использование для посторонних (“t” в строчке атрибутов стоит на месте последнего “x”) не отменяется. Просто они так редко используются друг без друга, что ls выводит их в одном и том же месте. Если кому-нибудь придёт в голову организовать разделяемый каталог без доступа посторонним на использование, ls выведет на месте девятого атрибута не “t”, а “T”.


[methody@localhost methody]$ ls -l loop

-rw-r--r-- 1 root root 26 Сен 22 22:10 loop

[methody@localhost methody]$ chown methody loop

chown: изменение владельца `loop': Operation not permitted

[methody@localhost methody]$ cp loop loopt

[methody@localhost methody]$ ls -l loop*

-rw-r--r-- 1 root root 26 Сен 22 22:10 loop

-rw-r--r-- 1 methody methody 26 Сен 22 22:15 loopt

[methody@localhost methody]$ mv -f loopt loop

[methody@localhost methody]$ ls -l loop*

-rw-r--r-- 1 methody methody 26 Сен 22 22:15 loop


Пример 8. Что можно делать с чужим файлом в своём каталоге

Оказывается, мелкие пакости продолжаются. Кто-то сменил файлу loop хозяина, так что теперь Мефодий может только читать его, но не изменять. Удалить этот файл — проще простого, но хочется «вернуть всё как было»: чтобы получился файл с тем же именем и тем же содержанием, принадлежащий Мефодию, а не root-у. Это несложно: чужой файл можно переименовать (это действие над каталогом, а не над файлом), скопировать переименованный файл в файл с именем старого (доступ по чтению открыт) и, наконец, удалить чужой файл с глаз долой. Ключ “-f” (force, «силком») позволяет утилите mv делать своё дело, не спрашивая подтверждений. В частности, увидев, что файл с именем, в которое необходимо переименовывать, существует, даже чужой, даже недоступный на запись, mv преспокойно удалит его и выполнит операцию переименования.

Суперпользователь

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


суперпользователь

Единственный пользователь в Linux, на которого не распространяются ограничения прав доступа. Имеет нулевой идентификатор пользователя.


Суперпользователь в Linux — это выделенный пользователь системы, на которого не распространяются ограничения прав доступа. UID суперпользовательских процессов равен 0: так система отличает их от процессов других пользователей. Именно суперпользователь имеет возможность произвольно изменять владельца и группу файла. Ему открыт доступ на чтение и запись к любому файлу системы и доступ на чтение, запись и использование к любому каталогу. Наконец, суперпользовательский процесс может на время сменить свой собственный UID с нулевого на любой другой. Именно так и поступает программа login, когда, проведя процедуру идентификации пользователя, запускает стартовый командный интерпретатор.

Среди учётных записей Linux всегда есть запись по имени root («корень»3), соответствующая нулевому идентификатору, поэтому вместо «суперпользователь» часто говорят «root». Множество системных файлов принадлежат root-у, множество файлов только ему доступны на чтение или запись. Пароль этой учётной записи — одна из самых больших драгоценностей системы. Именно с её помощью системные администраторы выполняют самую ответственную работу. Свойство root иметь доступ ко всем ресурсам системы накладывает очень высокие требования на человека, знающего пароль root. Суперпользователь может всё — в том числе и всё поломать, поэтому любую работу стоит вести с правами обычного пользователя, а к правам root прибегать только по необходимости.

Существует два различных способа получить права суперпользователя. Первый — это зарегистрироваться в системе под этим именем, ввести пароль и получить стартовую оболочку, имеющую нулевой UID. Это — самый неправильный способ, пользоваться которым стоит, только если нельзя применить другие. Что в этом случае выдаст команда last? Что тогда-то с такой-то консоли в систему вошёл неизвестно кто с правами суперпользователя и что-то там такое делал. С точки зрения системного администратора, это — очень подозрительное событие, особенно, если сам он в это время к указанной консоли не подходил... сами администраторы такой способ не любят.

Второй способ — это воспользоваться специальной утилитой su (shell of user), которая позволяет выполнить одну или несколько команд от лица другого пользователя. По умолчанию эта утилита выполняет команду sh от лица пользователя root, то есть запускает командный интерпретатор с нулевым UID. Отличие от предыдущего способа — в том, что всегда известно, кто именно запускал su, а значит, с кого спрашивать за последствия. В некоторых случаях удобнее использовать не su, а утилиту sudo, которая позволяет выполнять только заранее заданные команды.

Подмена идентификатора

Утилиты su и sudo имеют некоторую странность, объяснить которую Мефодий пока не в состоянии. Эта же странность распространяется и на давно известную программу passwd, которая позволяет редактировать собственную учётную запись. Запускаемый процесс наследует UID от родительского, поэтому, если этот UID — не нулевой, он не в состоянии поменять его. Тогда как же su запускает для обычного пользователя суперпользовательский shell? Как passwd получает доступ к хранилищу всех учётных записей? Должен существовать механизм, позволяющий пользователю запускать процессы с идентификаторами другого пользователя, причём механизм строго контролируемый, иначе с его помощью можно натворить немало бед.

В Linux этот механизм называется подменой идентификатора и устроен очень просто. Процесс может сменить свой UID, если запустит вместо себя при помощи exec() другую программу из файла, имеющего специальный атрибут SetUID4. В этом случае UID процесса становится равным UID файла, из которого программа была запущена.

[foreigner@somewhere foreigner]$ ls -l /usr/bin/passwd /bin/su

-rws--x--x 1 root root 19400 Фев 9 2004 /bin/su

-rws--x--x 1 root root 5704 Янв 18 2004 /usr/bin/passwd

[foreigner@somewhere foreigner]$ ls -l /etc/shadow

-r-------- 1 root root 5665 Сен 10 02:08 /etc/shadow


Пример 9. Обычная программа passwd, использующая SetUID

Как и в случае с t-атрибутом, ls выводит букву “s” вместо буквы “x” в тройке «для хозяина». Точно так же, если соответствующего x-атрибута нет (что бывает редко), ls выведет “S” вместо “s”. Во многих дистрибутивах Linux и /bin/su, и /usr/bin/passwd имеют установленный SetUID и принадлежат пользователю root, что и позволяет su запускать процессы с правами этого пользователя (а значит, и любого другого), а passwd — модифицировать файл /etc/shadow, содержащий в таких системах сведения обо всех учётных записях. Как правило, SetUID-ные файлы доступны обычным пользователям только на выполнение, чтобы не провоцировать этих обычных пользователей рассматривать содержимое этих файлов и исследовать их недокументированные возможности. Ведь если обнаружится способ заставить, допустим, программу passwd выполнить любую другую программу, то все проблемы с защитой системы от взлома будут разом решены — нет защиты, нет и проблемы.

Однако Мефодий работает с такой системой, где /usr/bin/passwd вообще не имеет атрибута SetUID. Зато эта программа принадлежит группе shadow и имеет другой атрибут, SetGID, так что при её запуске процесс получает идентификатор группы shadow. Утилита ls выводит SetGID в виде “s” вместо “x” во второй тройке атрибутов («для группы»). Замечания касательно “s”, “S” и “x” действительны для SetGID так же, как и для SetUID.

[root@localhost root]# ls -l /usr/bin/passwd

-rwx--s--x 1 root shadow 5704 Jan 18 2004 /usr/bin/passwd

[root@localhost root]# ls -al /etc/tcb/methody

total 3

drwx--s--- 2 methody auth 1024 Sep 22 12:58 .



drwx--x--- 55 root shadow 1024 Sep 22 18:41 ..

-rw-r----- 1 methody auth 81 Sep 22 12:58 shadow

-rw------- 1 methody auth 0 Sep 12 13:58 shadow-

-rw------- 1 methody auth 0 Sep 12 13:58 shadow.lock


Пример 10. Не подверженная взлому программа passwd, использующая SetGID

Каталог /etc/tcb в этой системе содержит подкаталоги, соответствующие входным именам всех её пользователей. В каждом подкаталоге хранится, в числе прочего, собственный файл shadow соответствующего пользователя. Доступ к каталогу /etc/tcb на использование (а следовательно, и ко всем его подкаталогам) имеют, кроме root, только члены группы shadow. Доступ на запись к каталогу /etc/tcb/methody и к файлу /etc/tcb/methody/shadow имеет только пользователь methody. Значит, чтобы изменить что-либо в этом файле, процесс обязан иметь UID methody и GID shadow (или нулевой UID, конечно). Именно такой процесс запускается из /usr/bin/passwd: он наследует UID у командного интерпретатора и получает GID shadow из-за атрибута SetGID. Выходит, что даже найдя в программе passwd ошибки и заставив её делать что угодно, злоумышленник всего только и сможет, что... отредактировать собственную учётную запись!

Оказывается, атрибут SetGID можно присваивать каталогам. В последнем примере каталог /etc/tcb/methody имел SetGID, поэтому все создаваемые в нём файлы получают GID, равный GID самого каталога — auth. Используется это разнообразными процессами идентификации, который, не будучи суперпользовательскими, но входя в группу auth и shadow, могут прочесть информацию из файлов /etc/tcb/входное_имя/shadow.

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

Восьмеричное представление атрибутов

Все двенадцать атрибутов можно представить в виде битов двоичного числа, равных 1, если атрибут установлен, и 0, если нет. Порядок битов в числе следующий: sU|sG|t|rU|wU|xU|rG|wG||xG|rO|wO|xO. где sU — это SetUID, sG — это SetGID, t — это t-атрибут, после чего следуют три тройки атрибутов доступа. Этим форматом можно пользоваться в команде chmod вместо конструкции “роли=виды_доступа”, причём число надо записывать в восьмеричной системе счисления. Так, атрибуты каталога /tmp будут равны 1777, атрибуты /bin/su — 4711, атрибуты /bin/ls — 755 и т. д.

Тем же побитовым представлением атрибутов регулируются и права доступа по умолчанию при создании файлов и каталогов. Делается это с помощью команды umask. Единственный параметр umask — восьмеричное число, задающее атрибуты, которые не надо устанавливать новому файлу или каталогу. Так, umask 0 приведёт к тому, что файлы будут создаваться с атрибутами “rw-rw-rw-”, а каталоги — “rwxrwxrwx”. Команда umask 022 убирает из атрибутов по умолчанию права доступа на запись для всех, кроме хозяина (получается “rw-r--r--” и “rwxr-xr-x” соответственно), а с umask 077 новые файлы и каталоги становятся для них полностью недоступны (“rw-------” и “rwx------”)5.
1 Здесь есть тонкость. В файле group указываются не идентификаторы, а входные имена пользователей. Формально говоря, можно создать двух пользователей с одинаковым UID, но разными GID и списками групп. Обычно так не делают: надобности — почти никакой, а неразберихи возникнет много.

2 Более точно — обо всех процессах, имеющих право выводить на какой-нибудь терминал, а значит, запущенными из терминального сеанса.

3 Вместо полного имени такому пользователю часто пишут «root of all evil».

4 Строго говоря, при этом меняется не собственно идентификатор пользователя, а т. н. исполнительный идентификатор пользователя, EUID; это нужно для того, чтобы знать, кто на самом деле запустил программу.

5 Параметр команды umask должен обязательно начинаться на 0, как это принято для восьмеричных чисел в языке Си.



Ввод и вывод

Любая программа — это автомат, предназначенный для обработки данных: получая на вход одну информацию, они в результате работы выдают некоторую другую. Хотя входящая и/или выходящая информация может быть и нулевой, т. е. попросту отсутствовать. Те данные, которые передаются программе для обработки — это её ввод, то, что она выдаёт в результате работы — вывод. Организация ввода и вывода для каждой программы — это задача операционной системы.

Каждая программа работает с данными определённого типа: текстовыми, графическими, звуковыми и т. п. Как, наверное, уже стало понятно из предыдущих лекций, основной интерфейс управления системой в Linux — это терминал, который предназначен для передачи текстовой информации от пользователя системе и обратно (см. лекцию Терминал и командная строка). Поскольку ввести с терминала и вывести на терминал можно только текстовую информацию, то ввод и вывод программ, связанных с терминалом1, тоже должен быть текстовым. Однако необходимость оперировать с текстовыми данными не ограничивает возможности управления системой, а, наоборот, расширяет их. Человек может прочитать вывод любой программы и разобраться, что происходит в системе, а разные программы оказываются совместимыми между собой, поскольку используют один и тот же вид представления данных — текстовый. Возможностям, которые даёт Linux при работе с данными в текстовой форме, и посвящена данная лекция.

«Текстовость» данных — всего лишь договорённость об их формате. Никто не мешает выводить на экран нетекстовый файл, однако пользы в том будет мало. Во-первых, раз уж файл содержит не текст, то не предполагается, что человек сможет что-либо понять из его содержимого. Во-вторых, если в нетекстовых данных, выводимых на терминал, случайно встретится управляющая последовательность, терминал её выполнит. Например, если в скомпилированной программе записано число 1528515121, оно представлено в виде четырёх байтов: 27, 91, 49 и 74. Соответствующий им текст состоит из четырёх символов ASCII: “ESC”, “[”, “1” и “J”, и при выводе файла на виртуальную консоль Linux в этом месте выполнится очистка экрана, так как “^[[1J” — именно такая управляющая последовательность для виртуальной консоли. Не все управляющие последовательности столь безобидны, поэтому использовать нетекстовые данные в качестве текстов не рекомендуется.

Что же делать, если содержимое нетекстового файла всё-таки желательно просмотреть (то есть превратить в текст)? Можно воспользоваться программой hexdump, которая выдаёт содержимое файла в виде шестнадцатеричных ASCII-кодов, или strings, которая показывает только те части файла, что могут быть представлены в виде текста:
[methody@localhost methody]$ hexdump -C /bin/cat | less

00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|

00000010 02 00 03 00 01 00 00 00 90 8b 04 08 34 00 00 00 |............4...|

00000020 e0 3a 00 00 00 00 00 00 34 00 20 00 07 00 28 00 |Ю:......4. ...(.|

. . .

00000100 00 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 |................|



00000110 04 00 00 00 2f 6c 69 62 2f 6c 64 2d 6c 69 6e 75 |..../lib/ld-linu|

00000120 78 2e 73 6f 2e 32 00 00 04 00 00 00 10 00 00 00 |x.so.2..........|

00000130 01 00 00 00 47 4e 55 00 00 00 00 00 02 00 00 00 |....GNU.........|

. . .


[methody@localhost methody]$ strings /bin/cat | less

/lib/ld-linux.so.2

_Jv_RegisterClasses

__gmon_start__

libc.so.6

stdout


. . .

[methody@localhost methody]$ strings -n3 /bin/cat | less

/lib/ld-linux.so.2

GNU


_Jv_RegisterClasses

__gmon_start__

libc.so.6

stdout


. . .
Пример 1. Использование hexdump и strings

В примере Мефодий, зная заранее, что текста будет выдано много, воспользовался конвейером “| less”, описанным в разделе Конвейер. С ключом “-C” утилита hexdump выводит в правой стороне экрана текстовое представление данных, заменяя непечатные символы точками (чтобы среди выводимого текста не встретилось управляющей последовательности). Мефодий заметил, что strings «не нашла» в файле /bin/cat явно текстовых подстрок “ELF” и “GNU”: первая из них — вообще не текст (перед ней стоит непечатный символ с кодом 7f, а после — символ с кодом 1), а вторая — слишком короткая, хоть и ограничена символами с кодом 0, как это и полагается строке в скомпилированной программе. Наименьшая длина строки передаётся strings ключом “-n”.

Перенаправление ввода и вывода

Для того, чтобы записать данные в файл или прочитать их оттуда, процессу необходимо сначала открыть этот файл (при открытии на запись, возможно, придётся предварительно создать его). При этом процесс получает дескриптор (описатель) открытого файла — уникальное для этого процесса число, которое он и будет использовать во всех операциях записи. Первый открытый файл получит дескриптор 0, второй — 1 и так далее. Закончив работу с файлом, процесс закрывает его, при этом дескриптор освобождается и может быть использован повторно. Если процесс завершается, не закрыв файлы, за него это делает система. Строго говоря, только в операции открытия дескриптора указывается, какой именно файл будет использоваться. В качестве «файла» используются и обычные файлы, и файлы-дырки (чаще всего — терминалы), и каналы, описанные в разделе Конвейер. Дальнейшие операции — чтение, запись и закрытие, работают с дескриптором, как с потоком данных, а куда именно ведёт этот поток, неважно.

Каждый процесс Linux получает при старте три «файла», открытых для него системой. Первый из них (дескриптор 0) открыт на чтение, это стандартный ввод процесса. Именно со стандартным вводом работают все операции чтения, если в них не указан дескриптор файла. Второй (дескриптор 1) — открыт на запись, это стандартный вывод процесса. С ним работают все операции записи, если дескриптор файла не указан в них явно. Наконец, третий поток данных (дескриптор 2) предназначается для вывода диагностических сообщений, он называется стандартный вывод ошибок. Поскольку эти три дескриптора уже открыты к моменту запуска процесса, первый файл, открытый самим процессом, будет, скорее всего, иметь дескриптор 3.
дескриптор

Описатель потока данных, открытого процессом. Дескрипторы нумеруются начиная с 0. При открытии нового потока данных его дескриптор получает наименьший из неиспользуемых в этот момент номеров. Три заранее открытых дескриптора: стандартный ввод (0), стандартный вывод (1) и стандартный вывод ошибок (2) процессу выдаются при запуске.


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

Стандартный вывод

"> Мефодий уже сталкивался с тем, что некоторые программы умеют выводить не только на терминал, но и в файл, например, info при указании параметрического ключа “-o” с именем файла выведет текст руководства в файл, вместо того, чтобы отображать его на мониторе. Даже если разработчиками программы не предусмотрен такой ключ, Мефодию известен и другой способ сохранить вывод программы в файле вместо того, чтобы выводить его на монитор: поставить знак “>” и указать после него имя файла. Таким образом Мефодий уже создавал короткие текстовые файлы (сценарии) при помощи утилиты cat (см. лекцию Доступ процессов к файлам и каталогам).
[methody@localhost methody]$ cat > textfile

Это файл для примеров.

^D

[methody@localhost methody]$ ls -l textfile



-rw-r--r-- 1 methody methody 23 Ноя 15 16:06 textfile
Пример 2. Перенаправление стандартного вывода в файл

От использования символа “>” возможности самой утилиты cat, конечно, не расширились. Более того, cat в этом примере не получила от командной оболочки никаких параметров: ни знака “>”, ни последующего имени файла. В этом случае cat работала как обычно, не зная (и даже не интересуясь!), куда попадут выведенные данные: на экран монитора, в файл или куда-нибудь ещё. Вместо того, чтобы самой обеспечивать доставку вывода до конечного адресата (будь то человек или файл), cat отправляет все данные на стандартный вывод (сокращённо — stdout).

Подмена стандартного вывода — задача командной оболочки (shell). В данном примере shell создаёт пустой файл, имя которого указано после знака “>”, и дескриптор этого файла передаётся программе cat под номером 1 (стандартный вывод). Делается это очень просто. В лекции Доступ процессов к файлам и каталогам было рассказано о том, как запускаются команды из оболочки. В частности, после выполнения fork() появляется два одинаковых процесса, один из которых — дочерний — должен запустить вместо себя команду (выполнить exec()). Так вот, перед этим он закрывает стандартный вывод (дескриптор 1 освобождается) и открывает файл (с ним связывается первый свободный дескриптор, т. е. 1), а запускаемой команде ничего знать и не надо: её стандартный вывод уже подменён. Эта операция называется перенаправлением стандартного вывода. В том случае, если файл уже существует, shell запишет его заново, полностью уничтожив всё, что в нём содержалось до этого. Поэтому Мефодию, чтобы продолжить записывать данные в textfile, потребуется другая операция — “>>”.

>">

[methody@localhost methody]$ cat >> textfile

Пример 1.

^D

[methody@localhost methody]$ cat textfile



Это файл для примеров.

Пример 1.

[methody@localhost methody]$



Поделитесь с Вашими друзьями:
1   ...   5   6   7   8   9   10   11   12   ...   16


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал