Жизненный цикл процесса linux

3.2. Жизнь процесса

3.2. Жизнь процесса

С точки зрения ядра процесс представляет собой запись в таблице процессов. Эта запись содержит данные, существующие в течение всего времени жизни процесса, и сведения о его состоянии. Размер таблицы процессов позволяет запускать несколько сотен процессов одновременно. Другая важная информация о процессе — например, таблица всех открытых процессом файлов — хранится в его адресном пространстве. Запись в таблице процессов и пространство процесса вместе составляют контекст, или окружение, процесса. В него входят:

? PID — идентификатор процесса. Он принудительно назначается планировщиком при запуске процесса.

? PPID — идентификатор родительского процесса (о порождении процессов — дальше в этом же параграфе).

? TTY — имя управляющего терминала (терминал, с которого запущен процесс).

? WD — текущий каталог процесса, от которого отсчитываются относительные пути.

? RID, RGID — реальные ID и групповой ID пользователя, запустившего процесс.

? EUID, EGID — эффективные ID и GID: см. п.2.1.4.8.

? NICE — показатель уступчивости. Процессы выполняются в режиме разделения времени, то есть время центрального процессора делится между готовыми к выполнению процессами с учетом их приоритета. Чем выше показатель уступчивости, тем ниже приоритет.

? Переменные окружения.

Системные вызовы fork() и exec() или как размножаются процессы

Каждый процесс порождается другим процессом, использующим для этого системный вызов fork(). Таким образом, структура процессов, подобно файловой системе, древовидна. Корнем этого дерева служит init — процесс инициализации системы. Он запускается ядром первым, получает идентификатор 1 и порождает еще несколько процессов (сколько и каких, можно узнать из его конфигурационного файла /etc/inittab), которые, в свою очередь, при участии пользователя порождают другие процессы.

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

Может случиться и так, что процесс выполняет вызов exec() без fork(): тогда не возникает нового процесса, но в старом начинает выполняться другая программа. Например, программа login выполняется с привилегиями суперпользователя, поскольку ей нужен доступ к файлу паролей. Проверив пароль, она устанавливает себе права зарегистрировавшегося пользователя и выполняет вызов exec(), замещая свой код кодом командной оболочки. После этого из командной оболочки изменить свои привилегии обратно на root нельзя, потому что кода программы login в текущем процессе уже нет.

Рис. 3.3. Как размножаются процессы

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

Снимок протекающих в системе процессов — команда ps

Моментальный снимок протекающих в системе процессов можно посмотреть с помощью команды ps (process status). Без аргументов она покажет список процессов, связанных с текущей консолью (или виртуальным терминалом). Список возможных ключей команды можно, как обычно, получить по команде ps —help. Вот некоторые полезные из них:

? -p : только процессы с указанными ID;

? -u : только запущенные указанными пользователями;

? -е: все процессы в системе;

? -f: полная форма вывода;

? -Н: вывод иерархии процессов в форме дерева.

Рис. 3.4. Фрагмент иерархии процессов

Динамика процессов — команда top

Представление о динамике процессов дает команда top. Она выводит список процессов, отсортированный по количеству запятой памяти или использованного процессорного времени, и обновляет его через указанные промежутки времени (по умолчанию через каждые 3 секунды).

Процессы делятся на три категории:

? Системные. Они порождаются ядром особым образом в процессе загрузки и выполняют системные функции (например, планирование процессов или смену страниц виртуальной памяти). Выполняемая ими программа берется не из исполняемого файла, а является частью ядра.

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

? Демоны. Запускаются после инициализации ядра. Выполняются в фоновом режиме, не связаны ни с одним пользователем, обеспечивают работу различных служб (например, управление сетью). Главным демоном считается init — процесс инициализации системы.

Название «демон» (daemon) не имеет ничего общего с потусторонними существами: это просто сокращение от Disk And Execution MONitor.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Читайте также

