книги хакеры / журнал хакер / 180_compressed

ЗАДАЧА № 1

Каков результат выполнения данного кода и почему?

var f = function g(){ return 23; };

typeof g();

Решение: кажется, что ответ — «number», но в результате получим ошибку — «g is not defined». Вся соль в том, что g видно только внутри самой функции, так как это не function declaration, а function expression. В то же время f видно обычным образом, и typeof f() даст нам number.

ЗАДАЧА № 2

Дан массив [1,[2,3,[4],5],6,[7]]. Предложи самый короткий код для превращения его в [1,2,3,4,5,6,7].

ЗАДАЧА № 3

Есть произвольная функция. В ней нужно получить ссылку на глобальный объект. Код должен без ошибок исполняться как на клиентской, так и на серверной стороне (Node.js).

NB: решение должно работать как под strict mode, так и без него.

Решение:

var global = (function() { return this || (1,eval)('this') })();

При работе в не strict mode решение даст первая часть выражения — this (он будет указывать на глобальную область). При работе в strict mode this == null нам потребуется вторая часть. Ключ к решению — так называемый indirect eval call, то есть мы вызываем не сам eval, а «ссылку» на него. А такой вызов гарантированно будет выполнен в глобальном scope. Подробности на StackOverflow (stackoverflow. com/questions/9107240/1-evalthis-vs-evalthis-in-javascript).

ЗАДАЧА № 4

Что выведет следующий код?

var foo = {

bar: function(){ return this.baz; },

baz: 1

}

typeof (f = foo.bar)();

Решение: результат работы данного кода — undefined или ошибка в strict mode. Граалем здесь будет понимание того, как работает this. В момент, когда выполняется f = foo.bar, в переменной f мы получаем ссылку на функцию foo.bar. В момент вызова f() this будет глобальный объект или null в strict mode. Соответственно, получим undefined или брошенное исключение.

ЗАДАЧА № 5

Каков результат выполнения данного кода и почему?

(function f(){

function f(){ return 1; }

return f();

function f(){ return 2; } })();

Решение: чтобы понять суть этой задачи, нужно понять hoisting. В этом случае мы имеем два объявления функции с одинаковым именем, которое «всплывет» в самый верх scope, и реально мы получим:

(function f(){

function f(){ return 1; }

function f(){ return 2; }

return f(); })();

Что даст в результате 2.

ЗАДАЧА № 6

Объясни, почему выражение ++[[]][+[]]+[+[]] = "10" истинно?

Решение: ключ к этому заданию — понять, как работает +[]. Грубо говоря, это приведение массива к числу, которое осуществляется через… приведение к строке

— +[] => +"" => 0. Дальше все выражение раскручивается довольно просто. На тему этой задачки есть эпичный тред на StackOverflow (stackoverflow.com/ questions/7202157/can-you-explain-why-10).

ЗАДАЧА № 9

Что выведет следующий код?

console.log(0);

setTimeout(function() { console.log(1) }, 0); setTimeout(function() { console.log(2) }, 42);

console.log(3);

ЗАДАЧА № 7

Почему следующее выражение верно?

({toString: function() { return 10 }, valueOf: function() {

return {} }}) + 1 == 11

Решение: для объяснения данной задачи нужно знать, как работает valueOf, toString и приведение типов.

Когда мы хотим сложить объект и число, сперва вызывается valueOf, но он возвращает не примитивный тип. В этом случае вызывается toString, который в нашем примере возвращает 10. 10 + 1 == 11.

ЗАДАЧА № 8

Объясни, что делает этот код и как можно использовать полученный bind:

var bind = Function.prototype.call.bind(Function.prototype.

bind);

Решение: создается функция, эквивалентная по смыслу Function. prototype.call, но выполняется всегда в контексте Function.prototype. bind. То есть, по сути, это Function.prototype.bind.call(...). В результате с помощью bind можно получить функцию, контекст которой будет определяться при вызове и передаваться первым аргументом. Пример:

var push = bind(Array.prototype.push);

var arr = [];

