Часть 4. дистрибутив nixos

Введение

Nix – это пакетный менеджер для unix-систем, обладающий существенно иным подходом к сборке пакетов, учету зависимостей между ними и способу доставки на целевые системы.

Nix может работать совместно с обычным пакетным менеджером на том дистрибутиве, который у вас уже установлен (Ubuntu, Arch и т. п.). В статье будут рассмотрены процедура установки, операции управления пакетами и некоторые механизмы работы Nix.

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

Функциональный подход заключается в том, что пакет собирается функцией, не имеющей побочных эффектов, т. е. операции в Nix не являются деструктивными. Таким образом, операции установки и обновления как пакетов, так и целиком системы безопасны и позволяют осуществлять откат не только к предыдущему, но и к более ранним состояниям.

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

Файлы каждого установленного пакета хранятся в отдельных каталогах под уникальными идентификаторами. Это позволяет, в частности, устанавливать различные версии определенного пакета. Также есть возможность иметь несколько профилей набора установленных пакетов и управлять ими без прав суперпользователя.

Установка

Загрузившись с установочного диска, входим под root с пустым паролем. На всякий случай можем воспользоваться руководством пользователя, которое открыто на виртуальной консоли 7 (нажать Alt+F7).

4.1. Подготовка жесткого диска

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

Когда корневой раздел будет готов, его нужно примонтировать к /mnt, чтобы установочный скрипт нашел его.

4.2. Определение оборудования

Начинаем формировать конфигурацию системы. Лучше всего начать с определения оборудования с помощью утилиты nixos-hardware-scan. Вывод этой команды является Nix-выражением, описывающим параметры оборудования, его можно непосредственно подставлять в configuration.nix:

$ nixos-hardware-scan > /mnt/etc/nixos/configuration.nix

готова заготовка конфигурационного файла.

4.3. Настройка точек монтирования

Дополняем конфигурационный файл атрибутами настроек.

Точки монтирования задаются в атрибуте fileSystems. Значением атрибута должен быть список из элементов, определяющих точки монтирования. Каждый из элементов есть набор атрибутов со следующими полями: mountPoint (точка монтирования в файловой системе), device (устройство), fsType ( тип файловой системы, передаваемый команде mount через флаг -t; по умолчанию «auto»), options ( опции монтирования, передаваемые команде mount через флаг -o; по умолчанию «defaults»). Альтернативный вариант указания раздела вместо device использует атрибут label, в котором указывается название раздела, если конечно файловая система поддерживает (для ext2/ext3 см. mke2fs -L). Если установить атрибут autocreate в значение true, то директория монтирования создастся автоматически, когда она не существует. Например:

  fileSystems = [
   { device = "/dev/hda1";
     mountPoint = "/";
   }
   { device = "/dev/hda2";
     fsType = "ext3";
     mountPoint = "/data";
     options = "data=journal";
   }
   { label = "bigdisk";
     mountPoint = "/bigdisk";
   }
  ];

swap-разделы указываются в отдельном атрибуте swapDevices. Значением атрибута является список элементов, определяющих swap-разделы по пути к устройству (атрибут device), либо по названию раздела (атрибут label, см. mkswap -L). Например:

 swapDevices  = [
  { device = "/dev/hda7"; }
  { device = "/var/swapfile"; }
  { label = "bigswap"; }
 ]

4.4. Настройка загрузчика

В качестве загрузчика в NixOS используется Grub. Раздел, на который следует установить загрузчик, указывается в атрибуте boot.grubDevice. К примеру:

 boot = {
  # ...
  grubDevice = "/dev/sda";
 };

указывает установить загрузчик в mbr первого жесткого диска.

Если на жестком диске установлены другие операционные системы, которые нужно загружать, то добавляем их в меню Grub через атрибут boot.extraGrubEntries, например:

 boot = {
  # ...
  extraGrubEntries = "\n title Windows\n chainloader (hd0,1)+1\n ";
 };

4.5. Установка системы

Получится файл конфигурации подобный этому (/mnt/etc/nixos/configuration.nix):

