Linux standard base

ISO standard

The LSB, version 3.1, is registered as an official ISO standard. The main parts of it are:

• ISO/IEC 23360-1:2006 Linux Standard Base (LSB) core specification 3.1 — Part 1: Generic specification
• ISO/IEC 23360-2:2006 Linux Standard Base (LSB) core specification 3.1 — Part 2: Specification for IA-32 architecture
• ISO/IEC 23360-3:2006 Linux Standard Base (LSB) core specification 3.1 — Part 3: Specification for IA-64 architecture
• ISO/IEC 23360-4:2006 Linux Standard Base (LSB) core specification 3.1 — Part 4: Specification for AMD64 architecture
• ISO/IEC 23360-5:2006 Linux Standard Base (LSB) core specification 3.1 — Part 5: Specification for PPC32 architecture
• ISO/IEC 23360-6:2006 Linux Standard Base (LSB) core specification 3.1 — Part 6: Specification for PPC64 architecture
• ISO/IEC 23360-7:2006 Linux Standard Base (LSB) core specification 3.1 — Part 7: Specification for S390 architecture
• ISO/IEC 23360-8:2006 Linux Standard Base (LSB) core specification 3.1 — Part 8: Specification for S390X architecture

There is also ISO/IEC TR 24715:2006 which identifies areas of conflict between ISO/IEC 23360 (the Linux Standard Base 3.1 specification) and the ISO/IEC 9945:2003 (POSIX) International Standard.

ISO/IEC 23360 and ISO/IEC TR 24715 can be freely downloaded from ISO website.

Извлечение стего из звукового контейнера

Задание:

1. Восстановить стего по известному ключу.
2. Промоделировать фильтрацию с помощью полосового фильтра низких частот.
3. Качественно оценить влияние шума и его фильтрации на восстановленное стего.

Исходные данные: звук с внедренными данными в файле audio1.wav, зашумленный звук с внедренными данными в файлах audio2.wav.Выходные данные: звук в файлах audio_filtered.wav, audio_filterd1.wav и audio_filtered2.wav, извлеченное стегосообщение в файлах data_out.txt, data_out_noized.txt, data_out_filtered.txt, data_out_filtered1.txt, data_out_filtered2.txt Результаты: cтегосообщение успешно восстанавливается в случае, если на контейнер не было оказано сторонних воздействий. Невозможность восстановления стегосообщения после применения фильтра низких полосовых частот (с различными параметрами) подтверждает крайнюю неустойчивость метода LSB к сторонним воздействиям.
В начале попробуем извлечь сообщение из незашумленного контейнера.
Открываем контейнер:

Функция извлечения данных из контейнера.

Извлечем данные из незашумленного контейнера:

Запишем полученные данные в файл:

Попробуем проделать то же самое с зашумленным контейнером.
Откроем зашумленный контейнер:

Попробуем извлечь из него данные:

Запишем их в файл:

Как видно из файла, данные не были успешно восстановлены.
Попробуем использовать фильтр.
Для реализации фильтра используем БПФ:

Расширим массив, дополнив его нулями до длины, кратной 216:

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

Рис.1 Параметры фильтра №1

Применяем фильтр:

Запишем отфильтрованный контейнер в файл:

Попробуем извлечь из него данные:

Запишем извлеченные данные в файл:

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

Рис.2 Параметры фильтра №2

Применяем фильтр:

Запишем отфильтрованный контейнер в файл:

Попробуем извлечь из него данные:

Запишем извлеченные данные в файл:

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

Рис.3 Параметры фильтра №3

Применяем фильтр:

Запишем отфильтрованный контейнер в файл:

Попробуем извлечь из него данные:

Запишем извлеченные данные в файл:

Как видно из файла, данные не были успешно восстановлены.

Crítica

La LSB ha sido criticada por no considerar aportaciones de proyectos externos a la esfera de influencia de las compañías miembros, especialmente del proyecto Debian. Por ejemplo, la LSB especifica que los programas deberían ser distribuidos en el formato RPM de Red Hat, el cual fue inventado mucho después del formato de empaquetado deb del proyecto Debian e ignorando otros sistemas de paquetes como Pacman o PET. Es muy poco probable que los programadores del proyecto Debian cambien su formato, el cual consideran superior a RPM (al igual que otros programadores). Sin embargo, la mayor parte de la crítica recibida por este tema surge del malentendido en la sugerencia de este uso obligado del formato RPM: el estándar no dicta cuál formato de empaquetado debe ser usado por el sistema operativo, sino solamente que un formato de empaquetado debe ser soportado de manera que los paquetes de otros programadores puedan ser instalados en un sistema que sigue el estándar LSB. Debido a que Debian admite la LSB, mediante el paquete homónimo, el problema se solventa y el usuario de un sistema Debian sólo necesita usar el programa alien para transformar un paquete de formato RPM en un paquete de formato nativo (deb) e instalarlo. Es una operación que funciona la mayoría de las veces.

