Что за адрес root

На всех сайтах, чей код разбираю, есть в head’е всегда подобный код:

:root a[href^="http://click.hotlog.ru/"], :root a[href*="//top.mail.ru/jump?"], :root [title="uCoz Counter"], :root .min-width-normal > #popup_container ~ #fade, :root .min-width-normal > #popup_container, :root body > div[id^="dV"][style^="width"][style*="height"][style*="position"][style*="fixed"][style*="overflow"][style*="z-index"][style*="background"], :root a[href*="/ulike.farm"], :root .stat_pixel_yes[onclick][class*="_layout_"][class*="_format_"], :root .serp-list_left_yes[aria-label="Результаты поиска"] > .t-construct-adapter__adv, :root .serp-list + .serp-list > .serp-adv__head ~ .serp-item, :root .i-bem.b-timetable__row[onclick*="awaps"], :root .content__right > .z-market_right_yes, :root body > #__promo-sticky-button__, :root .app.blog-post-page .secondary-header-ad-block, :root div[style="width: 252px; height: 450px; position: fixed; right: 0px; top: 0px; overflow: hidden; z-index: 10000;"], :root object[data^="blob"], :root noindex > .search_result[class*="search_result_"], :root img[width="468"][height="60"], :root img[width="160"][height="600"], :root iframe[src*="utraff.com"], :root iframe[src*="ads.exosrv.com"], :root iframe[src*="/mixadv_"], :root iframe[src*="/3647.tech"], :root iframe[id^="republer"], :root div[id^="zcbclk"], :root div[id^="trafmag_"], :root div[id^="tizerws_"], :root div[id^="smi2adblock_"], :root div[id^="sblock_inform_"], :root div[id^="rtn4p"], :root div[id^="news_nest_net_ru"], :root div[id^="news_nest_msk_ru"], :root div[id^="news_2xclick_ru_"], :root div[id^="join_informer_"], :root div[id^="gnezdo_ru_"], :root div[id^="b_tz_"], :root div[id^="ads_games_"], :root div[id^="admixer_"], :root div[id^="M"][id*="Composite"], :root div[id^="DIV_DA_"], :root div[id^="Crt-"][style], :root div[id*="Teaser_Block"], :root div[class^="da-ya-widget"], :root div[class*="spklw"][data-type="ad"], :root div[class*="relap"][class*="-rec-item"], :root a[onclick*="trtkp.ru"], :root a[onclick*="offergate-amigo"], :root a[onclick*="n284adserv.com"], :root a[href^="https://www.juicer.io?referrer="], :root a[href^="https://msetup.pro"], :root a[href^="https://kshop"][href*=".pro/"], :root a[href^="http://trafmaster.com"], :root a[href^="http://traderstart.mirtesen.ru"], :root a[href^="http://reals-story.ru/"], :root a[href^="http://luckiestclick.com/goto."], :root a[href^="http://kshop.biz/"], :root a[href^="http://datxxx.com"], :root a[href^="http://browserload.info/"], :root a[href^="http://apytrc.com/click/"], :root a[href^="http://amigodistr.ru/"], :root a[data-hren="http://advert.mirtesen.ru/"], :root a[href*="zdravo-med.ru"], :root a[href*="trklp.ru"], :root a[href*="traflabs.xyz"], :root a[href*="trafgid.xyz"], :root div[id^="CGCandy"], :root a[href*="tptrk.ru"], :root a[href*="torrentum.ru"], :root a[href*="top-info24.ru"], :root a[href*="shakesclick.com"], :root a[href*="shakescash.com"], :root a[href*="shakes.pro"], :root a[href*="sapmedia.ru"], :root a[href*="sandratand.ru"], :root a[href*="problogrus.ru"], :root a[href^="https://homyanus.com"], :root a[href*="please-direct.me"], :root a[href*="please-direct.com"], :root a[href*="sviruniversal.com/"], :root a[href*="octoclick.net"], :root a[href*="marketgid.com/"], :root a[href*="navaxudoru.com"], :root a[href*="lifebloggersz.ru"], :root a[href*="intovarro.ru"], :root a[href*="https://relap.io/r?"], :root a[href*="herrabjec.pro"], :root a[href*="goodtrack.ru"], :root a[href*="goext.info"], :root a[href*="gocdn.ru"], :root a[href*="go.ad2up.com"], :root a[href*="ftpglst.com"], :root a[href*="flylinks.pw"], :root a[href*="films.ws"], :root a[href*="filebase.me"], :root a[href*="cpl11.ru"], :root a[href*="cpl1.ru"], :root a[href*="cpagetti1.com"], :root a[href*="cmsmodnews.com"], :root a[href*="bubblesmedia.ru/sb/clk/"], :root a[href*="blogers-story.ru"], :root a[href*="shakesin.com"], :root a[href*="bgrndi.com"], :root a[href*="beststbuy.ru"], :root a[href*="bestforexplmdb.com"], :root a[href*="best-zdrav.ru"], :root a[href*="best-zdorovye.ru"], :root a[href*="beauty-list.ru"], :root a[href*="medinforms.ru"], :root a[href*="awesomeredirector"], :root a[href*="amigo-biz.ru/ads/click"]