{
  boot = {
    initrd = {
      extraKernelModules = ;
    };
    kernelModules = ;
    grubDevice = "/dev/sda";
  };
  fileSystems = [
    { mountPoint = "/";
      label = "nixos";
    }
  ];
  swapDevices = ;
  nix = {
    maxJobs = 1;
  };
  networking = {
    enableIntel3945ABGFirmware = false;
    enableIntel2200BGFirmware = false;
  };
  services = {
    xserver = {
      videoDriver = "nvidia";
    };
  };
}

Примеры конфигурационных файлов лежат в каталоге /etc/nixos/nixos/doc/config-examples.

С момента написания этой статьи к этому моменту настройки конфигурационного файла могли измениться, поэтому лучше уточнить их в http://hydra.nixos.org/job/nixos/trunk/manual/latest/download руководстве.

Когда конфигурационный файл будет готов, запускаем процедуру установки:

 $ nixos-install

Если установка прошла успешно, перегружаемся:

 $ reboot

Загрузившись в установленную систему, входим под пользователем root и сразу устанавливаем пароль для root:

 $ passwd

И добавляем пользовательский логин:

$ useradd -c 'First user' -m user
$ passwd user

ColdFusion

ColdFusion (он же язык разметки ColdFusion или CFML) был провозглашен новым грандиозным языком Web-разработок, ставящим себя в один ряд с ASP.NET и Java Enterprise. Ожидалось, что ColdFusion станет весьма популярным благодаря своей простоте и доступности для начинающих программистов. CFML использует теги (наподобие HTML). Программа на нем не требует никакой определенной формы написания, что очень помогает новичкам и не очень аккуратным программистам, постоянно забывающим о закрывающих тегах и заглавных буквах.

Довольно удивительно, что ColdFusion так быстро потерял популярность, учитывая простоту использования и, так сказать, HTML-наследственность. Гибель ColdFusion произошла не из-за ошибки в продвижении его как языка программирования, и не из-за каких-то особенных недостатков при его разработке. Он просто был вытеснен ASP.NET и PHP (который предложил людям интеграцию с MySQL и, что сыграло решающую роль, абсолютную халяву).

Что нужно знать и сделать перед установкой

Первое, о чем следует позаботиться, — это права root. Без них некоторые функции установленных нами утилит могут не поддерживаться или работать некорректно. Поэтому настоятельно рекомендую их заполучить. Особенно это касается пользователей с Android 10 и более поздних версий.

Получение root в каждом случае уникально, ведь оно напрямую зависит от конкретной модели устройства и версии Android. Я в этой статье буду использовать свой старенький Samsung Galaxy S6 (SM-G920F) на Android 7.0 Nougat, для рута в котором уже есть специальный инструмент. В остальных случаях придется погуглить и узнать, как получить рут конкретно на твоем устройстве. На форуме 4PDA почти всегда есть нужная инструкция.

Также нам понадобится Termux — простой и удобный терминал, дающий многие возможности среды Linux, который и позволит исполнять наши команды в подходящей среде и не возиться с предварительной настройкой окружения.

Рекомендую также установить утилиту tsu, которая предоставит тебе возможность выполнять команды от рута. Если она не работает должным образом, загляни в GitHub-репозиторий, который настраивает работу рута в Termux. Это нужно, чтобы Termux сразу имел рут-доступ, который может понадобиться для дальнейших операций.

INFO

Важный момент: при использовании в качестве рута Magisk (а на большинстве современных устройств альтернатив нет и не предвидится) не забудь в его настройках разрешить Termux рут-доступ, а также добавить в исключения для Magisk Hide, иначе все наши действия будут бесполезны.

Также рекомендую обновить список пакетов, как мы обычно делаем это в десктопе Kali:

Пара слов о Kali NetHunter

Если ты один из тех счастливчиков, чье устройство оказалось в списке поддерживаемых, рекомендую попробовать Kali NetHunter. Это платформа, созданная разработчиками Kali Linux специально для телефонов на Android. В NetHunter сразу доступно много рабочего софта из десктопной версии Kali. Образы можно найти на официальном сайте. Это более мощный набор, чем тот, что ты можешь получить с помощью Termux.

Подробнее о Kali NetHunter читай в статье «Атака со смартфона: знакомимся с Kali NetHunter».

Устанавливаем Metasploit

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

Установить Metasploit Framework (MSF) на Android 7 или выше можно в две команды:

На Android 5.x.x–6.x.x MSF устанавливают несколько другим методом:

WARNING

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

В частности, при запуске apt от рута мы получим сбитые контексты SELinux, что потом помешает нам устанавливать пакеты.

Установка может затянуться. Не закрывай сессию Termux до конца установки MSF!

WARNING

Не стоит обновлять MSF вручную редактированием , так как это может привести к проблемам с зависимостями.

Теперь, чтобы убедиться, что у нас все работает, запустим Metasploit:

Metasploit Framework

Как видишь, все отлично и в твоем распоряжении 2014 эксплоитов.

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Особенности

Модель конфигурации декларативной системы

В NixOS вся операционная система — ядро, приложения, системные пакеты, файлы конфигурации и т. д. — создаётся менеджером пакетов Nix из описания на функциональном языке сборки. Это означает, что создание новой конфигурации не может перезаписывать предыдущие конфигурации.

Система NixOS настраивается путем написания спецификации функций, которые пользователь хочет на своей машине, в глобальном файле конфигурации. Например, вот минимальная конфигурация машины, на которой запущен демон SSH:

{
  boot.loader.grub.device = "/dev/sda";
  fileSystems."/".device = "/dev/sda1";
  services.sshd.enable = true;
}

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

Эта команда делает всё необходимое для применения новой конфигурации, включая загрузку и компиляцию пакетов и создание файлов конфигурации.

Надёжные обновления

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

Атомарные обновления

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

Откат

Если после обновления системы новая конфигурация нежелательна, её можно откатить с помощью специальной команды .

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

Воспроизводимые системные конфигурации

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

Исходная бинарная модель

Язык сборки Nix, используемый NixOS, указывает, как создавать пакеты из исходного кода. Тем не менее, из-за медленного процесса сборки из исходного кода, менеджер пакетов автоматически загружает предварительно созданные двоичные файлы с кэш-сервера, когда они доступны. Это даёт гибкость базирующейся на исходном коде модели управления пакетами с эффективностью двоичной модели.

Согласованность

Менеджер пакетов Nix гарантирует, что работающая система «согласована» с логической спецификацией системы, что означает, что она перекомпилирует все пакеты, которые необходимо перекомпилировать. Например, если ядро изменено, менеджер пакетов гарантирует, что внешние модули ядра будут перекомпилированы. Аналогично, когда библиотека обновляется, это гарантирует, что все системные пакеты используют новую версию, даже пакеты, статически связанные с ней.

Управление многопользовательским пакетом

Нет необходимости в специальных привилегиях для установки программного обеспечения в NixOS. В дополнение к общесистемному профилю каждый пользователь имеет специальный профиль, в котором он может устанавливать пакеты. Nix также позволяет нескольким версиям пакета сосуществовать, поэтому разные пользователи могут иметь разные версии одного и того же пакета, установленные в соответствующих профилях. Если два пользователя установят одну и ту же версию пакета, то будет создана или загружена только одна копия, и модель безопасности Nix гарантирует, что это безопасно.

Using nix-shell for package development

nix-shell is a command which drops you into the build environment for a package. This is convenient for writing and debugging nix expressions. Nix-shell requires nix-1.6.x although running nix-build —run-env produces a similar environment.

$ mkdir -p ~/tmpdev/bc-build  &&  cd ~/tmpdev/bc-build
$ nix-shell $NIXPKGS -A bc

You can also drop in the build environment for a package not in nixpkgs.

$ mkdir -p ~/tmpdev/bc-build  &&  cd ~/tmpdev/bc-build
$ nix-shell -E "with import <nixpkgs> {}; callPackage /path/to/package.nix {}"

$ typeset -f genericBuild | less

which shows when custom variables $buildCommandPath or $buildCommand are defined, those are evaluated exclusively. Otherwise, if no custom $phases variable is set, the standard build phase order is used as shown here…

$ typeset -f genericBuild | grep 'phases='
phases="$prePhases unpackPhase patchPhase $preConfigurePhases configurePhase $preBuildPhases buildPhase checkPhase $preInstallPhases installPhase fixupPhase installCheckPhase $preDistPhases distPhase $postPhases";

So to observe a full build, you can do…

$ export out=~/tmpdev/bc-build/out
$ set -x
$ genericBuild

or while developing your own package, you need to individually run these phases in order:

unpackPhase
patchPhase
configurePhase
buildPhase
checkPhase
installPhase
fixupPhase
installCheckPhase
distPhase

Any overridden phases should be invoked using eval instead:

eval "$checkPhase"
# etc..

Note: you do not need to run $preConfigurePhase explicitly as it is run, when running configurePhase already.

To list all functions which are declared in set:

typeset -F
declare -f addCVars
declare -f addToCrossEnv
declare -f addToNativeEnv
declare -f addToSearchPath
declare -f addToSearchPathWithCustomDelimiter
declare -f buildPhase
declare -f checkPhase
declare -f closeNest
declare -f command_not_found_handle
declare -f configurePhase
declare -f distPhase
declare -f dumpVars
declare -f ensureDir
declare -f exitHandler
declare -f findInputs
declare -f fixLibtool
declare -f fixupPhase
declare -f genericBuild
declare -f header
declare -f installBin
declare -f installCheckPhase
declare -f installPhase
declare -f patchELF
declare -f patchPhase
declare -f patchShebangs
declare -f runHook
declare -f showPhaseHeader
declare -f startNest
declare -f stopNest
declare -f stripDirs
declare -f stripHash
declare -f substitute
declare -f substituteAll
declare -f substituteAllInPlace
declare -f substituteInPlace
declare -f unpackFile
declare -f unpackPhase

If the phase has been defined as a function, to list a particular function type:

typeset -f unpackPhase

Otherwise, if it was a string, simply echo the variable related to it

echo "$unpackPhase"

In either case, you can see the code that is about to be executed for each phase:

typeset -f unpackPhase
unpackPhase ()
{
    runHook preUnpack;
    if  -z "$srcs" ; then
        if  -z "$src" ; then
            echo 'variable $src or $srcs should point to the source';
            exit 1;
        fi;
        srcs="$src";
    fi;
    local dirsBefore="";
    for i in *;
    do
        if  -d "$i" ; then
            dirsBefore="$dirsBefore $i ";
        fi;
    done;
    for i in $srcs;
    do
        unpackFile $i;
    done;
    if  -n "$setSourceRoot" ; then
        runHook setSourceRoot;
    else
        if  -z "$sourceRoot" ; then
            sourceRoot=;
            for i in *;
            do
                if  -d "$i" ; then
                    case $dirsBefore in
                        *\ $i\ *)

                        ;;
                        *)
                            if  -n "$sourceRoot" ; then
                                echo "unpacker produced multiple directories";
                                exit 1;
                            fi;
                            sourceRoot="$i"
                        ;;
                    esac;
                fi;
            done;
        fi;
    fi;
    if  -z "$sourceRoot" ; then
        echo "unpacker appears to have produced no directories";
        exit 1;
    fi;
    echo "source root is $sourceRoot";
    if  "$dontMakeSourcesWritable" != 1 ; then
        chmod -R u+w "$sourceRoot";
    fi;
    runHook postUnpack
}

you can also modify the configureFlags prefix:

export configureFlags="--prefix=$out --with-readline"

Tip: A git repository can be used for snapshotting attempts at building the package. This also makes it easy to generate patches, should you need to.

Декларативный и функциональный

NixOS — это дистрибутив Linux, построенный вокруг двух ключевых идей:

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

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

Вместо этого NixOS предлагает описать необходимое состояние системы в специальном конфигурационном файле, где будет перечислено все, начиная от пакетов и заканчивая возможностью логина по SSH с помощью пароля. Далее достаточно выполнить одну команду, и, в каком бы состоянии система ни находилась в данный момент, пакетный менеджер приведет ее к требуемому.

Другими словами, если вам нужна система с установленным Apache, PHP, MySQL, SSH и с некоторыми дополнительными настройками, вы просто описываете все это в одном конфиге, а затем отдаете команду на развертывание системы. Независимо от того, свежеустановленная это ОС или уже используемая, вы получите абсолютно идентичную систему с идентичным набором пакетов и конфигов.

Все это возможно благодаря пакетному менеджеру Nix. В классических дистрибутивах Linux пакетный менеджер при установке пакета «размазывает» его содержимое по всей системе: запускаемые файлы в , библиотеки в , остальные компоненты — в . В результате ты получаете проблемы с неудачным обновлением/удалением пакетов (когда могут остаться файлы-сироты), ад зависимостей (когда два приложения требуют разные версии , например) и легкий способ уничтожить всю систему, неудачно обновившись.

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

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

