Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Вы внимательно читаете? Моя злоба направлена как раз... 06.12.05 12:20 Число просмотров: 3204
Автор: amirul <Serge> Статус: The Elderman
|
> А не получится, что в результате доступ записи на диск не
> будут иметь приложения, которым это и не надо (в которых и
> не предусмотрена никакая запись), а будут иметь доступ те,
> которые в принципе могут что-то захотеть записать. Возможно
При правильном использовании такого быть не должно. А вообще мне не особо понравилась идея ПОЛНОГО отказа от виндовых DACL. Как по мне, такая система защиты должна уметь только СУЖАТЬ права, а не расширять их. Таким образом, если пользователю стандартными средствами запрещена запись в определенный каталог, то дополнительный слой защиты может к примеру запретить еще и чтение, но уж никак не разрешать запись.
> никто и не будет переполнять буфер у приложений, которые с
> диском не работают по жизни, а все атаки будут и так
> направлены на те, что пишут что-то на диск, а у них по
> вашему останутся права доступа.
> Есть тут у меня пару идей. Для коллекционеров патентов
> предложу запатентовать их.
> Первый: Пользователя SYSTEM должно быть два. Добавим еще
> SERVICE, у которого не будет прав доступа на запись. В
Выполняя предельный переход получим, что каждому процессу нужно по пользователю и при правильной настройке прав это будет идеальным вариантом. Опять таки воспользовавшись бритвой Оккама отбросим ненужную мишуру (собственно, самого пользователя) и получим, что с каждым процессом можно напрямую сопоставить отдельный дескриптор защиты, минуя всякие лишние звенья.
> реестре сервисов предусмотреть/добавить поле пользователя,
> от имени которого запускается сервис. Останется только
> скорректировать пользователя, под чьими правами будет
> выполняться этот сервис в зависимости от предназначения
> этого сервиса.
Сервисы можно запускать от имени любого зарегестрированного пользователя уже сейчас.
> Второй: Разделить сегменты задачи на три - сегмент кода,
> сегмент констант, сегмент данных. Сегмент кода защищен от
> модификации и анализа кода в процессе работы программы как
> чужим процессом, так и своим. Константы защищены от
> модификации и выполнения. Данные защищены от выполнения.
> Буфера размещаются в сегменте данных. Получается что память
> либо нельзя модифицировать, либо нельзя выполнить код из
> этого сегмента памяти. В данном случае выполнение
> непредусмотренного кода в следствие переполнения буфера
> данных исключено. Аппаратно современные процессоры это
> поддерживают.
Сегментную организации ОСеписатели очень не любят хотя бы потому, что я не могу припомнить ни одного процессора, кроме IA, поддерживающего ее. Наряду с требованием переносимости использование сегментов становится невозможным. И наоборот, во всех архитектурах (из известных мне), кроме IA, защита от исполнения возложена на страницы (хотя последние AMD вроде тоже научились это делать).
Кстати, существует очень хитрый хак для IA (реализация называется то ли pex то ли как то еще), связанный с тем, что TLB-кеши для данных и для кода разные. ВСЕ страницы помечаются как non-present, по page fault-у происходит анализ, что же собственно происходит со страницей fetch или обчный read/write. Если fetch, то странице дается read-only (который заносится в instruction TLB), после чего PTE для этой страницы быстро восстанавливается в non-present состояние. Аналогично с данными. Это приводит к тому, что в iTLB лежат readonly исполнимые страницы, а в кеше данных - rw страницы данных, а PDE/PTE в памяти все как одна помечены как инвалидные. Процессор сам смотрит fetch это или rw и обращается за информацией о странице к тому или иному кешу. Очень хитрый и элегантный, но весьма грязный хак :-)
Кстати, любители патентовать, "чтобы не украли" приглашаются к патентованию этой прогрессивной технологии.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