И так далее
Вследствие этого у меня возник вопрос: что это за код, почему код такого типа есть на всех сайтах и за что он, собственно, отвечает?

Да, знаю, вопрос, похоже, очень новичковый, но тем не менее прошу не ругаться

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

«Пользовательские пространства имен изолируют связанные с безопасностью идентификаторы и атрибуты. В частности, ID пользователей, групповые ID, корневой каталог, ключи и возможности. Пользователь процесса и групповые ID внутри и вне user namespace* могут отличаться. Если конкретно, то процесс может иметь обычный непривилегированный UID вне этого пространства имен и в то же время иметь UID=0 внутри него».

*Прим. пер.: С целью облегчить чтение по ходу статьи выражения «пространство имен» и «namespace» будут использоваться попеременно.

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

cryptonite@cryptonite:~ $uname -a
Linux qb 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
# корневое user namespace
cryptonite@cryptonite:~ $id
uid=1000(cryptonite) gid=1000(cryptonite) groups=1000(cryptonite) ...
cryptonite@cryptonite:~ $unshare -U /bin/bash
nobody@cryptonite:~$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

«Если UID не имеет отображения внутри пространства имен, тогда системные вызовы, возвращающие пользовательские ID, возвращают значение, определенное в файле /proc/sys/kernel/overflowuid. В стандартной системе по умолчанию этим значением является 65534. Изначально, user namespace не имеет отображения UID, поэтому все UID внутри него отображаются в это значение».

На вторую же часть вопроса ответ такой – для ситуаций, когда процессу нужно выполнять общесистемные операции, существует динамическое отображение UID.

#внутри user namespace создаем файл
nobody@cryptonite:~$ touch hello
nobody@cryptonite:~ $ls -l hello
-rw-rw-r-- 1 nobody nogroup 0 Jun 29 17:06 hello

cryptonite@cryptonite:~ $ls -al hello
-rw-rw-r-- 1 cryptonite cryptonite 0 Jun 29 17:09 hello
# под каким UID выполняется процесс, создавший этот файл?
cryptonite@cryptonite:~ $ps l | grep /bin/bash
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 1000 18609 3135 20 0 19648 5268 poll_s S+ pts/0 0:00 /bin/bash

cryptonite@cryptonite:~ $unshare -U /bin/bash
nobody@cryptonite:/$ ls -al
drwxr-xr-x 20 nobody nogroup 4096 Jun 12 17:25 .
drwxr-xr-x 20 nobody nogroup 4096 Jun 12 17:25 ..
lrwxrwxrwx 1 nobody nogroup 7 Jun 12 17:21 bin -> usr/bin
drwxr-xr-x 5 nobody nogroup 4096 Jun 25 10:23 boot
...
nobody@cryptonite:~$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
nobody@cryptonite:~$ touch /heloo.txt
touch: cannot touch '/heloo.txt': Permission denied

Отображение UID и GID

Некоторые процессы должны запускаться под действующим UID=0, чтобы предоставить свои службы и иметь возможность взаимодействовать с файловой системой ОС. Одним из типичных случаев при использовании пользовательских пространств имен является определение отображений. Выполняется оно при помощи файлов /proc/‹PID
›/uid_map и /proc/‹PID›/gid_map в следующем формате:

ID-внутри-ns ID-вне-ns длина

Некоторые важные правила из документации Linux:

«Если два процесса находятся в одном пространстве имен, тогда ID-вне-ns интерпретируется как UID (GID) в родительском user namespace идентификатора (PID) процесса. Здесь типичным случаем является процесс, производящий запись в собственный файл отображения (/proc/self/uid_map или /proc/self/gid_map)».

Если два процесса находятся в разных пространствах имен, то ID-вне-ns интерпретируется как UID (GID) в user namespace процесса, открывающего /proc/PID/uid_map (/proc/PID/gid_map). Тогда записывающий процесс определяет отображение относительно его собственного user namespace.

Хорошо, проверим все это:

# добавление отображения для процесса оболочки с PID=18609 в user namespace
cryptonite@cryptonite:~ $echo "0 1000 65335" | sudo tee /proc/18609/uid_map
0 1000 65335
cryptonite@cryptonite:~ $echo "0 1000 65335" | sudo tee /proc/18609/gid_map
0 1000 65335
# возвращаемся в оболочку в user namespace
nobody@cryptonite:~$ id
uid=0(root) gid=0(root) groups=0(root)
# создаем файл
nobody@cryptonite:~$ touch hello
# возвращаемся в корневое пространство имен
cryptonite@cryptonite:~ $ls -l hello
-rw-rw-r-- 1 cryptonite cryptonite 0 Jun 29 17:50 hello

Процесс внутри пользовательского пространства имен считает, что его действительный UID является корневым, но в вышестоящем (корневом) пространстве имен его UID такой же, как у создавшего его процесса (zsh с UID=1000). Вот иллюстрация для вышеприведенного фрагмента кода:

В более общем виде процесс переотображения показан здесь:

# в корневом user namespace
cryptonite@cryptonite:~ $ls -l
total 0
-rw-rw-r-- 1 cryptonite cryptonite 0 Jul 2 11:07 hello
# в дочернем user namespace
nobody@cryptonite:~/test$ ls -l
-rw-rw-r-- 1 root root 0 Jul 2 11:07 hello

Инспектирование текущих отображений процесса

Файлы /proc/‹PID
›/uid_map и /proc/‹PID›/gid_map также можно использовать для инспектирования отображения заданного процесса. Это инспектирование происходит относительно пользовательского пространства имен, в котором процесс находится.
Здесь есть два правила:

• Если процесс внутри одного namespaceинспектирует отображение другого процесса в том же namespace, то он увидит отображение на родительское user namespace.
• Если процесс инспектирует отображение процесса из другого namespace, то он увидит отображение относительно его собственного отображения.

Все это немного запутывает, так что посмотрим наглядно:

# в оболочке номер 1
cryptonite@cryptonite:~ $unshare -U /bin/bash
nobody@cryptonite:~$
# в оболочке номер 2 определяем переотображение пользователя
cryptonite@cryptonite:~ $echo "0 1000 65335" | sudo tee /proc/6638/uid_map
0 1000 65335
# восприятие изнутри переотображенного namespace
nobody@cryptonite:~ $cat /proc/self/uid_map 0 1000 65335
nobody@cryptonite:~ $id
uid=0(root) gid=65534(nogroup) groups=65534(nogroup)
# теперь в 3-й оболочек создаем новое user namespace
cryptonite@cryptonite:~ $unshare -U /bin/sh
$
# во 2-й оболочке определяем новое отображение оболочки sh
cryptonite@cryptonite:~ $echo "200 1000 65335" | sudo tee /proc/7061/uid_map
# возвращаемся в оболочку sh
# восприятие собственного переотображения
$ cat /proc/self/uid_map 200 1000 65335
# восприятие переотображения оболочки bash
$ cat /proc/6638/uid_map 0 200 65335

«Если процесс, открывающий файл, находится в том же user namespace, что и PID этого процесса, тогда ID-вне-ns определяется относительно родительского user namespace. Если процесс, открывающий файл, находится в другом user namespace, тогда ID-вне-ns определяется относительно user namespace этого открывающего файл процесса».

Существуют кое-какие важные правила по определению переотображения внутри файла:

«Определение переотображения – это одноразовая операция для каждого пространства имен: мы можем выполнить только одну операцию записи (которая может содержать несколько разделенных пустыми строками записей) в файл uid_map или ровно один из процессов в user namespace. Более того, сейчас в файл можно записать не более пяти строк».

