А зачем?

Не запускаю инсталляторы руткитов, очевидно.

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

Вообще предпочтение, если возможно запускать через firejail, в планах docker, chroot, просто виртуалки. rootkit запускался эпизодически

Плюс иногда и выборочно lsof|grep -i tcp|grep -i established.

Регулярная пересборка обновлений ядра.

glsa-check полезно

Что-то он мне с десяток варнингов выдал

На библиотеки keyutils говорит, что это sniffer component O_o

System checks summary
=====================

File properties checks...
    Files checked: 149
    Suspect files: 1

Rootkit checks...
    Rootkits checked : 501
    Possible rootkits: 12

Читай этот пост ClamAV (комментарий) и ещё 3 поста анонима ниже, 4 пост не читай, это плохой аноним.

У меня NixOS. Его разве рутуют?

glsa-check полезно

Приятно встретить однополчанина

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

Есть две идеи:

1. Написать проверочку для distfiles/*, получить архивы, их подписи, хеши с других источников, архива интернета, можно начать с официальных сайтов и сверить с портадж. (Помню инцендент с vsftpd, разные струи одной версии).

2. Возможность пересборки для верификации бинарников. Желательно чтобы такая возможность была в базовой системе. В теории если стейдж, portage-*, /etc/portage, список команд или скрипт установки одинаковы,- системы должны получится идентичны.

У меня NixOS. Его разве рутуют?

Настрой любую крыптографическую верификацию системы, периодически загружается с LiveCD/DVD и проверяй целосность... отловленные руткиты отсылай тем кто пишет антивирусные сигнатуры.

А чем он отличается в этом плане?

Руткиты в дистрибутивах Линукс.

У меня очень важный вопрос для всех пользователей разных дистрибутивов Линукс:

Выполните в своём любимом дистре следующие 3 команды:

dmesg | grep -i 'x.*509'
modinfo usbcore | grep '^sig'
ls -l /usr/src/linux/certs/signing_key.pem

Первая команда покажет загруженные сертификаты. Они должны быть уникальны для каждого административного домена. Единый сертификат для всего дистрибутива неприемлем!

Вторая, вместо usbcore, можно ввести название любого другого модуля ядра, покажет подписаны ли модули ядра.

Третья - спрятан/уничтожен ли секретный ключ для подписи модулей ядра, этого файла в рабочей системе быть не должно!

И отпишите здесь название дистра и результат проверки.

Нейронные сети, конечно же

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

arch:

1. обнаружено 5 сертификатов

2. rfkill подписан, остальные не проверял

3. нет такого файла или каталога

Если бы это еще работало.

См. мой доклад двухлетней давности: https://youtu.be/Vpp3B8K0V8A?t=1154.

Не сутулься!

я так на винде баловался, брал простейшие шел команды - например эту

Get-AppxPackage  -AllUsers | Remove-AppxPackage

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

Только вот тут ситуация не изменилась и через несколько лет.

Читаю на ночь код того, что буду устанавливать через месяц или год.

Fedora 30

bvn13@bvn13-book  ~  dmesg | grep -i 'x.*509'                                                                                                   ✔  1077  22:16:19 
[    0.716939] Asymmetric key parser 'x509' registered
[    0.802061] Loading compiled-in X.509 certificates
[    0.825092] Loaded X.509 cert 'Fedora kernel signing key: 7af26f362e0cda74a8cb6c31a1dc0c5ab045ce31'
[    2.255338] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20190509/nsarguments-59)
[    2.255384] ACPI Warning: \_SB.PCI0.RP01.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20190509/nsarguments-59)
[    6.535573] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    6.537466] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
 bvn13@bvn13-book  ~  modinfo usbcore | grep '^sig'~                                                                                             ✔  1078  22:16:21 
modinfo: ERROR: Module usbcore not found.
 bvn13@bvn13-book  ~  ls -l /usr/src/linux/certs/signing_key.pem                                                                             1|1 ↵  1079  22:16:38 
ls: cannot access '/usr/src/linux/certs/signing_key.pem': No such file or directory
 bvn13@bvn13-book  ~   

Такая же фигня на Manjaro

Все не как у людей же. FHS не соблюдается, да даже libc не по стандартному пути

Все не как у людей же. FHS не соблюдается, да даже libc не по стандартному пути

Значительная часть эксплоитов даже не заметит разницы, потому что, внезапно, направлена на ядро.

🤦 okay

Никак, хотя была машинка попой в наружу, но после выставления попы всё переводилось в RO и только 2 рабочих каталога были активными, это tmp с noexec и каталог с базой и всё. Вот и вся безопасность, а вся эта активная защита хтьфу. Если в софте есть дырка то она никуда не денется пока её не закрыть, поэтому запрещено всё что не разрешено. Но на домашней системе лично мне глубоко всрать =)

Как же вы будете исполнять скрипты из /tmp, если он с noexec? Жутко неудобно наверное, это ж никакой софт работать не будет.

Он для мусора, исполняемое в /usr/local/project/bin/ который в RO и может писать только в /tmp

Ну так да, у меня куча динамических скриптов через /tmp работает, а так всё развалится. :(

Ну, я хз как там с динамикой у меня на KORE.io был сервер, всё было просто как палка =) Ну, а если ты ты генерируешь скрипты и потом исполняешь их думаю у тебя не 100500 скриптов генерятся поэтому можно на tmp оставить noexec сделать ещё одну tmpfs размером метров в 50 (хватит наверное под дин-скриптоту) всё генерированно-запускаемое скидывать туда (по факту просто в память) после исполнения удалять, и вообще принципиально удалять всё что там может появится кроме момента когда нужно исполнить что-то. Но меня не слушай это просто идеи. Я уж 100 лет ничего подобного не делал =)

1. Сертификаты подгружаемые в ядро Линукс.

1. обнаружено 5 сертификатов

Это капец как настораживает!

В подавляющего большинства должен быть один единственный сертификат, УНИКАЛЬНЫЙ для каждой установки Линукс. Это сертификат с помощью которого ядро крыптограытчески верифтцирует свои модули. В ядре есть только открытый ключ этого сертификата необходимый для верификации модулей. Секретный ключ должен уничтожался сразу после выполнения 'make modules_install' или очень надёжно прятался (а зачем его прятать? кому он нужен кроме руткита?). Если руткит украдет секретный ключ сертификата то выполнит:

/usr/src/linux/scripts/sign-file sha512 /usr/src/linux/certs/signing_key.pem /usr/src/linux/certs/signing_key.x509 virus_rootkit.ko

Зачем у арча аж 5 сертификатов в ядерном кейринге? Заметте каждый с этих сертификатов должен быть уникален для каждой установки арча!

У меня в самых продвинутых установках GNU/Linux используется только 4 сертификата, хоть теория рекомендует максимум 3:

1. Ядерный сертификат для автоматической подписи модулей ядра.

2. Мой личный корневой сертификат CA который гружу в ядерный кейринг и использую для подписи других сертифткатов.

3. Сертификат в кейринге IMA подписанный моим CA (его считают устаревшим) используется для верификации всех неизменяемых файлов (бинарей, библиотек, настроек) начиная с init.

4. Сертификат в кейринге EVM используется для защиты разных атрибутов файла в файловых системах Линукс (IMA, Linux capabiletis, selinux,...)

Посмотреть загруженные сертификаты иногда можно в:

cat /proc/keys

Ещё раз в каждой установки Линукс ВСЕ сертификаты ядра должны быть уникальны!!! Наличие хоть одного одинакового сертификата ядра в дистрибутиве неприемлемо! Товарищ майор подойдёт к разрабу с длинным, толстым и сильно горячим паяльником и попросит предоставить этот ключ ему!!!

cat /proc/keys

Ты про этот?

Build time autogenerated kernel key

В Manjaro один такой

2. Подписание модулей ядра Линукс

Если в настройках ядра указано:

CONFIG_MODULE_SIG_FORCE=y

или при загрузки указан параметр ядра:

module.sig_enforce=1

то ядро Линукс не должно грузить модули не подписанные каким небудь ключом с кейринга ядра.

modinfo имя_модуля

выводит информацию о наличии подписи, если она есть.

Для тестирования можно с одного ненужного модуля в /lib/modules/*/kernel/*/*.ko удалить цифровую подпись и попробовать его погрузить в ядро:

modprobe имя_модуля

rmmod имя_модуля

Подписанный модуль нормально загружаться и его видно в lsmod

Теперь удаляем подпись:

strip --strip-debug /lib/modules/*/kernel/*/*.ko

modprobe имя_модуля

Выдаст ошибку, что нужный ключ отсутствует.

в самых продвинутых
используется только 4 сертификата

у меня в sid 4 сертификата - типа самый продвинутый?

cat /proc/keys

но загружено только 2

Товарищ майор

это вообще лажа - клал на этих товарищей с высокой колокольни

3. Гарантировать надёжное уничтожение/хранение секретных ключей ядра Линукс.

3. нет такого файла или каталога

Он был создан и во время выполнения 'make modules_install' подписал все модули ядра. Вы должны гарантировать его надёжное уничтожение/хранение.

ls -l /usr/src/linux*/certs/signing_key.pem