push(arr, 10); // вместо arr.push(10);

bind(Array.prototype.push) =>

Function.prototype.bind.call(Array.prototype.push) =>

Array.prototype.push(context, args...) => F

F(arr, 10) => arr.push(10);

Решение: правильным ответом к этой задачке будет последовательность «0, 3, 1, 2». Основная загоздка состоит в том, что, даже указав задержку в 0 секунд, мы размещаем в «очереди событий» новое событие, к обработке которого виртуальная машина JavaScript все равно перейдет лишь в тот момент, когда будет закончена обработка текущего «набора» инструкций (то есть в нашем случае следующего setTimeout и console. log(3)).

Изучаем возможности nftables — нового пакетного фильтра Linux

Уже более 13 лет сетевые соединения Linux-систем защищает iptables. К сожалению, по мере развития этот пакетный фильтр обрастал серьезными проблемами на функциональном уровне и в дизайне. Взвесив все за и против, разработчики решили отказаться от метода костылей и создали новый файер, имя которому nftables.

ЧЕМ НЕ УСТРАИВАЕТ IPTABLES?

просто развивать подсистему фильтрации, и со временем появилось большое количество новых функций и модулей. Полноценная поддержка IPv6 появилась только в 2011 году, что, правда, потребовало редизайна netfilter. В результате модуль NAT разделили на два независимых компонента, один из которых включает в себя ядро подсистемы NAT, а второй реализует поддержку протокола третьего уровня. Помимо фильтрации, модули обеспечивают классификацию трафика (вплоть до седьмого уровня OSI), балансировку нагрузки, манипуляцию с пакетами, маршрутизацию и прочее.

Со временем накапливались проблемы на функциональном уровне и в дизайне. Код ядра дублировался, становилось все сложнее его поддерживать и добавлять новые возможности. Обработка некоторых параметров жестко вшита в ядро, модуль нередко обслуживает только свой протокол. Например, за извлечение номера порта UDP и TCP отвечают два разных модуля. Для реализации любой функции в userspace требуется поддержка модулем ядра, это затрудняет разработку, и без пересборки часто не обойтись. Правила загружаются как один большой дамп, в случае изменения правила выгружаются, меняются и весь набор отправляется обратно. Без учета дополнительных расширений количество опций конфигурирования в ядре уже давно перевалило за сотню.

Еще один важный мотив — необходимость сбросить текущий ABI (Application Binary Interface), представляющий собой набор соглашений между программами, библиотеками и ОС, обеспечивающими их взаимодействие на низком уровне.

В iptables ABI жестко прописаны специфические для протоколов поля, поэтому расширить его сложно. Как результат, приходится сразу запускать iptables, arptables и ebtables, по существу выполняющие одну работу, но каждый на своем уровне. По общим оценкам дублируется 10 000 строк кода. Учитывая, что все защитные механизмы и цепочки (даже пустые) грузятся изначально и активны, iptables потребляет больше ресурсов, чем реально необходимо.

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

НАЗНАЧЕНИЕ NFTABLES

Об nftables (netfilter.org/projects/nftables) впервые заговорили

воктябре 2008 года на конференции Netfilter Workshop. Задача проекта — заменить подсистемы iptables, ip6tables, arptables и ebtables одним решением. Разработкой новой подсистемы пакетной фильтрации стала заниматься та же команда, только под руководством Патрика Мак-Харди (Patrick McHardy). Аль- фа-версия была представлена в марте 2009 года, хотя до 2012 года проект практически спал.

Дерево патчей состояло из более 100 патчей, которые в конце октября 2013-го были объединены в 17. В стандартную ветку Linux nftables включен с версии 3.13, хотя высокоуровневые инструменты все еще находятся в разработке, а документация, ориентированная на пользователя, отсутствует. Старая и новая подсистемы будут некоторое время сосуществовать рядом, так как nftables еще требует доработки и тестирования. Для обеспечения обратной совместимости предоставляется специальная прослойка, позволяющая использовать iptables/ip6tables поверх инфраструктуры nftables.