En otras áreas la operación de la LSB es menos controvertida, y ha sido recibida con considerable gratitud.

Changelog

2016-07-06 - Steve Langasek <steve.langasek@ubuntu.com>
lsb (9.20160110ubuntu0.2) xenial; urgency=medium
* Revert changes to python2 vs. python3 installation of lsb_release.py,
inadvertently breaking imports of lsb_release in python2.  LP: #1596638.

2016-06-21 - Steve Langasek <steve.langasek@ubuntu.com>
lsb (9.20160110ubuntu0.1) xenial; urgency=medium
* lsb_release.py: restore support for querying the list of installed
modules, since for the moment some modules are still supported.

* Re-added LSB compatibility packages, so that auto-downloadable
LSB-based printer driver packages work.  Thanks to Till Kammpeter
for the patch.  LP: #1536353
* Added Conflicts/Replaces against cups-filters-invalid-mta and
cups-filters-lsb for upgrade compatibility from the Xenial development
cycle.

2016-01-10 - Didier Raboud <odyx@debian.org>
lsb (9.20160110) unstable; urgency=medium
* Merge the last Ubuntu diff

* Add 01-upstart-lsb from the upstart package, and make executing rc.d
scripts no-op if there is an upstart job for that script

2015-09-17 - Didier Raboud <odyx@debian.org>
lsb (9.20150917) unstable; urgency=medium
* Demote Build-Depends from python3-all-dev to python3-all (Closes: #799210)

2015-08-26 - Didier Raboud <odyx@debian.org>
lsb (9.20150826) unstable; urgency=low
* Drop all the LSB compatibility packages besides lsb-release and lsb-base
- Drop packages-availability checking in lsb-release
- Truncate README.Debian to a minimum
- Document this in lsb-base.NEWS.Debian
* Change the versioning number to avoid any ambiguity; use joeyh's
version.date, with version being Debian next stable's

2015-08-12 - Didier Raboud <odyx@debian.org>
lsb (4.1+Debian14) unstable; urgency=low

* Convert packaging to Debhelper 9
* Port to python3, keep compatibility symlink for lsb_release.py
(Closes: #719063)

* Add Turkish translation of lsb debconf messages (Closes: #757509)

* Add gbp.conf
* Rework the releases codename handling:
- Depend and Build-Depend on distro-info-data, and populate the
RELEASES_CODENAME_LOOKUP from that reference
- Drop meaningless tests trying to compare random release names
* Make sure '-proposed-updates' don't sort before unstable
* Actuall ignore suites when guessing the release from apt
* Fix comparison of testing codename (Closes: #691744)
* Bump Standards-Version to 3.9.6 without changes needed

2014-10-20 - Ondřej Surý <ondrej@debian.org>
lsb (4.1+Debian13+nmu1) unstable; urgency=medium

* Non-maintainer upload with maintainer agreement
* Change libjpeg62 dependency to libjpeg62-turbo (Closes: #766023)

2014-06-09 - Didier Raboud <odyx@debian.org>
lsb (4.1+Debian13) unstable; urgency=medium

* test/test_lsb_release.py: also, make lsb_release ignore dpkg origins for
the test, otherwise the test fails on derivatives.

* Use open() rather than file() in initdutils.py, for Python 3 compatibility
(see LP #1035136)
* Test fileob and strob against None in RFC822Parser.__init__ rather than
testing their truth value, to avoid a misleading error in the case of a
file with no LSB headers

* Allow lsb-printing to depend on cups-filters | ghostscript-cups

* Revert "Fix the remaining problems of initdutils.py python3 compatibility"
(Closes: #743903)
* Allow multiarch alternatives of libc6-i386 and lib32z1.
Thanks to Michael Biebl (Closes: #748426)

* In lsb_release, don't forget CODENAME when it's testing; therefore stop
* calling apt-cache policy again (Closes: #747413)

The LSB 5.0 Specification

This is the approved final version of the LSB 5.0 specification.
The tables below present two popular formats, you may also go to the
page with all formats.

Release notes outlining
changes from the previous release of the specification can be found
at
http://www.linuxfoundation.org/en/ReleaseNotes50

Note that the LSB 5.0 Core specification set is an evolution of
the ISO/IEC International Standard 23360, which corresponded
to LSB 3.1. This edition is not to be considered an ISO standard.

LSB 5.0 was released June 3, 2015.

The LSB 4 Specification Series

This is the Linux Standard Base
version 4 specification series. Following on from LSB 3 and LSB 2,
this version is evolutionary, rather then revolutionary.

Requires

The LSB 4.0 Specification

This is the approved final version of the LSB 4.0 specification.
The tables below present two popular formats, you may also go to the
page with all formats.

Release notes outlining
changes from the previous release of the specification can be found in

the release notes for LSB 4.0.

Note that the LSB 4.0 Core specification is an evolution of
the ISO/IEC International Standard 23360, which corresponded
to LSB 3.1. This edition is not to be considered an ISO standard.

LSB 4.0 was released May 1, 2009

The LSB 3 Specification Series

The LSB Specification evolution continues with the LSB 3 release.
Built on the same structure as the 2.x specification, this version
of the LSB is based on a new C++ ABI, and includes many improvements
throughout the specification.

Но не менее значимый

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

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

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

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

Вот и все, на этом метод заканчивается.

DNS-Tunneling: тоже стеганография?

Можем ли мы считать использование DNS-туннеля подвидом стеганографии? Определенно, да. Для начала давайте вспомним, как выглядит схема DNS-туннеля в общих чертах.

В закрытой сети с пользовательской машины посылается запрос на «резолв» домена, например, wL8nd3DdINcGYAAj7Hh0H56a8nd3DdINcGYAlFDHBurWzMtimbadguycom (где доменное имя второго уровня не несет смысловой нагрузки). Локальный DNS-сервер передает запрос внешнему DNS-серверу. Тому, в свою очередь, неизвестно имя 3-го уровня и запрос передается дальше. Таким образом, по цепочке перенаправлений от одного DNS-сервера к другому запрос достигает DNS-сервера домена imbadguycom.

Вместо разрешения запроса на сервере злоумышленник может извлечь из полученного домена нужную ему информацию, расшифровав первую часть его имени. Например, таким способом можно передать информацию о системе пользователя. В ответ DNS-сервер злоумышленника так же посылает некую информацию в зашифрованном виде, передавая ее в доменном имени 3-го уровня или выше.

Таким образом, злоумышленник имеет в запасе для каждого DNS резолва 255 символов, до 63 символов для поддоменов. 63 символа в одну сторону — 63 в ответ, 63 — туда, 63- обратно… Неплохой канал для передачи данных! А главное — скрытый, ведь невооруженным взглядом не видно, что идет обмен какой-то дополнительной информацией.

Для специалистов, знакомых с сетевыми протоколами и в частности с DNS-туннелированием, такой дамп трафика будет выглядеть довольно подозрительно: очень уж много успешных резолвов длинных доменов. В данном случае мы наблюдаем реальный пример трафика зловреда Backdoor.Win32.Denis, который использует DNS туннель как скрытый канал общения со своим командным центром.

Обнаружить DNS-туннель можно с помощью любой известной IDS, например, Snort, Suiricata или BRO Ids. Как именно распознать DNS-туннелирование? Существуют различные способы. Например, очевидно, что доменные имена для резолва при туннелировании значительно длиннее, чем обычно. В сети можно найти достаточное количество вариаций на эту тему:

Совсем примитивно, но встречается и такое:

Тут можно экспериментировать и стремиться найти свой идеальный баланс между количеством ложных срабатываний и нахождением реального DNS-туннелирования.

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

Если в доменном имени присутствуют символы, характерные для Base64 кодировки, то это выглядит довольно подозрительно, не так ли? Если при этом еще и длина не маленькая, то явно стоит присмотреться повнимательней.

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

Хочется отметить, что даже такой простой по своему смыслу подход к поиску DNS-туннелей дает очень хорошие результаты. Благодаря нескольким таким правилам для IDS мы на входящем потоке вредоносного ПО, поступающем к нам в «Лабораторию», обнаружили несколько новых, неизвестных до этого бэкдоров, использующих скрытый канал общения с командным центром — DNS-туннель.

История версий

• 1.0: Первый релиз, июнь 2001.
• 1.1: Январь 2002. Добавлены аппаратные спецификации (IA-32).
• 1.2: Июнь 2002. Добавлены аппаратные спецификации (PowerPC 32-bit). Июль 2002: начата сертификация.
• 1.2.1: Октябрь 2002. Добавлена архитектура Itanium.
• 1.3: Декабрь 2002. Добавлены аппаратные спецификации (Itanium, Enterprise System Architecture/390, z/Architecture).
• 2.0: Сентябрь 2004. LSB разделено на LSB-Core, LSB-CXX, LSB-Graphics, LSB-I18n (не выпущено). Добавлены аппаратные спецификации (PowerPC 64-bit, AMD64). LSB синхронизовано с Single UNIX Specification (SUS) version 3.
• 2.0.1: ISO-версия LSB 2.0, включающая спецификации для всех архитектур (кроме LSB-Graphics, для которого доступна только начальная версия).
• 2.1: Выпущен в 2004.
• 3.0: 1 июля 2005. Наряду с другими изменениями в библиотеках, C++ ABI изменено на используемое в gcc 3.4. Спецификация ядра обновлена до ISO POSIX (2003), Техническое Исправление 1: 2005.
• 3.1: 31 октября 2005. Эта версия представлена как ISO/IEC 23360.
• 3.2: 19 января 2008.
• 4.0: 11 ноября 2008. Эта версия содержит следующие свойства:
  • glibc 2.4;
  • двоичная совместимость с LSB 3.x;
  • более простой SDK;
  • поддержка новых версий графических библиотек GTK и Cairo;
  • Java;
  • более простые способы создания LSB-совместимых пакетов RPMp;
  • Crypto API (через библиотеку Network Secure Sockets).
• 4.1: 16 февраля 2011.
• 5.0: 2 июня 2015.
  • Обновление версий библиотек;
  • Добавлены библиотеки SANE, libncursesw, libtiff и libxslt;
  • Добавлена поддержка XCB API для X11;
  • Удалена поддержка Qt3.

The LSB 3.2 Specification

This is the approved final version of the LSB 3.2 specification.
The tables below present two popular formats, you may also go to the
page with all formats.

With this version, two new mandatory specifications, LSB-Printing
and LSB-Languages (which incorporates the Perl and Python dynamic
languages), as well a Trial Use specification, are introduced.
In addition, the Optional Qt4 specification is now mandatory,
and is incorporated in the Desktop specification.

Release notes outlining
changes from the previous release of the specification can be found in

the release notes for LSB 3.2.

Note that the LSB 3.2 Core specification is an evolution of
the ISO/IEC International Standard 23360, which corresponded
to LSB 3.1. This edition is not to be considered an ISO standard.

LSB 3.2 was released January 25, 2008

Стандарт ISO

LSB зарегистрирован в качестве официального стандарта ISO. Его основные части:

Критика

Стандарт LSB критикуют за то, что он не принимает предложения проектов, в особенности Debian, находящихся за пределами круга его членов.

К примеру, LSB предписывает поставлять программные пакеты (packages) в формате RPM, который был разработан гораздо позже формата deb, однако разработчики Debian не собираются менять свой формат, так как считают его лучше RPM.

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

Так как в Debian присутствует опциональная поддержка LSB (версии 1.1 в woody, 2.0 в sarge, а позднее 3.1 в etch и 3.2 в lenny), проблема исчезает при более близком рассмотрении (то есть пользователь всего лишь должен использовать утилиту alien для преобразования и установки сторонних пакетов). Таким образом, на практике Debian совместим с LSB.

Известный в сообществе открытого программного обеспечения программист Ульрих Дреппер (известен как лидер проекта Glibc) критиковал LSB за плохое качество тестирования, которое может привести к несовместимости между сертифицированными дистрибутивами.

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

В остальных областях LSB менее противоречив и нашёл большее признание.

Backward compatibility

LSB aims to make userspace binaries portable

The LSB is designed to be binary-compatible and produce a stable application binary interface (ABI) for independent software vendors. To achieve backward compatibility, each subsequent version is purely additive. In other words, interfaces are only added, not removed. The LSB adopted an interface deprecation policy to give application developers enough time in case an interface is removed from the LSB.

This allows the developer to rely on every interface in the LSB for a known time and also to plan for changes, without being surprised. Interfaces are only removed after having been marked «deprecated» for at least three major versions, or roughly eleven years.

LSB 5.0 is the first major release that breaks backward compatibility with earlier versions.