Уже на протяжении трех статей этого цикла мы с вами обсуждаем интересную и относительно новую технологию, которая называется «Динамический контроль доступа» и
from Pocket http://ift.tt/1c13Qvw
via IFTTT
суббота, 16 августа 2014 г.
Динамический контроль доступа: списки свойств ресурсов и классификация файлов tutorial
Уже на протяжении трех статей этого цикла мы с вами обсуждаем интересную и относительно новую технологию, которая называется «Динамический контроль доступа» и
from Pocket http://ift.tt/1c13Qvw
via IFTTT
Динамический контроль доступа: что собой представляют ресурсы tutorial
Ты должен увидеть это сам. Не поздно отказаться. Потом пути назад не будет.Примешь синюю таблетку — и сказке конец.
from Pocket http://ift.tt/17Mf5Kj
via IFTTT
Полное отключение синхронизации времени между виртуальной машиной и гипервизором VMware ESXi
Небольшая, но довольно полезная статья. Надеюсь поможет кому-нибудь избежать проблем в будущем.
from Pocket http://ift.tt/1nWaRU5
via IFTTT
пятница, 15 августа 2014 г.
Идентификация исходников как модуля ядра Linux
Идентификация исходников как модуля ядра Linux
В этом посте я расскажу о том, как можно определить, что из некоторых файлов исходных текстов собирается модуль ядра Linux, а не обычный исполняемый файл.Допустим, что информации о назначении исходников нет или её пытаются преднамеренно скрыть. Объём кода превышает несколько Гб и надо оперативно выделить только те исходные тексты, которые реализуют модули ядра.
#01 __KERNEL__
При сборке исходных текстов определён символ препроцессора __KERNEL__.
Как пишут Alessandro Rubini и Jonathan Corbet в книге "Драйверы устройств в Linux":
"Поскольку модуль не связывается ни с одной из стандартных библиотек, исходные тексты модуля не должны подключать обычные заголовочные файлы. В модулях ядра могут использоваться только те функции, которые экспортируются ядром. Все заголовочные файлы, которые относятся к ядру, расположены в каталогах include/linux и include/asm, внутри дерева каталогов с исходными текстами ядра (как правило это каталог/usr/src/linux).Например, в makefile может присутствовать строчка "CFLAGS = -D__KERNEL__".
Ранние версии Linux (основанные на libc версии 5 и более ранних) устанавливали символические ссылки из /usr/include/linux и /usr/include/asm на фактические каталоги из исходных текстов ядра, таким образом дерево заголовочных файлов libc могло ссылаться на заголовочные файлы ядра. Это позволяло подключать заголовочные файлы ядра в пользовательские приложения тогда, когда в этом возникала необходимость.
Но даже теперь, когда заголовочные файлы ядра отделены от заголовочных файлов, используемых прикладными программами, все равно иногда возникает необходимость включения их в программы, работающие в пространстве пользователя, чтобы воспользоваться определениями, отсутствующими в обычных заголовочных файлах. Однако большая часть определений из заголовочных файлов ядра относится исключительно к ядру и "невидима" для обычных приложений, поскольку доступ к этим определениям заключен в блоки #ifdef __KERNEL__. Это кстати одна из причин, почему необходимо определять символ __KERNEL__ при сборке модуля."
Или "-D__KERNEL__" можно обнаружить в логах сборки .
#02 MODULE
Если модуль не линкуется к ядру статически, то в составе переменной CFLAGS обязательно будет присутствовать строка "-DMODULE". Этот символ препроцессора должен быть определён должен быть определен до подключения файла linux/module.h.#03 Все имена объявлены как static и имеют уникальный префикс
Таким образом разработчик избегает "загрязнения" пространства имён ядра - иначе при отладке ему пришлось бы отлавливать имена своего модуля среди всех имён ядра. Использование префикса освобождает от обязанности придумывать уникальные имена, которые не будут совпадать с именами, уже присутствующими в пространстве имён ядра.#04 printk()
В исходных текстах вместо функции printf() используется функция printk(). "Драйверы устройств в Linux" говорит:"Функция printk определена в ядре и по своему поведению напоминает функцию printf из стандартной библиотеки языка C. Зачем же тогда ядру своя собственная функция? Все просто -- ядро, это самостоятельный код, который собирается без вспомогательных библиотек языка C."
#05 init_module и cleanup_module
"Драйверы устройств в Linux" говорит:
"Приложение выполняется как цельная задача, от начала и до конца. Модуль же просто регистрирует себя самого в ядре, подготавливая его для обслуживания возможных запросов и его функция "main" завершает свою работу сразу же после вызова. Другими словами, задача функции init_module (точка входа) состоит в подготовке функций модуля для последующих вызовов. Она как бы говорит ядру: "Эй! Я здесь! Вот то, что я могу делать!". Вторая точка входа в модуль - cleanup_module - вызывается непосредственно перед выгрузкой модуля. Она сообщает ядру: "Я ухожу! Больше не проси меня ни о чем!". "
#06 Использование current->
"Драйверы устройств в Linux" говорит:
"<...> Код ядра может определить текущий процесс, обратившийся к модулю, через глобальный элемент current - указатель на struct task_struct, который в ядре 2.4 объявляется в файле <asm/current.h>. Указатель current ссылается на текущий пользовательский процесс. В процессе выполнения системных вызовов, таких как read или write, текущим считается процесс, сделавший этот вызов. Ядро может воспользоваться информацией о текущем процессе, используя указатель current, если возникнет такая необходимость. <...>
Фактически current более не является глобальной переменной ядра, как это было ранее. Разработчики оптимизировали доступ к структуре, описывающей текущий процесс, перенеся ее на стек. Реализацию current вы найдете в файле <asm/current.h>. Но прежде, чем вы отправитесь исследовать этот файл, вы должны запомнить, что Linux -- это SMP-совместимая система (от англ. SMP -- Symmetric Multi-Processing) и потому простая глобальная переменная здесь просто неприменима. Детали реализации находятся в других подсистемах ядра и все же, драйвер устройства может подключить заголовочный файл <linux/sched.h> и обращаться к указателю current.
С точки зрения модуля, current -- обычная внешняя ссылка, как например printk. Модуль может обращаться к current всякий раз, когда сочтет это необходимым. Например, следующий код выведет идентификатор (ID) процесса и имя команды, запустившей процесс:
printk("The process is \"%s\" (pid %i)\n", current->comm, current->pid);
Имя команды хранится в поле current->comm и представляет собой имя файла программы.
Если вам известны ещё какие-либо способы определить исходные тексты модуля ядра - добро пожаловать в комментарии.
среда, 13 августа 2014 г.
Давайте, наконец, задумаемся о том, что мы подразумеваем, когда говорим «активы» и «три защищаемых свойства информации»
О том, о чём все и так знают Почему-то очень многие люди говорят, что защищают три свойства информации (да, те самые: конфиденциальность, целостность, доступность).
from Pocket http://ift.tt/ViIusw
via IFTTT
суббота, 9 августа 2014 г.
Проверка PVS-Studio с помощью Clang
Да, да. Вы не ослышались. В этот раз статья «наоборот». Не мы проверяем какой-то проект, а проверили наш анализатор с помощью другого инструмента.
from Pocket http://ift.tt/1skN5IS
via IFTTT
Русские технологии: «Чем охраняется Лувр и ЦБ» — системы безопасности Павла Скирневского
Первый выпуск проекта «Русские технологии» с Денисом Климовым. Герой программы — учёный, изобретатель и успешный бизнесмен Павел Скирневский.
from Pocket http://ift.tt/1kwOJ7S
via IFTTT
Что не нужно кодить самостоятельно
Недавно написал свой велосипед и выложил его на хабре. Вот он: «Простейший Connection pool без DataSource в Java». Статья не из самых удачных, только прошу больше не минусовать.
from Pocket http://ift.tt/1rGFVMh
via IFTTT
воскресенье, 3 августа 2014 г.
Какой HDD надёжнее? Статистика Backblaze по 27134 накопителям за 4 года работы
Компания Backblaze опубликовала в своём блоге статистику использования дисковых накопителей в своих серверах. Backblaze предоставляет услугу дешёвого облачного бэкапа.
from Pocket http://ift.tt/1juz5Fp
via IFTTT
суббота, 2 августа 2014 г.
Альтернативные методы трассировки приложений
Трассировка используется во многих видах ПО: в эмуляторах, динамических распаковщиках, фаззерах.
from Pocket http://ift.tt/1uNz8oR
via IFTTT
четверг, 17 июля 2014 г.
Проверка безопасности скриптов на Ruby
Проверка безопасности скриптов на Ruby
В ходе аудита кода [очень]большого проекта обнаружилось, что существующие и применяемые инструменты\методики не охватывают скриптов на языке Ruby. Он, конечно, "широко известен в узких кругах", но в составе общесистемного ПО пока представлен (пока) не слишком широко.
Во избежание непредвиденных неприятностей в будущем озаботился поиском как минимум статических анализаторов программ на языке Ruby.
Ответы по теме на Stackoverflow:
https://stackoverflow.com/questions/286564/ruby-source-code-analyzer-something-like-pylintThe Ruby Toolbox:
Brakeman: https://www.ruby-toolbox.com/categories/security_toolsBrakeman detects security vulnerabilities in Ruby on Rails applications via static analysis.
Find mass assignment:
Find likely mass assignment vulnerabilities
Ruby Tools Roundup
Simplabs. Exlellent
Статья Грега Брокмана (Greg Brockman)
YorickPeterse/ruby-lint
среда, 5 марта 2014 г.
Выявлен руткит, существовавший 3 года необнаруженным.
Старейшая из детектированных версия руткита Uroburos была написана в 2011 г., и это значит, что он работал не замеченным как минимум три года.
В коде руткита обнаружены кириллические символы, подтолкнувшие экспертов к мнению о российском (постсоветском) авторстве вредоноса.
На основе последовательности символов Ur0bUr()sGotyOu#, найденных в коде руткита, программа получила от первооткрывателей название Uroburos (герметический символ в виде змея, пожирающего собственный хвост).
Срок жизни вредоноса в необнаруженном состоянии вызывает уважение к квалификации его авторов, несмотря на сомнительный с моральной точки зрения способ монетизации их мастерства.
Подробнее:
Подписаться на:
Комментарии (Atom)