Вnftables реализована идея, схожая с BPF (Berkeley Packet Filters): правила фильтрации в пространстве пользователя компилируются в байт-код, а затем через Netlink API передаются

вядро. После этого для принятия решения по дальнейшим действиям с пакетом они выполняются с использованием так называемого конечного автомата (pseudo-state machine), который представляет собой простейшую виртуальную машину, выполняющую байт-код.

Виртуальная машина способна манипулировать наборами данных (как правило, IP-адреса), позволяя заменить несколько операций сравнения единым набором поиска. Для принятия решений на основе этих данных могут быть использованы арифметика, битовые операторы и операторы сравнения. Возможен и обратный процесс декомпиляции объектов, позволяющий воссоздать текущую конфигурацию в ядре.

Использование userspace значительно упрощает код ядра и позволяет гораздо легче анализировать и принимать решения по отдельным протоколам. Отсутствует дублирование кода, особенности каждого протокола уже не встраиваются.

Все операции по определению условий и связанных с ними действий выполняются в пространстве пользователя, в ядре

123

ЖУРНАЛИРОВАНИЕ В NFTABLES

Для регистрации событий используется Netfilter, при помощи модулей xt_LOG (регистрирует в syslog) и/или nfnetlink_log. Последний использует демон сбора информации ulogd2, вышедший примерно полтора года назад и способный накапливать данные на уровне отдельных пакетов или потоков и сохранять их, в том числе и в БД.

Механизм журналирования для каждого протокола настраивается через /proc.

# cat /proc/net/netfilter/nf_log

0 NONE (nfnetlink_log)

1 NONE (nfnetlink_log)

2 ipt_LOG (nfnetlink_log,ipt_LOG)

Под номером 2 у нас скрывается IPv4. Меняем на nfnetlink_log:

# echo "nfnetlink_log" >/proc/sys/net/netfilter/nf_log/2

table filter hook output priority 0;

ip protocol tcp counter packets 190 bytes 21908

ip daddr 192.168.1.100 drop

}

}

Правило можно вставить в нужную позицию (handle), здесь работают две директивы — add и insert. Первая добавляет правило после указанной позиции, а вторая — перед. Например, чтобы вставить правило перед handle 8, пишем:

nft insert rule filter output position 8 ip daddr

127.0.0.1 drop

Удаляются правила в цепочке при помощи параметра delete:

nft delete rule filter output handle 9

Если не указывать номер правила, то будет очищена вся цепочка. При помощи flush сбрасывается вся таблица:

nft flush table filter

Настройка NAT не сложнее, вначале необходимо загрузить модули:

modprobe nft_nat

modprobe nft_chain_nat_ipv4

modprobe nft_chain_nat_ipv6

Создаем цепочку:

nft add table nat

nft add chain nat post \{ type nat hook

postrouting priority 0 \; \}

nft add chain nat pre \{ type nat hook

prerouting priority 0 \; \}

И добавляем в нее правила:

nft add rule nat post ip saddr 192.168.1.0/24

meta oif eth0 snat 192.168.1.1

nft add rule nat pre udp dport 53 ip saddr

192.168.1.0/24 dnat 8.8.8.8:53

Первое активирует NAT для всего трафика с 192.168.1.0/24 на интерфейсе eth0, второе перенаправляет весь DNS-трафик на 8.8.8.8.

УСТАНОВКА NFTABLES В UBUNTU

На данный момент единственный выход изучить новинку — это установить nftables самостоятельно. Нам потребуются библиотеки и стандартный набор для сборки ПО:

$ sudo apt-get install autoconf2.13 dh-autoreconf

libmnl-dev libmnl0

ПАКЕТНЫЙ ФИЛЬТР FF

Джефри Мерки (Jeffrey Merkey) представил в списке рассылки разработчиков ядра Linux код нового специализированного пакетного фильтра FF (lkml.org/ lkml/2009/1/8/467), предназначенного для блокирования большого числа IPадресов в сетях с интенсивным трафиком. FF состоит из модуля Linux-ядра и утилиты для управления пакетным фильтром. Представленный пакетный фильтр не отличается такой гибкостью, как iptables, но опережает последний по производительности и потребляет значительно меньше памяти в расчете на один IP.