Жизнь до блога

Жизнь до блога Сфера влияния и сфера забот В «Семи навыках высокоэффективных людей» Стивен Кови вводит понятия «круг влияния» и «круг забот». Если рассматривать их в трехмерном мире, то круги становятся сферами. Чтобы блогосфера не превратилась для вас в сферу забот, вы

Жизнь с блогом

Жизнь с блогом Важное и несрочное дело Блогородная репутация Метки: репутацияКогда компания обычно задумывается над своей репутацией? Как правило, когда уже нет времени на ее исправление: в кризисной ситуации, или при усилившейся конкуренции, или перед изменением

Жизнь

Жизнь В зависимости от правил администрирования домена первого уровня возможна регистрация имен на различные периоды времени. Например, в домене COM можно регистрировать имена на срок от одного года до десяти лет. Обычно в течение первых 30–60 дней после регистрации смена

7.3.2. Концепции, касающиеся основных средств производственного процесса организации Основные средства производственного процесса организации (ППО)

7.3.2. Концепции, касающиеся основных средств производственного процесса организации Основные средства производственного процесса организации (ППО) Организация устанавливает и сопровождает набор основных средств производственного процесса, как показано на рис. 4.1. К

Игра» Жизнь»

Игра» Жизнь» Исходный файл: gameoflife.fla Игра «Жизнь» известна как результат серьезных разработок в области искусственного интеллекта и одновременно как популярная игра. Она была изобретена математиком Джоном Конвэйем и приобрела известность благодаря опубликованной в 1970

Жизнь насекомых

Жизнь насекомых Вряд ли в далеких сороковых годах инженеры, доставшие из чрева компьютера Mark II виновницу замыкания — крохотную мошку, могли предвидеть, какая судьба уготована брошенному ими мимоходом словечку «bug». В наши дни, когда не в меру расплодившиеся компьютерные

«Жизнь» в Интернете

«Жизнь» в Интернете Билл Гейтс и Рей Оззи (новый технический директор Microsoft) обратились к сотрудникам с призывом, практически повторяющим строки нашей известной песни: «Вставай, страна огромная, вставай на смертный бой:». Все на приступ Интернета. Большая Игра в

Жизнь без прокладки

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

Утопия и жизнь

Утопия и жизнь Автор: Киви БердЖурналисты английской газеты Daily Mail провели любопытное исследование нынешних масштабов государственной слежки за населением. Для максимальной выразительности, вероятно, в качестве объекта анализа была выбрана квартира Джорджа Оруэлла на

Наука и жизнь

Наука и жизнь Тибетский горючий лёд обогреет Китай Михаил Карпов После такого заголовка сразу же представляются огромные грузовики, гружёные льдом и снующие повсюду предприимчивые китайцы. На самом деле, всё прозаичнее: китайские власти планируют начать разработку

Наука и жизнь

Наука и жизнь «Великое объединение» для нейтронных звезд Сергей Попов (ГАИШ МГУ) Опубликовано 12 мая 2010 года В современной физике высоких энергий есть такое важное и красивое понятие, как «Великое объединение». Это та самая «теория всего» или

Лучшая жизнь в трехмерном онлайне: Жизнь в метаверсе как часть «просто жизни»

Лучшая жизнь в трехмерном онлайне: Жизнь в метаверсе как часть «просто жизни» Автор: Анатолий ЛевенчукЯ не буду даже обсуждать многопользовательские онлайн-игры — где есть понятие квеста, где есть геймплей. Я буду обсуждать метаверсы — многопользовательские

Источник

Linux: о жизненном цикле процессов и разграничении доступа

В статье описан жизненный цикл процессов и приведены особенности, возникающие при разработке средств разграничения доступа в ОС Linux. Предлагается способ «отслеживания» процессов ОС для однозначного и точного определения субъекта доступа в момент получения доступа к объектам ОС.

Linux, разграничение доступа, fork, exec, setuid

