https://hardenedbsd.org/content/easy-feature-comparison https://wiki.gentoo.org/wiki/Hardened/Toolchain https://wiki.ubuntu.com/Security/Features https://wiki.freebsd.org/Hardening Ничего из этого нет на FreeBSD. Точнее частично ASLR есть в develop ветках FreeBSD. В HardenedBSD довольно давно. В OpenBSD вообще раньше всех ОС появилось почти 20 лет назад. Только с началом программирования на Си начал хоть как-то понимать про что это всё и чем оно важно. Точнее под вопросом важен ли ASLR: полно людей считает что это security by obscurity, значит нафиг нужно, не серьёзно. Про ASLR не много чего могу сказать, но то что SbO это не серьёзно -- солидарен. Меня не продолжают удивлять рекомендации менять порты SSH-а или имена учётных записей чтобы злоумышленник имел чуть чуть более высокий порог входа. Я не считаю этот геморрой стоящим этого. В чём проблема с SSH? Если используется аутентификация по ключам, то пусть хоть об-brute-force-ятся. А если где-то применяются пароли -- то я считаю вообще не стоит задумываться о безопасности с таким подходом: тут ничего не поможет. На деле попробовал использовать SSP: https://wiki.osdev.org/Stack_Smashing_Protector включаемый -fstack-protector опцией. В FreeBSD оказывается можно глобально для портов включить эту опцию. Overhead, говорят, очень незначительный. А я видел что даже не злонамеренный код может набедокурить -- и раздражать то будет неясность его поведения и что вообще происходит. ASLR+PIE вроде в FreeBSD всё же собираются внедрить. Удивляет что Windows уже давно в курсе про многие подобные технологии и использует их. Всякие RELRO и BIND_NOW вроде не касаются статически собранного софта. Ещё один довод что нафиг динамическую линковку, ибо и PIE и BIND_NOW имеют очень нехилый overhead, как пишут. В 5fca611e0f3c79a2985ba04708ecedf960ed7c03 писал что меня удивляло что на простой FreeBSD всё визуально как будто значительно быстрее стало работать. Возможно связано как-раз вот со всем этим. https://hardenedbsd.org/article/shawn-webb/2021-02-28/hardenedbsd-february-2021-status-report https://cgit.freebsd.org/src/commit/?id=2e1c94aa1fd582fb8ae0522f0827be719ff5fb67 https://www.freebsd.org/news/status/report-2019-07-2019-09/#Kernel-Mapping-Protections пишут что и работа по W^X ведётся и мержится.
From: kmeaw Date: 2021-03-04 17:38:01Z А является ли подмешивание случайный значений в некриптографические функции security by obscurity? Например, рандомизация порядка обхода map в golang, случайные per-process добавки к hash в Python, Ruby и Perl? ASLR заметно усложняет эксплуатацию уязвимости, требуя либо дополнительный address leak, либо пересбора, что делает атаку гораздо более заметной. К сканированию TCP-портов все привыкли, поэтому вряд ли кто-то начнёт готовиться отбивать атаку и вдумчиво читать логи в реальном времени при многократных попытках найти порт SSH. А в случае резкого роста числа SIGSEGV уже стоит начать внимательно следить за своей системой и подменять её на honeypot. Ещё ASLR заставляет программу по-разному использовать память при перезапусках, что увеличивает вероятность случайно обнаружить в своём коде какой-нибудь баг.
From: Sergey Matveev Date: 2021-03-04 19:38:09Z *** kmeaw [2021-03-04 20:29]: >А является ли подмешивание случайный значений в некриптографические >функции security by obscurity? Например, рандомизация порядка обхода map >в golang, случайные per-process добавки к hash в Python, Ruby и Perl? У меня тут нет мнения. Ни тут, ни касательно ASLR. Нет ещё чувства понимания. >ASLR заметно усложняет эксплуатацию уязвимости, требуя либо >дополнительный address leak, либо пересбора, что делает атаку гораздо >более заметной. Видимо поэтому, касательно ALSR, постоянно говорят про то сколько энтропии какая реализация добавляет и как всё плохо с узким адресным пространством i386. >Ещё ASLR заставляет программу по-разному использовать память при >перезапусках, что увеличивает вероятность случайно обнаружить в своём >коде какой-нибудь баг. И потом отлавливать его, пытаясь воспроизвести :-). Но согласен что лучше знать факт наличия бага.