От ipset новая система отличается тем, что поддерживает блокирование на уровне драйвера e1000. Набор утилит, работающий на уровне пользователя, обеспечивает сохранение БД-адресов на диске с кешированием базы в памяти ядра.

Главная задача FF — защита от DoS/DDoS-атак, блокирование различного флуда и паразитного трафика. В качестве примера представлен код для интеграции разработки с Postfix с целью борьбы с роботами спамеров, выступающий в роли более жесткой системы блокирования для серых списков и RBL-систем.

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

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

CHROOT

Способ изолирования окружения с помощью chroot известен еще со времен UNIX V7, где и появился данный системный вызов. Я не буду описывать конкретные методы его применения — об этом писали уже неоднократно, и смысла пересказывать, какие команды нужны для его развертывания, я не вижу (разве что коснусь проблемы запуска графических приложений в нем). Вместо этого сосредоточусь на его преимуществах и недостатках.

Неоспоримое преимущество chroot — он есть везде, даже в таких древних дистрибутивах, о которых сейчас уже никто и не помнит. В случае крайней необходимости можно сконфигурировать нечто, отдаленно напоминающее защищенную систему даже на основе ядер 2.2. Но именно что «отдаленно напоминающее» — поскольку

больше преимуществ у этого способа изоляции, по сути, и нет.

Недостатки… к ним можно отнести, например, сложность развертывания. Для запуска того же Apache в chroot нужно разбираться с кучей библиотек, конфигурационных файлов и файлов устройств, от которых он зависит. Но, допустим, для быстрого развертывания нужных библиотек можно использовать debootstrap, для файлов устройств и псевдофайловых систем — попросту пробросить в chroot-окружение нужные каталоги командой mount --bind… вот только для целей именно изоляции без создания в этом окружении непривилегированного пользователя толк будет нулевой. В этом и заключается основной недостаток chroot.

Все дело в том, что из поддерева chroot достаточно легко выйти. Для этого, помимо очевидного пути (монтирования файла из каталога /dev), есть также способ «двойного chroot». Суть его заключается в следующем: программа создает директорию, делает в нее вызов chroot(), но перед этим она запоминает fd текущего каталога. После этого она делает системный вызов fchdir(), в качестве параметра которого используется запомненный ранее fd. По сути, на этом процедуру выхода из поддерева можно считать выполненной — необходимо лишь перейти к фактическому корню и сделать chroot() уже в него.

Что же касается запуска графических приложений, то, во-первых, перед изменением корня нужно разрешить доступ к X-серверу, что и делает следующая команда:

$ xhost +localhost

А во-вторых, уже после вызова chroot, экспортировать переменную DISPLAY, значение которой нужно узнать заблаговременно:

$ export DISPLAY=":0.0"

Несмотря на все его недостатки, chroot (как и его примерный аналог, fakeroot) незаменим для «честной» сборки некоторых приложений. Также без его помощи производить восстановительные работы на сломанной системе было бы гораздо сложнее.

SELINUX

Данный фреймворк безопасности был разработан в NSA, который нынче стал притчей во языцех. Я не буду больше здесь писать об NSA, поскольку статья все же посвящена технической части, замечу лишь, что, если что-то разработано

внедрах подобных контор, это вовсе не значит, будто есть какие-то недекларированные возможности, — разработка-то велась для себя. В то же время, в силу относительной сложности SELinux, я не могу гарантировать, что таких возможностей там стопроцентно нет.

Первым делом вспомним, что такое SELinux. Как правило, когда упоминают SELinux, рядом же упоминают MAC — мандатный контроль доступа, то есть модель управления доступом, основанную на «метках» — грифах секретности. Однако

