Вопрос или проблема
Ядро: 5.8.0-31-generic x86_64 разрядность: 64 компилятор: gcc версия: 10.2.0 Рабочий стол: i3 4.18
Дистрибутив: Ubuntu 20.10 (Groovy Gorilla)
Tripwire работает нормально на виртуальной машине, но выдает ошибку сегментации на хосте, смотрите ниже:
Я получаю следующее, когда запускаю tripwire –init -v
sudo tripwire --init -v
Open Source Tripwire(R) 2.4.3.7.0 собран для x86_64-pc-linux-gnu
Open Source Tripwire 2.4 Части защищены авторским правом 2000-2018 Tripwire, Inc. Tripwire является зарегистрированной
торговой маркой Tripwire, Inc. Это программное обеспечение поставляется БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ;
для подробностей используйте --version. Это свободное программное обеспечение, которое может быть распространено
или изменено только при соблюдении определенных условий; смотрите COPYING для подробностей.
Все права защищены.
Открытие файла конфигурации: /etc/tripwire/tw.cfg
Этот файл зашифрован.
Открытие ключевого файла: /etc/tripwire/site.key
Открытие ключевого файла: /etc/tripwire/zika.gattaca.net-local.key
Пожалуйста, введите ваш локальный пароль:
Открытие ключевого файла: /etc/tripwire/site.key
Открытие файла политики: /etc/tripwire/tw.pol
Этот файл зашифрован.
Анализ файла политики: /etc/tripwire/tw.pol
Создание базы данных...
*** Обработка файловой системы Unix ***
Обработка: /usr/sbin
--- Создание информации для: /usr/sbin
Программное прерывание заставило завершение: Ошибка сегментации
Ошибка сегментации (образ ядра сброшен)
На всякий случай, чтобы предотвратить копирование и вставку, я сам нашел несколько ответов:
Привет, Шейн, есть пара вещей, которые вы можете попробовать сразу —
Ваш журнал, похоже, указывает на то, что инициализация спотыкается о что-то в /proc. Если вам вообще не нужно сканировать /proc, вы можете просто добавить строку “! /proc ;” в вашу политику, чтобы исключить его.
Также вы можете попробовать “–init –verbose”, что должно указать, на каком файле (или псевдо-файле /proc, в данном случае) происходит сбой. Если вы попробуете это несколько раз и сбой произойдет последовательно с одним и тем же объектом или одним и тем же типом объекта, это будет намек, что с ним есть что-то особенное, с чем нам нужно разобраться. У меня нет виртуальной машины 17.04 под рукой, но я попробую сканировать /proc на 16.04 и посмотрю, что произойдет у меня.
Еще одна вещь, которая, как известно, вызывает сбои, это комбинация статически связанных бинарных файлов и удаленных сервисов каталогов (NIS, LDAP, AD и т.д.). (Смотрите вопрос №11 для прежнего примера). Если это окажется проблемой, вы можете либо a.) использовать опцию конфигурации RESOLVE_IDS_TO_NAMES=false (введена в OST 2.4.3.2), либо использовать динамически связанные бинарные файлы.
У меня также возникла эта проблема, и у меня есть страница об этом здесь.
Окончательное решение в моем случае заключалось в редактировании файла twcfg.txt и добавлении туда RESOLVE_IDS_TO_NAMES=false.
Однако сначала я закомментировал несколько файлов: /proc и /dev, а также /boot, в котором в моем случае была удаленно смонтированная папка, которая, по словам tripwire, ему не нравится. Известно, что они вызывают проблемы.
Еще две возможности: некоторое время назад у меня был файл размером более 2 Гб, и, видимо, tripwire спотыкался на них. В папке /usr/sbin таких не должно быть, однако.
Один человек упомянул, что у него был файл с правами -r——– (400) в папке /usr/sbin. Изменив свой файл политики, он скрыл этот файл, и затем все заработало. Возможно, вы находитесь в такой же ситуации. Я не мог видеть такого файла в своей папке /usr/sbin, однако.
Наконец, Teakwood J Overclutch, который столкнулся с той же проблемой, решил ее, пересобрав tripwire из исходного кода. Если ничего другого вам не помогает, это может быть решением. Я предполагаю, что сборки Debian/Ubuntu используют один и тот же исходный код, но у них могут быть патчи, некоторые из которых могут что-то ломать!
Спасибо, это “RESOLVE_IDS_TO_NAMES=false” спасло мой день.
Ответ или решение
Сегментационная ошибка в Tripwire может возникать по разным причинам и требует детального анализа для выявления источника проблемы. Ваш случай демонстрирует несколько возможных причин и решений данной проблемы, которые мы рассмотрим ниже.
Теория
Сегментационная ошибка (segmentation fault) обычно происходит, когда программное обеспечение пытается обратиться к области памяти, к которой у него нет прав доступа. Это может быть связано с ошибками в коде программы, некорректными разрешениями или специфическими особенностями системы. В случае Tripwire, известной системы для контроля целостности файлов и обнаружения изменений, такая ошибка может возникать по следующим причинам:
-
Особенности файловой системы: Некоторые области файловой системы, такие как
/procили/dev, содержат динамически изменяющиеся или виртуальные файлы, которые могут вызывать проблемы при сканировании. -
Статически связанные бинарные файлы и удаленные службы каталогов: Использование статически связанных бинарников в сочетании с такими службами, как NIS, LDAP или Active Directory, может вызывать конфликты.
-
Разрешения файлов и их размеры: Файлы с нестандартными разрешениями или очень большие файлы также могут вызывать ошибки при обработке.
-
Проблемы с конкретными файлами или конфигурацией: Некоторые файлы могут иметь конфликты с правилами политики Tripwire, что в свою очередь ведет к ошибкам.
Пример
Ваш случай демонстрирует конкретную ситуацию, когда Tripwire запускается с ошибками на хост-машине, хотя работает нормально в виртуальной машине. В выводе командной строки можно увидеть, что проблема возникает на этапе генерации информации для /usr/sbin, после чего происходит сегментационная ошибка. Вот некоторые шаги, которые вы предприняли, чтобы диагностировать и попытаться решить проблему:
- Исключили определенные директории, такие как
/proc, из сканирования. - Использовали параметр
--verbose, чтобы попытаться выяснить, какой точно файл вызывает ошибку. - Пробовали изменить конфигурационные параметры, такие как
RESOLVE_IDS_TO_NAMES=false, что может помочь избежать специфических проблем с разрешением ID.
Применение
Для решения проблемы с сегментационной ошибкой в Tripwire рекомендуется выполнить следующие действия:
-
Изменение файлов конфигурации: Откройте файл
twcfg.txtи добавьте строкуRESOLVE_IDS_TO_NAMES=false. Это предотвратит попытку Tripwire разрешать идентификаторы пользователе к именам, что может быть причиной ошибок в некоторых системах с нестандартными сетевыми конфигурациями. -
Исключение проблемных областей: В вашей политике безопасности Tripwire стоит добавить строки для исключения сканирования директорий
/proc,/devи любых удаленно смонтированных файловых систем, например, в каталоге/boot. Сделать это можно добавлением строк вида! /proc ;в файле политики. -
Проверка файлов и разрешений: Осуществите проверку папки
/usr/sbinна наличие файлов с нестандартными разрешениями. Файлы с разрешениями, как, например,-r--------(400), могут нуждаться в адаптации политики. -
Перекомпиляция ПО: Если вышеописанные методы не увенчались успехом, возможно, стоит попробовать пересобрать Tripwire из исходного кода, взятого прямо с GitHub. Возможные патчи в бинарниках, предоставленных дистрибутивом, могут являться причиной ошибок.
-
Логирование и анализ ошибок: Используйте логирование и режим отладки для сбора более детальной информации о том, на каком этапе происходит ошибка. Это может включать запуск команды
tripwire --init --verboseнесколько раз для отслеживания того, на каком конкретно объекте программа падает. -
Использование динамически связанных бинарных файлов: Проверьте, что Tripwire использует динамически связанные библиотеки вместо статически связанных, так как это может устранить некоторые конфликты с сетевой и файловой латенцией.
Следуя этим шагам в систематическом ключе, можно не только устранить текущие ошибки, но и улучшить надежность и стабильность работы Tripwire в дальнейшем. Вы также можете обратиться к сообществу за дополнительной поддержкой или поискать на форумах возможные специфические решения для вашей версии и конфигурации Ubuntu.