NixOS позволяет устанавливать софт не только root, но и обычным пользователям (в этом случае пакет будет установлен в домашний каталог), а также имеет встроенный сборщик мусора, который автоматически удалит все пакеты-зависимости, если они больше никому не нужны.

Windows Subsystem for Linux (WSL)

WSL1 (pre-Windows 10 2004 build 19041)

Running Nix is much simpler on WSL2, so we recommend that if at all possible. If WSL2 is not available, then Nix can be installed and run from WSL1 with a few workarounds.

Install and configure QEMU and binfmt-support

$ sudo apt install qemu-user-static
$ sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'

Start the binfmt-support service every WSL1 login:

$ sudo service binfmt-support start

Continue installing Nix as described in Single-user install

Устанавливаем

В NixOS нет инсталлятора, но если ты когда-нибудь устанавливал Arch Linux, то у тебя не должно возникнуть проблем. Для начала скачиваем последнюю версию NixOS с официального сайта и записываем ее на флешку:

Затем перезагружаем машину и грузимся с флешки. NixOS встретит тебя приветствием командной строки.

Первое, что мы должны сделать, — подготовить диск для установки. Проще всего сделать это с помощью parted (в данном примере мы создаем один большой раздел ext3 на диске с разметкой в стиле DOS):

Мы будем ставить систему на зашифрованный диск, поэтому для начала инициализируем шифрование:

Затем примонтируем диск к каталогу /mnt:

Теперь обновляем репозитории:

И генерируем дефолтовые файлы конфигурации:

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

Наконец, устанавливаем систему и перезагружаемся:

Устанавливаем NixOS 

Термин «Unix-подобный» и торговая марка UNIX

The Open Group обладает торговой маркой UNIX и управляет разработкой стандарта Single UNIX Specification, где слово «UNIX» используется как знак соответствия. Они не приветствуют употребление термина «UNIX-подобный» и считают, что это злоупотребление их товарным знаком. Руководства, изданные группой, требуют использования заглавных букв в названии UNIX либо выделение другим способом от остального текста, одобряют использование слова «UNIX» как прилагательного в сочетании с такими словами, как «система», и не одобряют написание через дефис (относится к английским текстам). Наиболее близкий термин, который они сочли бы корректным, был бы Unix system-like.

В 2007 году Wayne R. Gray пытался оспорить в суде возможность использования слова «UNIX» как товарного знака, но проиграл процесс. Суд поддержал статус товарного знака и право собственности на него.

Также в 2007 году X/Open Company Ltd. настояла на том, чтобы немецкий Университет Касселя не использовал UNIX в качестве сокращения.

Сила виртуализации

TAILS распространяется в форме немодифицируемого Live CD не только для защиты от троянов и от возможных утечек конфиденциальных данных при получении физического доступа к машине, но и для банальной «защиты от дурака». Разработчики не могут быть уверены, что пользователь корректно настроит каждое установленное им приложение и не спровоцирует утечку данных или раскрытие своего IP. А если систему нельзя менять, то и проблема пропадает сама собой.

Единственный способ выйти во внешний мир для рабочей машины — это шлюз, единственный путь трафика во внешний мир из шлюза и обратно — через сеть Tor

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

Тебя не удастся отследить даже по временной зоне, часы здесь настроены на UTC, а для синхронизации времени используются time stamp’ы HTTP-заголовков, отдаваемых случайно выбранными веб-серверами.

Самая же интересная черта системы в том, что она вовсе не требует, чтобы ты использовал именно рабочую машину Whonix. Главный компонент здесь — это шлюз, к которому можно подцепить любую другую запущенную в виртуалке ОС, будь то Ubuntu, Windows или OS X, и получить почти такой же уровень защиты от отслеживания

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Дисклеймер

