Леннарт Поттеринг (Lennart Poettering) представил в своём блоге Journal, дополнение к системному менеджеру systemd, призванное заменить собой службу syslog. Разработка пока находится на начальной стадии, прототип с реализацией базовой функциональности можно найти в Git-репозитории systemd. Первую экспериментальную реализацию Journal планируется интегрировать в дистрибутив Fedora 17.

Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и почистить выдающие их активность записи из системных логов. Используемые в настоящее время реализации службы syslog беспомощны перед такими действиями. В Journal для решения данной задачи планируется задействовать средства обеспечения целостности, похожие на те, что используются в Git. Для каждой записи в журнале будет сопоставлен хэш, который по цепочке будет охватывать хэш каждой предыдущей записи. Используя отдельно сохранённый эталонный начальный хэш, который недоступен атакующему (без этого хэша нет возможности воссоздать всю цепочку подтверждений), можно легко проверить неизменность всего лога.

Journal будет частью systemd и не сможет использоваться обособленно. Все логи будут проиндексированы и хранится в специальной БД, к которой к сожалению будут неприменимы стандартные утилиты обработки текстовых файлов, такие как grep. Тем не менее, Journal не исключает параллельное использование традиционных syslog-служб, таких как rsyslog и syslog-ng. Каждая запись в БД Journal будет содержать набор параметров в формате "переменная=значение". С целью обеспечения структурирования инфомрации, переменные могут создаваться произвольно. Кроме текстовых данных допускается прикрепление бинарных дополнений, которые могут содержать такие связанные с отражаемыми в логе событиями, как core-дампы, данные ATA SMART, диагностические дампы SCSI и т.п.

По своему формату БД Journal будет комбинацией классических линейных логов и идей, используемых репозитории Git. Как в случае с обычными логами, данные будут добавляться в конец БД с небольшим изменением служебных заголовков в начале файла. Данные будут храниться в сжатом виде. Каждое поле в блоке данныз будет сохраняться как независимый объект, что позволит минимизировать дисковое пространство при наличии типовых значений (например, при сохранеии поля с именем хоста, если такое имя уже было в логе, вместо дублирования информации будет помещена ссылка). Сообщения от непривилегированных пользователей будут размещаться в отдельных файлах БД, привязанных к логину пользователя. Подобный подход позволяет ограничить доступ к логам только для их владельцев (для доступа к системным логам пользователь должен входить в спецальную группу).

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

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

Кроме выполнения функций syslog, новая система сможет заменить собой и другие типы логов, такие как журнал входа в систему (wtmp), журнал начальной загрузки и логи системы аудита. Источником поступления сообщений может быть как стандартный интерфейс syslog(3), так и вызов printk() из ядра, а также различные специализированные API. В будущем рассматривается возможность перехвата сообщений от прошивок (логи UEFI) и задействование расширенных механизмов журналирования в ядре Linux. Начальная реализация Journal будет включать в себя минимальную поддержку передачи логов по сети, которая будет ограничена простым копированием файлов БД на центральный хост, используя scp, rsync или NFS. В будущем появятся более серьёзные средства для непрерывного приёма и отправки новых записей по сети.

Особенности Journal:

• Упрощение: небольшой размер кода с минимальным числом зависимостей;
• Автоматизация работы без необходимости ручного обслуживания: ведение журнала критически важная функциональность для отладки и мониторинга систем, поэтому работа должна вестись с оглядкой на возникновение внештатных ситуаций. Например, следует контролировать расходование свободного места в разделе /var и применять соответствующие методики ротации логов и ограничения интенсивности записи в лог;
• Устойчивость: файлы с логами должны быть непосредственно доступны для администраторов и пригодны для простого копирования по сети с использованием штатных средств, таких как scp, без нарушения целостности, даже если лог скопирован не полностью. Возможность анализа лога должна быть доступна без необходимости запуска демона журналирования, обслуживающего БД с логами;
• Переносимость: файлы с логами не должны зависеть от типа системы и CPU. Например, лог созданных на встраиваемом устройстве на базе архитектуры ARM должен быть просмотрен и на обычном ПК;
• Производительность: все операции по добавлению данных в лог и просмотру лога должны выполняться с максимальной скоростью;
• Интеграция: Новая система ведения логов должна плотно интегрироваться с другими системными компонентами;
• Минимальное потребление ресурсов: файлы с журналами должны занимать минимальное место на диске, даже с учетом того, что объем генерируемых данных может быть существенно больше, чем при использовании классических журналов;
• Хранилище информации о событиях общего назначения: должно поддерживаться помещение в журнал разных типов записей, независимо от их формата и размера;
• Унификация: различные виды технологий журналирования должны быть унифицированы, все события должны храниться в едином типе хранилища и должны быть доступны для связанного анализа. Например, часто запись от прошивки следует за записью от ядра Linux и связана с какими-то действиями на уровне пользователя - важно, чтобы связь между этими тремя событиями можно было отследить;
• Поддержка высокоуровневых инструментов: должен присутствовать API, который можно использовать в программах мониторинга, восстановления после сбоев, генераторах отчетов о причинах краха и различных утилитах для просмотра логов;
• Масштабируемость: система должна работать на обычных компьютерах, на больших кластерах и на встраиваемых системах с ограниченными ресурсами, справляясь с любыми размерами журналов и интенсивностью потока событий;
• Универсальность: возможность расширения для поддержки специфичных требований отдельных приложений (формат должен быть расширяем);
• Поддержка кластеризации и сетевых функций: обеспечение единой службы журналирования для больших инфраструктур, состоящих из множества хостов;
• Безопасность: файлы с логами должны быть аутентифицированными для гарантии отсутствия изменения уже сохранённых данных.

Среди основных проблем syslog, которые попытались решить разработчики Journal, отмечаются:

• Данные сообщений не аутентифицированы. Например, любой локальный процесс может указать что он Apache с PID 4711, а syslog поверит этому и сохранит сведения в лог;
• Данные помещаются в лог в свободной и неструктурированной форме, что требует написания специальных парсеров для автоматизированного разбора логов, учитывающих множество возможных форм представления данных;
• Время записи сохраняется без учета часового пояса;
• На одной машине разными службами одновременно ведётся несколько разных журналов, таких как utmp/wtmp, lastlog, audit, логи ядра, доги прошивок, логи отдельных приложений. Подобная организация существенно затрудняет выявление связей между элементами разных логов;
• Чтение лога является очень простым, но в то же время крайне не эффективным процессом. Так как отсутствует индексация, всегда требуется полный перебор лога;
• Сетевой протокол syslog очень ограничен, например, не гарантирует доставку и не учитывает потерю пакетов;
• Атакующие могут легко отредактировать лог для сокрытия своих действий;
• Отсутствуют гибкие средства контроля доступа к логам;
• Ограничены возможности по сохранению в логе дополнительных метаданных;
• При ротации логов не учитывается свободное место и нет эффективной защиты от проведения DoS-атак через наводнение логов;
• Сжатие логов производится только после ротации, активный лог находится в несжатом виде, а архивный сжат целиком, а не на уровне отдельных записей;
• Классический Syslog непригоден для журналирования событий на раннем этапе загрузки системы;
• В лог не могут помещаться бинарные данные.