«Файл /proc/PID/uid_map принадлежит UID, который создал пространство имен, и делать запись в него может только этот пользователь (или привилегированный). При этом должны быть выполнены следующие требования:

• записывающий процесс должен иметь возможность CAP_SETUID (CAP_SETGID для gid_map) в user namespace своего PID;
• независимо от возможностей, записывающий процесс должен находиться либо в user namespace PID процесса, либо в ближайшем родительском user namespace идентификатора процесса».

Выдержка из документации:

«Когда создается user namespace, первый процесс в нем получает полный набор возможностей для данного namespace. Это позволяет ему выполнять любые необходимые инициализации до создания других процессов в этом namespace. Причем несмотря на то, что новый процесс имеет весь набор возможностей в новом user namespace, в родительском namespace он их не имеет совсем. Это верно независимо от полномочий и возможностей процесса, вызывающего clone(). В частности, даже если корень задействует clone(CLONE_NEWUSER), результирующий дочерний процесс не будет иметь возможностей в родительском namespace».

cryptonite@cryptonite:~ $ ./main
Capabilities of child process viewed from parent namespace =
Capabilities of child process viewed from child namespace =ep
Namespaced process eUID = 65534; eGID = 65534;

Пространства имен mount (MNT) позволяют создавать деревья файловых систем под отдельные процессы, тем самым создавая представления корневой файловой системы. Linux поддерживает структуру данных для всех различных файловых систем, смонтированных в системе. Эта структура является индивидуальной для каждого процесса, а также пространства имен. В нее входит информация о том, какие разделы дисков смонтированы, где они смонтированы и тип монтирования (RO/RW).

cryptonite@cryptonite:~ $cat /proc/$$/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
...

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

Определение mount namespace также позволяет процессу изменять свой корень, то есть проявлять поведение, аналогичное системному вызову chroot. Разница здесь в том, что chroot привязан к текущей структуре файловой системы, и все изменения (монтирование, размонтирование) в среде с измененным корнем влияют на всю файловую систему. В случае с пространствами имен такое невозможно, поскольку вся структура виртуализирована, тем самым обеспечивая полную изоляцию исходной файловой системы для монтирования/размонтирования.

# находим ID пространства имен текущего процесса оболочки
cryptonite@cryptonite:~ $readlink /proc/$$/ns/mnt
mnt:[4026531840]

Схема устройства mount namespace:

Схема оформлена Махмудом Ридваном из Toptal

# создаем новое namespace и входим в него
cryptonite@cryptonite:~ $sudo unshare -m /bin/bash
root@cryptonite:/home/cryptonite# mount -t tmpfs tmpfs /mnt
root@cryptonite:/home/cryptonite# touch /mnt/hello
# во втором терминале <=> в отдельном mount namespace
cryptonite@cryptonite:~ $ls -al /mnt
total 8
drwxr-xr-x 2 root root 4096 Feb 9 19:47 .
drwxr-xr-x 20 root root 4096 Jun 8 23:24 .
# изменения не отразили другое mount namespace

Здесь мы видим, что процессы в изолированном mount namespace могут создавать под собой различные точки монтирования и файлы, не отражая родительское mount namespace.

Монтирование и размонтирование каталогов отражает файловую систему ОС. В классической ОС Linux эта система представлена в виде дерева. Как видно из схемы выше, создание различных пространств имен технически приводит к созданию виртуальных структур деревьев для каждого процесса. Так вот, эти структуры могут быть общими.

Из документации Linux:

«Ключевое преимущество общих поддеревьев заключается в возможности автоматического, управляемого распространения событий монтирования и размонтирования между пространствами имен. Это означает, к примеру, что монтирование оптического диска в одном mount namespace может запустить монтирование этого диска во всех пространствах имен».

Основной составляющей поддеревьев являются теги для каждой точки монтирования, сообщающие, что произойдет при добавлении/удалении точек монтирования, присутствующих в разных mount namespace. Добавление/удаление точек монтирования запускает событие, которое распространяется в так называемых одноранговых группах. Одноранговая группа – это набор vfsmounts (точек монтирования виртуальной файловой системы), которые распространяют события монтирования и размонтирования между собой.

Точки монтирования бывают четырех видов:

• MS_SHARED: разделяет события монтирования/размонтирования с другими точками монтирования, входящими в ее «одноранговую группу». Когда под этой точкой монтирования добавляется/удаляется другая точка, это изменение распространяется на всю группу, в результате чего монтирование/размонтирование также происходит под каждой из одноранговых точек. Распространение также происходит и в обратном направлении, в следствии чего события монтирования/размонтирования в однорангововых точках монтирования распространяются на эту точку.
• MS_PRIVATE: противоположна общей точке монтирования, то есть не распространяет события на одноранговых соседей и не получает аналогичные события от них.
• MS_SLAVE: находится между общим видом и закрытым. Подчиненная точка монтирования имеет мастера – общую группу пиров, чьи члены распространяют события монтирования/размонтирования на подчиненную точку. Однако такая точка, в свою очередь, на мастер-группу пиров события не распространяет.
• MS_UNBINDABLE – не получает и не передает никакие события распространения и роль привязки монтирования выполнять не может.

Состояние точки монтирования является индивидуальным для каждой такой точки. То есть, если у вас есть, например, / и boot, то вам нужно отдельно применить нужное состояние для каждой точки монтирования. Предлагаю немного поэкспериментировать.

# создаем точку монтирования и описываем ее как общую для пиров (дочерних пространств # имен)
cryptonite@cryptonite:~ $mkdir X
cryptonite@cryptonite:~ $sudo mount --make-shared -t tmpfs tmpfs X/
# входим в новое mount namespace
cryptonite@cryptonite:~ $sudo unshare --mount /bin/bash
root@cryptonite:/home/cryptonite#
# теперь создадим еще одну точку монтирования в родительском mount namespace
cryptonite@cryptonite:~ $mkdir Y; mount --make-shared -t tmpfs tmpfs Y/
# возвращаемся в оболочку внутри mount namespace
root@cryptonite:/home/cryptonite/X# mount | grep Y
tmpfs в /home/cryptonite/X/Y type tmpfs (rw,relatime)
# так, мы видим, что между этими двумя пространствами имен происходит
# распространение.
# Точка монтирования была помечена как shared => изменения отражаются во всех членах
# одноранговой группы.
# возвращаемся в корневое mount namespace
cryptonite@cryptonite:~ $mkdir Z; sudo mount --make-private -t tmpfs tmpfs Z
cryptonite@cryptonite:~ $mount | grep Z
tmpfs on /home/cryptonite/test/Z type tmpfs (rw,relatime)
# возвращаемся в дочернее mount namespace
root@cryptonite:/home/cryptonite/test# mount | grep Z
# ничего --> точка монтирования, помеченная как private, из родительского пространства # имен в дочернем mount namespace отсутствует

Информацию о разных видах монтирования в пространстве имен текущего процесса можно найти в /proc/self/mountinfo.

╭─cryptonite@cryptonite ~
╰─$ cat /proc/self/mountinfo | head -n 3
24 31 0:22 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
25 31 0:23 / /proc rw,nosuid,nodev,noexec,relatime shared:15 - proc proc rw
26 31 0:5 / /dev rw,nosuid,noexec,relatime shared:2 - devtmpfs udev rw,size=8031108k,nr_inodes=2007777,mode=755

По аналогии можно сравнить имя хоста с названием многоэтажного жилого здания. Сказать таксисту, что мы живем в City Palace, часто будет эффективнее, чем сообщать фактический адрес. Наличие нескольких имен хостов на одном физическом хосте существенно помогает в обширных контейнеризованных средах.

Итак, пространство имен UTS предоставляет разделение имен хостов среди процессов. Таким образом, становится проще взаимодействовать со службами в закрытой сети и инспектировать их логи на хосте.

cryptonite@cryptonite:~ $sudo unshare -u /bin/bash
root@cryptonite:/home/cryptonite# hostname
cryptonite
root@cryptonite:/home/cryptonite# hostname test
root@cryptonite:/home/cryptonite# hostname
test
# тем временем во втором терминале
cryptonite@cryptonite:~ $hostname
cryptonite

Пространство имен IPC предоставляет изоляцию для механизмов взаимодействия процессов, таких как семафоры, очереди сообщений, разделяемая память и т.д. Обычно, когда процесс ответвляется, он наследует все IPC, открытые его родителем. Процессы внутри IPC namespace не могут видеть или взаимодействовать с ресурсами IPC вышестоящего пространства имен. Вот краткий пример, где используются разделяемые сегменты памяти:

cryptonite@cryptonite:~ $ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 32769 cryptonite 600 4194304 2 dest
0x00000000 6 cryptonite 600 524288 2 dest
0x00000000 13 cryptonite 600 393216 2 dest
0x00000000 16 cryptonite 600 524288 2 dest
0x00000000 32785 cryptonite 600 32768 2 dest
cryptonite@cryptonite:~ $sudo unshare -i /bin/bash
root@cryptonite:/home/cryptonite#
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status

Cgroup (контрольная группа) — это технология, контролирующая потребляемый процессом объем аппаратных ресурсов (RAM, HDD, блок ввода-вывода).

Итак, пространства имен CGroup виртуализируют другие виртуальные файловые системы в виде PID namespace. Но в чем вообще цель предоставления изоляции для данной системы? Выдержка из мануала:

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

В традиционной иерархии CGroup существует возможность того, что вложенное CGroup сможет получить доступ к своему предку. Это означает, что процесс в /sys/fs/cgroup/mycgroup/group1 потенциально может считывать и/или управлять чем-угодно, вложенным в mycgroup.

# Сначала скачиваем минимальный образ файловой системы,
# который будет находиться в новой корневой файловой системе изолированного процесса
cryptonite@cryptonite:~ $wget http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/x86_64/alpine-minirootfs-3.10.1-x86_64.tar.gz
cryptonite@cryptonite:~ $mkdir rootfs_alpine; tar -xzf alpine-minirootfs-3.10.1-x86_64.tar.gz -C rootfs_alpine
cryptonite@cryptonite:~ $ls rootfs_alpine
bin etc hostfs_root media opt root sbin sys usr
dev home lib mnt proc run srv tmp var

Хорошо, теперь у нас есть каталог, чье содержимое совпадает с классическим корневым каталогом Linux. Важно отметить порядок обертывания пространства имен, поскольку некоторые операции (например, создание пространств имен PID, UTC, IPC) требуют наличия расширенных привилегий в текущем пространстве имен. Приведенный ниже алгоритм иллюстрирует необходимый порядок действий:

1. Создать USER namespace
2. Переотобразить UID процесса в новое USER namespace
3. Создать UTC namespace
4. Изменить имя хоста в новом UTC namespace
5. Создать IPC/CGROUP namespaces
6. Создать NET namespace
7. Создать и настроить пару veth
8. Создать PID namespace
9. Создать MNT namespace
10. Изменить корень процесса
11. Смонтировать /proc в новом корне
12. Размонтировать старый корень
13. Поместить процесс в его новый корневой каталог

# создаем привилегированное user namespace, чтобы иметь возможность
# создавать пространства имен, требующие права администратора
cryptonite@cryptonite:~ $unshare -U --kill-child /bin/bash
nobody@cryptonite:~$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
# пробуем создать новые пространства имен
nobody@cryptonite:~$ unshare -iu /bin/bash
unshare: unshare failed: Operation not permitted
nobody@cryptonite:~$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

# в другом терминале; получаем PID процесса в пространстве имен.
# Затем переотображаем корневого пользователя внутри этого пространства имен в
# непривилегированного.
# В вышестоящем пространстве имен:
cryptonite@cryptonite:~ $ps aux | grep /bin/bash
crypton+ 26739 0.2 0.0 19516 5040 pts/0 S+ 18:04 0:00 /bin/bash
cryptonite@cryptonite:~ $echo "0 1000 65335" | sudo tee /proc/26739/uid_map
0 1000 65335
cryptonite@cryptonite:~ $echo "0 1000 65335" | sudo tee /proc/26739/gid_map
0 1000 65335
# возвращаемся к процессу в user namespace
nobody@cryptonite:~/test$ id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

Теперь можно переходить к созданию пространств имен IPC и UTS.

#создаем пространства имен IPC и UTC
nobody@cryptonite:~$ unshare --ipc --uts --kill-child /bin/bash
root@cryptonite:~/test# ipcs
------ Message Queues --------
key msqid owner perms used-bytes messages
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
------ Semaphore Arrays --------
key semid owner perms nsems
root@cryptonite:~# hostname isolated
root@cryptonite:~# hostname
isolated

Далее с помощью виртуальных интерфейсов создадим net namespace.