Честно говоря, изначально Subgraph OS не произвела на меня никакого впечатления. Очередной проект, ставящий своей целью разместить пользовательский софт в песочницах и таким образом достигнуть каких-то непонятных уровней защищенности ОС. Нет, ребята, в Qubes OS все это уже реализовано, причем на самом низком уровне, на уровне гипервизора Xen, да еще и с изоляцией сетевого стека и слоя работы с накопителями. Однако, следя за развитием проекта, я начал замечать движение в правильную сторону. Песочницы оказались далеко не так просты, как представлялось, а система обрела множество других правильных черт, в том числе ядро с включенными патчами PaX/Grsecurity и прокси-слой, который пропускает трафик приложений через Tor, анонимизируя его источник.

В целом операционка начала обретать черты из коробки защищенной системы, которую гипотетический пользователь может поставить и просто юзать, не вникая в детали того, как это все работает. А это уже тянет если не на премию, то как минимум одну статью в одном русскоязычном журнале. Тем более Сноуден уже высказался, почему нельзя мне?

Установка Nix в основную систему

Nix портирован на различные платформы: Linux (архитектуры x86, x86_64, PowerPC), Mac OS X (Intel и PowerPC), FreeBSD (тестирование проводилось только для архитектуры Intel), Windows (Cygwin).

2.1. Сборка из исходных текстов

Для компиляции NIX в системе должны быть установлены GCC/G++, Curl и Perl.

Сборка и установка осуществляется стандартным набором команд:

$ ./configure
$ make
$ make install

По умолчанию утилиты и конфигурационные файлы Nix устанавливаются в /usr/local, изменить этот путь можно, указав конфигурационному скрипту —prefix=path. Изменять путь размещения хранилища (/nix) не рекомендуется.

2.2. Установка из RPM

Есть уже собранные пакеты для дистрибутивов, основанных на пакетном менеджере RPM. Скачать их можно отсюда. Бинарный пакет устанавливается командой

$ rpm -U nix-0.12-1.i386.rpm

2.3. Активизация Nix в системе

Если системой пользуется всего один человек, то назначаем его пользовательский аккаунт владельцем директорий /nix/var/nix и /nix/store:

$ sudo chown -R <username> /nix/store /nix/var/nix

Теперь он может выполнять операции с Nix без привилегий суперпользователя. Такой режим доступа к хранилищу Nix называется однопользовательским. Nix также поддерживает многопользовательский режим, при котором операции доступа к хранилищу от пользователей перенаправляются демону Nix, работающему с правами суперпользователя. Это позволяет непривилегированным пользователям в системе работать с менеджером Nix. Настройка многопользовательского режима в этой статье не рассматривается, информация о ней есть в руководстве пользователя.

Включаем в пользовательский ~/.bashrc загрузку файла /usr/local/etc/profile.d/nix.sh:

source /usr/local/etc/profile.d/nix.sh

Скрипт создает в директории пользователя символическую ссылку ~/.nix-profile, которая указывает на пользовательское окружение Nix с набором установленных программ. В переменную окружения PATH добавляется путь ~/.nix-profile/bin, и таким образом становятся доступны программы, установленные через Nix.

2.4. Обновление Nix через Nix

Если Nix уже установлен, то для его обновления нет необходимости трогать основную систему, с самим менеджером можно работать через Nix как с обычным пакетом:

$ nix-env -i nix

Заключение

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

Набор пакетов, доступных через Nix, включает средства для разработки (GCC, Haskell, Perl, Python, Ruby, Subversion, Git, Darcs, Bazaar, Mercurial,…), сетевые утилиты, средства работы с текстом (Vim, Emacs, Eclipse,…), средства виртуализации (VirtualBox, Qemu,…), офисные пакеты (Abiword, OpenOffice,…), мультимедиа приложения (Audacious, Audacity, MPlayer, Xine, Vlc,…), интернет-приложения (Firefox, Opera, BitTorrent, Skype, Pidgin,…) и др.

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

Заключение

Таким образом, NixOS абстрагирует детали реализации системы и разнородный синтаксис конфигурационных файлов под однородным синтаксисом Nix-выражений. Сборка конкретной системы производится на основе одного файла, описывающего её конфигурацию (configuration.nix).

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

Похожие темы

• Функциональный менеджер пакетов Nix. Часть 1: Базовое использование.
• Функциональный менеджер пакетов Nix. Часть 2: Специализированный язык.
• Функциональный менеджер пакетов Nix. Часть 3: Описание сборки пакета.
• Страница проекта.
• Последняя версия руководства пользователя NixOS (EN).