find / -name signing_key.pem -type f

Вы должны гарантировать надёжное уничтожение/хранение ВСЕХ созданных секретных ключей ядра после подписания ими всех модулей ядра, программ, библиотек, настроек, файловых атрибутов!

Стырят у вас ключ, разрабы дистров передадут ключ товварищу майору и будут здесь рыдания по поводу руткита в GNU/Linux и плохих антивирусов.

PS: Если вас вся эта криптография уже достала можете скомпилировать монолитное ядро без протдержки модулей.

Федорка ;)

Loaded X.509 cert 'Fedora kernel signing key: 7af26f362e0cda74a8cb6c31a1dc0c5ab045ce31'

Этот ключ должен создаватся при каждой инсталляции Fedora и быть уникальным для каждого компа с Fedora GNU/Linux.

Наличие единого секретного ключа в разработчиков дистра - дыра безопасности неприличного размера.

Дайте вывод «dmesg | grep -i 'x.*509'» с другой установки федорки. ;)

у меня нет другой установки федоры

Манджаро.

В Manjaro один такой

Один это нормально, главное чтобы он был уникален в каждой установки Manjaro GNU/Linux, а не как в федорке один на всех с копией секретного ключа в майора АНБ.

разрабы дистров передадут ключ товарищу майору

разрабы sid передадут ключ товарищу майору?