# возвращаемся в первый терминал,
# чтобы создать пару виртуальных интерфейсов
cryptonite@cryptonite:~ $sudo ip link add veth0 type veth peer name ceth0
# активируем одну из виртуальных сторон и присваиваем ей IP-адрес
cryptonite@cryptonite:~ $sudo ip link set veth0 up
cryptonite@cryptonite:~ $sudo ip addr add 172.12.0.11/24 dev veth0
# создаем net namespace
root@cryptonite:~# unshare --net --kill-child /bin/bash
root@isolated:~# sleep 30
# находим PID изолированного процесса
cryptonite@cryptonite:~ $ps -fC sleep
UID PID PPID C STIME TTY TIME CMD
crypton+ 78625 78467 0 11:44 pts/0 00:00:00 sleep 30
# помещаем другую сторону в net namespace этого процесса
cryptonite@cryptonite:~ $sudo ip link set ceth0 netns /proc/78467/ns/net
# Вернемся к процессу в пространстве имен,
# активируем вторую сторону veth и также присваиваем ей IP-адрес
root@isolated:~# ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
9: ceth0@if10: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 76:8d:bb:61:1b:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@isolated:~# ip link set lo up
root@isolated:~# ip link set ceth0 up
root@isolated:~# ip addr add 172.12.0.12/24 dev ceth0
# проверяем соединение
root@isolated:~# ping -c 1 172.12.0.11
PING 172.12.0.11 (172.12.0.11) 56(84) bytes of data.
64 bytes from 172.12.0.11: icmp_seq=1 ttl=64 time=0.079 ms
...

Теперь создадим отдельные пространства имен PID и MNT, а затем отделим корневую файловую систему.

// создаем новые пространства имен PID и MNT
root@cryptonite:~/test# unshare --pid --mount --fork --kill-child /bin/sh
#
# mount | grep ext4
/dev/mapper/vgcryponite-lvcryptoniteroot on / type ext4 (rw,relatime,errors=remount-ro)
// у нас есть копия точки монтирования rootfs в mount namespace,
// делаем корневую файловую систему alpine монтируемой
# mount --bind rootfs_alpine rootfs_alpine
# cd rootfs_alpine
# pwd
/home/cryptonite/test/rootfs_alpine
# mkdir hostfs_root
# ls
bin dev etc home hostfs_root lib media mnt opt proc root run sbin srv sys tmp usr var
// изменяем точку монтирования текущей корневой файловой системы
# pivot_root . hostfs_root
# ls hostfs_root
bin dev lib libx32 mnt root snap tmp
boot etc lib32 lost+found opt run srv usr
cdrom home lib64 media proc sbin sys var
// на данном этапе у нас есть связывающая точка монтирования файловой системы хоста в новом mount namespace
# touch hostfs_root/home/cryptonite/test/hello
cryptonite@cryptonite:~ $ls hello -l
-rw-rw-r-- 1 cryptonite cryptonite 0 Jul 6 13:45 hello
# ps
PID USER TIME COMMAND
// так, вывода нет – дело в том, что новую procfs мы ищем в пустом каталоге proc образа alpine.
// Давайте смонтируем относительную procfs в каталог /proc файловой системы alpine
# mount -t proc proc /proc
# ps
PID USER TIME COMMAND 1 root 0:00 /bin/sh 12 root 0:00 ps

Теперь нам нужно полностью изолировать процесс внутри текущего каталога alpine.

// размонтируем старую корневую систему в процессе из mount namespace
# umount -l hostfs_root
# mount | wc -l
2
// у нас три точки монтирования – проверим верхнее mount namespace
cryptonite@cryptonite:~ $mount | wc -l
59
# cd /
# pwd
/
# whoami
root
# ps
PID USER TIME COMMAND 1 root 0:00 /bin/sh 20 root 0:00 ps
# ipcs
------ Message Queues --------
key msqid owner perms used-bytes messages
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
------ Semaphore Arrays --------
key semid owner perms nsems
# hostname
isolated
# ls hostfs_root/
// пустой каталог
# rmdir hostfs_root
# ls
bin etc lib mnt proc run srv tmp var
dev home media opt root sbin sys usr

Мы изолировали процесс, используя почти все пространства имен. Иными словами, мы создали очень примитивный контейнер. Однако в нем нет ограничения на использование ресурсов, которое устанавливается с помощью контрольных групп.