Linux: process life cycle and access control

Author describes life cycle of processes and singularities arising during development of tools for access control in Linux operating systems. Article provides method of «tracking» processes for unambiguous and precise definition of subject which gains access to objects in operating system.

Linux, access control, fork, exec, setuid

В общем случае для корректной реализации системы защиты информации от несанкционированного доступа (СЗИ НСД) в Linux вне зависимости от реализуемой политики разграничения доступа (дискреционная, мандатная или любая другая) ко всему прочему, свойственному только ОС на базе ядра Linux [1, 2, 3, 4], необходимо для любого типа доступа к объектам ОС ответить на главный вопрос — какой именно субъект доступа в данный момент осуществляет доступ? На первый взгляд этот вопрос может показаться не столь сложным, однако тут есть множество ньюансов.

Итак, субъектом доступа всегда является процесс ОС, который выполняется от имени некоторого субъекта доступа — пользователя ОС, которому соответствует некоторый уникальный идентификатор (UID, User identifier). У каждого процесса на уровне ядра ОС существует описывающая его структура task_struct, в которой содержатся такие значения как реальный и эффективный UID (для версий ядра Linux >= 2.6.29 эти значения перенесены в структуру cred внутри структуры task_struct). Не вдаваясь в отличия этих двух UID-ов, отметим только то, что в зависимости от их значений процесс выполняется от имени того или иного пользователя ОС.

Таким образом, в общем случае присутствие определенного пользователя в ОС (т. е. пользователя, прошедшего процедуру идентификации и аутентификации и имеющего незавершенные задачи или запущенный интерактивный шелл) означает наличие хотя бы одного процесса с UID, соответствующим UID-у этого пользователя.

Жизненный цикл процессов ОС

Какой UID имеют процессы изначально? Откуда возникают процессы с различными UID?

На самом раннем этапе загрузки ОС Linux, а именно, в момент загрузки ядра создается самый первый процесс — swapper или sched (так называемый процесс 0, процесс имеющий Process ID/PID = 0). Этот процесс, вообще говоря, нельзя считать реальным процессом, скорее это функция ядра ОС, ответственная за организацию управления памятью и некоторые другие возможности. В ходе дальнейшей загрузки ядра ОС (start_kernel()) запускается по сути первый процесс пользовательского режима init, который имеет PID = 1. Этот процесс в дальнейшем является родителем всех процессов, запускаемых в ОС (PID-ы всех остальных процессов нефиксированы), в т. ч. и процессов реальных пользователей. Само собой по умолчанию и процесс swapper/sched, и init имеют UID = 0 (т. е. выполняются от имени пользователя root в ОС Linux).

Сами процессы в ходе своей жизни могут пребывать в следующих состояниях (рис. 1): состояние выполнения (running), состояние сна (uninterruptible/interruptible sleep), состояние остановки выполнения (stopped), zombie-состояние.

Рисунок 1: жизненный цикл процесса

При этом в процессе выполнения каждый процесс может создавать новые процессы (child process), по отношению к которым он будет предком-родителем, т. е. parent process (рис. 2). Эти новые процессы могут запускать на выполнение другие задачи (fork()&exec()) или выполняться дальше (fork()), с возможностью порождения других процессов в обоих случаях.

Рисунок 2: создание новых процессов (fork() и fork()&exec())

Таким образом, все процессы ОС можно представить в виде дерева, корнем которого является процесс init. Необходимо отметить, что при создании child process наследуют большинство параметров от своего предка-родителя, в т. ч. и UID. Однако, далеко не все процессы даже во время загрузки ОС Linux будут постоянно иметь UID = 0, наследую его от процесса init.