ядро без протдержки модулей

это вообще отстой какой то...

послушай товарищ - ты сильно зациклен на товарищах майорах, расслабся!

desktop / # dmesg | grep -i 'x.*509'
desktop / # modinfo usbcore | grep '^sig'
modinfo: ERROR: Module usbcore not found.
desktop / # modinfo soundcore | grep '^sig'
desktop / # ls -l /usr/src/linux/certs/signing_key.pem
ls: cannot access '/usr/src/linux/certs/signing_key.pem': No such file or directory

Расскажите, что делать? Я готов на любые эксперименты.

 $ cat /proc/keys
0abcefaa I--Q---   262 perm 3f030000  1000  1000 keyring   _ses: 1
32323232 I--Q---     1 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty

Я готов на любые эксперименты

от тебя больше ничего не требуется, ты свои ключи слил - дальше товарищ майор экспериментировать будет!

Дебиан.

у меня в sid 4 сертификата - типа самый продвинутый?

А цель этих сертификатов? Вы гарантирует что все эти сертификаты были созданы на вашем компе во время установки Debian GNU/Linux? Вы гарантирует надёжное уничтожение/хранение всех секретных ядерных сертификатов Линукс в дистрибутиве Дебиан?

Вот на вас всех уже ножи точят: out-of-tree v1.0.0 ― инструментарий для разработки и тестирования эксплоитов и модулей ядра Linux

Максимум угрозы - деанонимизация.

cat /proc/keys

dmesg | grep -i 'x.*509'

modinfo usbcore | grep '^sig'

Вывод этих комманд даёт только отпечаток ключей. Ядро не знает секретного ключа. На безопасность вашей установки это не влияет, Я, анонимус ЛОРа, гарантирую.

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

В случае хорошего дистрибутива GNU/Linux, в котором все ядерные ключи уникальны для каждой его установки, отпечаток ключа может использоваться товарищем майором для вашей деанонимизации!!! Но в виду того что отпечатки может просмотреть только root риск не велик. В прочем нормальные дистры предоставляют инструментарий для замены ядерных ключей - переустановка системы. ;)

Так там вроде это нужно для secure boot? Типа фича, сесурити.

Ну в смысле 1 ключ на всех.

Расскажите, что делать? Я готов на любые эксперименты.

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

Если желаете включить верификации модулей вам необходимо чуть перенастроить и пересобрать ядро Линукс, начни читать здесь: https://wiki.gentoo.org/wiki/Signed_kernel_module_support

Заметь это лишь один с многих путей защиты модулей ядра Линукс - самый простой, но далеко не полный. Он не защищает само ядро и инитрд.

Тебе надо отдельной технологией защитить все програмы, библиотеки, настройки.

Технологиями безопасной загрузки защитит ядро, инитрд и на конец сам загрузчик.

Можешь посмотреть по ссылкам:

Защита модулей, настроек GRUB, ядра и инитрд: https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

Дополнительные опции защиты Линукс: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Config...

IMA/EVM крыптографически верифицирует всего начиная с init, включая все подгружаемые модули ядра: https://sourceforge.net/p/linux-ima/wiki/Home/

Для начала поставь любую IDS и научись её правильно использовать.

Правильное применения Антивируса в Линукс.

Расскажите как вы защищаете свои рабочие станции? (комментарий)

Ну в смысле 1 ключ на всех.

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

[ 6.535573] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 6.537466] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

А зачем этот сертификат Фёдоре? Что за «regulatory database»? Посмотри, если разберёшся, оно наверно кроме модулей верифтцирует некоторые этапы загрузки. Интересно насколько продвинулись и какие технологии используют в Фёдоре?