Пространства имен – это очень мощный принцип ядра Linux, обеспечивающий изоляцию системных ресурсов. Это один из основных принципов, стоящих за созданием контейнеров, таких как известные Docker или LXC. Он обеспечивает ортогональность – то есть, все возможности, предоставляемые пространствами имен, могут использоваться независимо. Тем не менее пространства имен не устанавливают ограничения на использование процессом аппаратных ресурсов, это делается с помощью контрольных групп. Совмещение пространств имен, контрольных групп и возможностей позволяет нам создавать полностью изолированную среду.

Root server addresses

Root server supervision

Root zone file

1. AS19836 is not listed by the RIPEstat tool, though one can see it in https://stat.ripe.net/AS19836#tabId=at-a-glance
2. AS64820 is listed as «private use» in RIPE’s RISwhois tool
3. Originally it was ; It was changed to from January 2004 to October 2017 and then changed to 170.247.170.2 on May 2023
4. Since 3 January 2013; originally was .
5. Since November 2017; originally was AS27.
7. Unlike all other DNS root servers, G-Root does not respond to pings.
8. Since 1 December 2015; originally was .
9. Since 1 December 2015; originally was .
10. Since 1 December 2015; originally was AS13.
11. Since November 2002; originally was .
12. Since 1 November 2007; originally was .
13. Since 23 March 2016; originally was .

1. «Root Directory Definition». techterms.com. Archived from the original on 2020-10-26. Retrieved .
2. «Root Filesystem Definition by The Linux Information Project». LInfo.org. Archived from the original on 2021-07-10. Retrieved .
3. «What chroot() is really for». LWN.net. Archived from the original on 2020-11-12. Retrieved .
4. Brownbridge, David R.; Marshall, Lindsay F.; Randell, Brian (1982). «The Newcastle Connection» . Software: Practice and Experience. 12: 1147–1162. doi:10.1002/spe.4380121206. S2CID 1840438. Archived from the original on 2016-08-16. Retrieved .
5. Callaghan, Brent (2000). NFS Illustrated. Addison Wesley. ISBN 0-201-32570-5.
6. «Root Definition». LInfo.org. The Linux Information Project. 2007-10-27. Archived from the original on 2021-05-08. Retrieved .

Incidents of root certificate misuse

1. «What Are CA Certificates?». Microsoft TechNet. 2003-03-28.
2. «Windows and Windows Phone 8 SSL Root Certificate Program (Member CAs)». Microsoft TechNet. October 2014.
3. «476766 — Add China Internet Network Information Center (CNNIC) CA Root Certificate». bugzilla.mozilla.org. Archived from the original on 2020-02-22. Retrieved .
4. «CNNIC发行的中级CA发行了Google的假证书». solidot. 2015-03-24. Archived from the original on 2015-03-26. Retrieved .
5. «最危险的互联网漏洞正在逼近». Archived from the original on 2015-11-21. Retrieved .
6. «Google Bans China’s Website Certificate Authority After Security Breach». No. April 2, 2015. Extra Crunch.
7. «谷歌不再承認中國CNNIC頒發的信任證書». 華爾街日報. 2015-04-03. Retrieved .
8. «谷歌不再信任中国CNNIC 的网站信任证书». 美國之音. 2015-04-03. Retrieved .
9. «Google and Mozilla decide to ban Chinese certificate authority CNNIC from Chrome and Firefox». VentureBeat. April 2, 2015.
10. «Mozilla紧随谷歌 拒绝承认中国安全证书». 美國之音. 2015-04-04. Retrieved .
11. «谷歌宣布开始全面封杀使用沃通CA证书网站，信誉破产的恶果 — 超能网». www.expreview.com. Retrieved .
12. «CA:WoSign Issues — MozillaWiki». wiki.mozilla.org. Retrieved .
13. Stephen Schrauger. «The story of how WoSign gave me an SSL certificate for GitHub.com». Schrauger.com.
14. Microsoft Defender Security Research Team (2017-08-08). «Microsoft to remove WoSign and StartCom certificates in Windows 10». Microsoft.
15. «Toxic Root-CA certificates of WoSign and StartCom are still active in Windows 10». Windows Phone Info.

ipconfig /all