Существует возможность изменить текущий UID процесса с помощью системного вызова setuid(). Так, в ходе загрузки ОС Linux, некоторые процессы будут иметь UID, соответствующий некоторым сервисам/демонам для которых существуют учетные записи в ОС (например, apache, mysql и другие учетные записи, у которых обычно в /etc/passwd вместо реального шелла прописаны /sbin/nologin или /bin/false). Также в ходе штатной процедуры идентификации и аутентификации в ОС (login, gdm и т. п.) UID некоторого процесса, который в дальнейшем запустит шелл или сессию пользователя, будет заменен на UID реального пользователя.

Контроль создания и выполнения процессов в СЗИ НСД

Чтобы в любой момент времени иметь возможность однозначно ответить на вопрос «Какой именно субъект доступа осуществляет доступ?» и при этом реализовывать некоторое внешнее по отношению к ОС СЗИ НСД в ОКБ САПР в рамках продукта ПАК СЗИ НСД «Аккорд-Х» было решено реализовать следующее:

1. Начиная с момента загрузки СЗИ НСД на раннем этапе загрузки ОС помечать все существующие и вновь создаваемые (во время операций fork() и/или exec()) процессы собственными дескрипторами безопасности. В таком случае в каждый момент времени в ОС не будет существовать процессов, которые не помечены каким-либо дескриптором безопасности;

2. Для всех уже существующих процессов ОС на момент загрузки ставить в соответствие дескрипторы с субъектом доступа типа shadow с именем root (это специальный субъект доступа, от которого выполняется процесс init и большинство процессов во время загрузки ОС);

3. Во время выполнения setuid() можно изменять субъект доступа в дескрипторе безопасности. При этом необходимо придерживаться определенных правил смены субъектов доступа, которые описаны ниже.

В продукте ПАК СЗИ НСД «Аккорд-Х» на данный момент используется 2 типа субъектов доступа:

• user — реальные пользователи ОС, которые могут проходить процедуру идентификации и аутентификации;
• shadow — псевдо-пользователи, от имени которых могут выполняться определенные процессы в ОС, но которые не могут проходить процедуру идентификации и аутентификации (примером таких пользователей являются, например, различные сервисы/демоны).

В связи с этим логика условий и правил для смены субъекта доступа в рамках setuid() будет разной в зависимости от того, какой тип субъекта доступа соответствует текущему процессу:

• Изменять субъект доступа типа user на другой субъект доступа типа user можно только в случае успешного прохождения процедуры идентификации/аутентификации в СЗИ НСД одним из процессов-предков текущего процесса и при условии, что UID в setuid() совпадает с UID из процедуры идентификации/аутентификации. Т. к. в разных дистрибутивах ОС Linux процедуры идентификации/аутентификации и, собственно, смены UID-а могут призводить разные, даже достаточно далекие «в родстве», процессы — необходимо вместе с дескриптором безопасности наследовать (при операциях fork() и fork()&exec()) от процесса-родителя в т. ч. и информацию о пользователе, который осуществил успешную процедуру идентификации / аутентификации.;
• Изменять субъект доступа типа shadow после идентификации/аутентификации в СЗИ НСД:
  • можно на субъект доступа типа user, если UID в setuid() совпадает с UID из процедуры идентификации и аутентификации (такая замена является следствием обычного логина пользователя в ОС);
  • необходимона другой субъект доступа типа shadow, если текущий и заменяющий UID оба равны 0 и UID в setuid() не совпадает с UID из процедуры идентификации и аутентификации.

• Изменять субъект доступа типа shadow без идентификации/аутентификации в СЗИ НСД:
  • на субъект доступа типаuserнельзя;
  • можно на другой субъект доступа типаshadow, если такой субъект доступа shadow существует и у текущего субъекта доступа есть разрешение делать setuid().

В соответствии с приведенными правилами выполнения setuid() в системе при использовании СЗИ НСД должно присутствовать некоторое количество пользователей типа shadow. Для корректного создания таких пользователей shadow (сервисов, демонов и т. п.) необходимо предусмотреть режим работы СЗИ НСД, в котором все переключения на пользователей типа shadow будут фиксироваться и заноситься в журнал (т.н. лог работы СЗИ НСД в «мягком» режиме). В дальнейшем из журнала необходимо заносить таких пользователей типа shadow в список пользователей СЗИ НСД.