вслучае с SELinux это не совсем верно. Он позволяет гораздо больше, чем обычный MAC. Фактически SELinux реализует архитектуру FLASK — Flux Advanced Security Kernel, которая основана на идее Type Enforcement (TE, иногда переводится как «принудительное присвоение типов»). Суть идеи в том, что каждому объекту (файлу ли, каталогу или даже сетевому соединению) или субъекту (в качестве которого выступает тот или иной процесс) принудительно присваивается контекст

Подготовка к запуску Skype в SELinux sandbox

type sandbox_net_client_t;

type v4l_device_t;

class chr_file { read write };

}

require {

type sandbox_net_client_t;

type v4l_device_t;

class chr_file { open ioctl };

}

require {

type sandbox_net_t;

type v4l_device_t;

class chr_file { read write };

}

require {

type sandbox_net_t;

type v4l_device_t;

class chr_file { open ioctl };

}

# ======= sandbox_net_client_t =========

allow sandbox_net_client_t

v4l_device_t:chr_file { read write };

allow sandbox_net_client_t

v4l_device_t:chr_file { open ioctl };

allow sandbox_net_t v4l_device_t:

chr_file { read write };

allow sandbox_net_t v4l_device_t:

chr_file { open ioctl };

Откомпилируем и загрузим этот модуль:

#checkmodule -M -m -o Skype42_sandbox_ v4l.mod Skype42_sandbox_v4l.te

#semodule_package --module Skype42_ sandbox_v4l.mod --outfile Skype42_ sandbox_v4l.pp

#semodule -i Skype42_sandbox_v4l.pp

После очередного запуска Skype увидит камеру.

Разберем теперь плюсы и минусы данной песочницы. Плюсы, если сравнивать с chroot, несомненно, имеются. Так, налицо большая безопасность при меньшем времени развертывания. Посуди сам: для запуска программы в chroot нужно набрать 3–5 команд, для запуска же в песочнице SELinux в общем случае достаточно одной команды, которая, ко всему прочему, еще

иотключает все capabilities данного процесса — то есть ограничивает приложения, даже будучи запущенной из-под root.

Но и минусы тоже есть. Самый главный — эта утилита входит в состав только Fedor’ы, RHEL

иклонов. Во-вторых, при попытке запустить ка- кое-нибудь приложение — даже, казалось бы, не слишком экзотическое — этот sandbox просто отказывается его запускать, что мы и видели в случае со Skype. Настройка же SELinux, на ос-

Профиль Firefox для AppArmor

ство изоляции из уже рассмотренных по соотношению удобство использования / безопасность.

LXC И ARKOSE

Механизм LXC, который можно назвать усовершенствованным chroot, появился относительно недавно и, хотя для промышленного применения пока еще сыроват, для домашних пользователей вполне сгодится. Здесь я не буду описывать, как создавать контейнеры, коснусь лишь внутренней архитектуры.

По сути, LXC не является самостоятельной технологией. Это объединение двух разных механизмов — namespaces и cgroups. Namespaces (пространства имен) позволяют, в частности, разграничить область видимости процессом других процессов (пространство имен pid) и скрывать точки монтирования (пространство имен mount). Последнее, кстати говоря, и является аналогом chroot, так что де-факто, даже если бы LXC был основан только на пространствах имен, у него бы все равно была большая гибкость. Но помимо пространств имен, LXC использует еще и cgroups для контроля ресурсов — процессорного времени и памяти. Пространства имен стоит описать чуть подробнее. Всего их шесть, о двух из них мы уже упомянули, расскажу об оставшихся:

•UTS — если коротко, позволяет задавать раздельные hostname;

•IPC — позволяет изолировать некоторые механизмы межпроцессной коммуникации, такие как SysV IPC и очереди сообщений POSIX;

•Network — предоставляет возможность изоляции сетевых ресурсов — интерфейсов, таблицы маршрутизации, портов и прочего;

•User — изолирует диапазон UID и GID. Иными словами, в общем пространстве имен процесс может иметь один UID/GID, а в своем собственном может быть совершенно другой. А если учитывать, что начиная с ядра 3.8 дан-

Потенциальная возможность вырваться из Arkose —

получить root-привилегии в песочнице, собрать свой

модуль ядра и загрузить его