Статья, очевидно, относится к ядерному программированию. Рассмотрен метод динамической модификации, когда не возможности (желания, необходимости) править исходники ядра. Про strace я что-то не совсем понял.
SELinux всегда ограничивал рута и нет в этом ничего плохого :) Другое дело на сколько такая защита всё-таки эффективна, ведь в конечном счёте переполнению буфера в ядре не важно под кем оно происходит…
/dev/mem давно уже ограничен и нельзя просто так взять и записать в произвольный адрес памяти:
314 /*
315 * devmem_is_allowed() checks to see if /dev/mem access to a certain address
316 * is valid. The argument is a physical page number.
317 *
318 *
319 * On x86, access has to be given to the first megabyte of ram because that area
320 * contains bios code and data regions used by X and dosemu and similar apps.
321 * Access has to be given to non-kernel-ram areas as well, these contain the PCI
322 * mmio resources as well as potential bios/acpi data regions.
323 */
Что касается требований к проектированию, то мне представляется, что при создании коммерческих продуктов вендорами мирового класса, также используются все необходимые технологии. И даже более, ведь для них реальная безопасность чуть-чуточку важнее, чем «условная», прикрытая, как правило, сертификатом того же ФСТЭК. Таким образом, уж если у крупнейших вендоров есть эксплуатируемые ошибки в ПО, то грезить тем, что таких ошибок возможно избежать при разработке наложенных средств защиты «с учетом требований к высокой степени защиты» и разрабатываемых по «методологиям защищенного программирования» — неразумно.
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Что касается требований к проектированию, то мне представляется, что при создании коммерческих продуктов вендорами мирового класса, также используются все необходимые технологии. И даже более, ведь для них реальная безопасность чуть-чуточку важнее, чем «условная», прикрытая, как правило, сертификатом того же ФСТЭК. Таким образом, уж если у крупнейших вендоров есть эксплуатируемые ошибки в ПО, то грезить тем, что таких ошибок возможно избежать при разработке наложенных средств защиты «с учетом требований к высокой степени защиты» и разрабатываемых по «методологиям защищенного программирования».
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Если есть исходники, то делаем вообще что угодно. А что касается того, что лучше подменять отдельные хуки, то предложенный способ позволяет это делать без каких-либо ограничений: смотрите внимательней приведённый в качестве примера код.
straceя что-то не совсем понял./dev/memдавно уже ограничен и нельзя просто так взять и записать в произвольный адрес памяти:CONFIG_MODULESи живите спокойно :)Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?
Что касается эшелонирования и прочих верных мер, то тут стоит ответить на такой вопрос. Если аппаратная реализация поддержки виртуализации реализована в железе, то где гарантия того, что данное «железо» не имеет внутри себя «потайных» ходов, которые позволят любому исполняющемуся на процессоре коду с любыми привилегиями выполнить «секретную' последовательность команд и эксалироваться до уровня того же гипервизора?