«Мягкий» режим работы является средством обучения СЗИ НСД, поэтому все субъекты доступа типа shadow, которые не были отображены в журнале и, соответственно, не были созданы в самом СЗИ НСД, не смогут корректно работать в обычном режиме работы с включенными политиками разграничения доступа. В связи с этим в «мягком» режиме работы СЗИ НСД желательно достаточно точно эмулировать работу пользователей ОС с целью создания как можно более точного соответствия/наличия в системе пользователей типа shadow. В противном случае при возникновении каких-либо ошибок придется повторно «дообучать» СЗИ НСД при дальнейшем использовании.

Как было отмечено выше, желательно для всех пользователей типа shadow завести параметры с разрешением/запрещением делать операции setuid() (т.н. setuid_ability) и делать setuid() на UID = 0 (т.н. setuid_root_ability). Эти параметры призваны исключить возможность эскалации привилегий и должны запрещать все действия setiud(), если выбранному субъекту доступа типа shadow в своей работе не требуется переключения на другие учетные записи (как правило, это требуется всего нескольким shadow, например при входе пользователей для открытия /etc/passwd и т. п.).

Заключение

В заключении хотелось бы отметить, что описанный выше способ является не единственным способом для корректной «пометки» процессов соответствующими дескрипторами безопасности. Вторым, более простым вариантом можно считать аналогичную маркировку процессов в начале работы СЗИ НСД и при всех операциях fork() и/или exec(), но со сменой субъекта доступа на этапе успешного прохождения процедуры идентификации и аутентификации (т. е. по сигналу от специального PAM-модуля), без учета каких-либо событий setuid(). Этот способ является вполне корректным, но в меньшей степени соответствует реальному поведению процессов, т. к., например, после прохождения идентификации и аутентификации, процессы, помеченные дескриптором зашедшего пользователя, будут производить множество системных действий, на которые пользователю, вообще говоря, нельзя выдавать права доступа (доступ к /etc/passwd, различным сервисам, активирующимся при старте графической пользовательской сессии и т. д.).

Рассмотренный же в данной статье способ «отслеживания» процессов ОС является по сути практически полноценной эмуляцией реального поведения процессов и не требует назначения пользователю каких-либо лишних прав в системе. Т. к. часто для защиты ОС используются внешние по отношению к ОС СЗИ НСД — такая эмуляция необходима, т. к. без неё нельзя с достаточной степенью уверенности сказать, что определенный доступ осуществил в действительности тот или иной пользователь, а не другой процесс/сервис/демон ОС.

Литература

1. Каннер А. М. Linux: о доверенной загрузке загрузчика ОС // Безопасность информационных технологий. М., 2013. N 2. С. 41–46.
2. Каннер А. М. Linux: объекты контроля целостности // Информационная безопасность. Материалы XIII Международной конференции. Таганрог., 2013. Часть 1. С. 112–118. 14.
3. Каннер А. М. Linux: к вопросу о построении системы защиты на основе абсолютных путей к объектам доступа // Информационная безопасность. Материалы XIII Международной конференции. Таганрог., 2013. Часть 1. С. 118–121. 15.
4. Каннер А. М., Ухлинов Л. М. Управление доступом в ОС GNU/Linux // Вопросы защиты информации. Научно-практический журнал. М., 2012. № 3. С. 35–38.

Автор: Каннер А. М.

Дата публикации: 01.01.2014

Библиографическая ссылка: Каннер А. М. Linux: о жизненном цикле процессов и разграничении доступа // Вопросы защиты информации: Научно-практический журнал. М.: ФГУП «ВИМИ», 2014. Вып. 4 (107). С. 37–40.

Источник