> Вообще, есть три уровня адросации - виртуальные адреса (те, с которыми
> работает приложение), линейные (после примнения десегментации) и
> физические (после примнения страничного механизма к линейному адресу).
> Разделение на типы памяти (стек, код, данные) нужно делать на уровне виртуальных
> адресов, т.к. именно здесь адреса разделяются по назначению. Линейные адреса
> аморфны, в них уже нет информации о том, в каком качестве используется память.
Эта информация всё равно есть у ОС. Вместо того чтобы разделять
линейное пространство на неперекрывающиеся сегменты, можно (было бы
при наличии соотв. аппаратной возможности) просто пометить области,
предназначенные для стека и для данных, как неисполняемые, и получить
практически тот же результат, только не отходя от flat модели.

Тут ключевое слово - "не отходя от flat-модели". В условиях, когда УЖЕ РЕАЛИЗОВАНА flat-модель, сделать защиту на уровне страниц проще, чем вводить сегментацию. А если рассматривать вопрос о том, как нужно бы делать изначально, то на уровне сегментов было бы логичнее.

еще раз про security models в UNIX.

> скоро будет не всчёт, а количество дистрибутивов Linux в которых есть

А с каких пор UNIX = Linux ?

security vs stupid admin

2 adoyl:

> Последнее, вопрос безопасности зависит больше не от системы как таковой, а от того, кто этой системой управляет,

Не согласен. Это одинаково зависит как от модели безопасности, используемой ОС, так и от того, насколько понимает эту модель администратор ( a.k.a. security officer )

> (установка несанкционированного софта или иные действия)

А для того, чтоб запретить подобные действия ( или сделать их последствия нулевыми ) и нужна более гибкая ( чем DAC ) модель безопасности.

> И только в 10% случаев или менее успешность атак возможна благодаря ошибкам (уязвимостям) ОС или приложений.

В идеале, уязвимости _большинства_ приложений вообще не должны влиять на ОС в целом ( если каждый процесс имеет ровно такие права, какие ему необходимы -- не больше и не меньше ).

Русский язык сначала выучи, "вообщем то".

> Добавлю свою ложку дегтя - когда наконец взаимодействия между ПРОЦЕССАМИ будут называть МЕЖПРОЦЕССНЫМИ а не МЕЖПРОЦЕССОРНЫМИ?????

Тогда же, когда и ЦП перестанут называть "ЦПУ".

Одной статьи мало, чтобы обсудить предложенную тему. Тут и книги одной мало будет.

2 Eugene_Korobko >Про проблемы переносимости при переходе к сегментной модели спорить >не буду - я плохо знаю другие архитектуры. Что же касается запрета на >исполнение кода в стеке - модель flat, насколько я её понимаю, >предполагает ПОЛНОЕ совмещение сегментов, а не только баз

Плоная ерунда, сегментная модель это всего лишь способ обойти ограничения на ширину шины адреса. В 32-битных архитектурах использовать сегментную модель вместо flat это полное безумие, до которого только "начитанные ламера" могут додуматся. А с защитой стека никаких проблемм в модели flat нет можно для каждой страницы поставить отдельно режим доступа. Можно для всех страниц памяти которые принадлежат стеку поставить запрет на выполнение, если ОС этого не делает значит есть уже много разного кода который требует исполнения в стеке.

<<Тогда же, когда и ЦП перестанут называть "ЦПУ".>> Вообще-то ЦПУ тоже можно - Центральное Процессорное Устройство (Хотя мне болеепривычно ЦП)

Имхо, тем, кого ещё интересует тема Windows NT (w2k & XP имхо, недалеко ушли) vs Unix следует почитать http://www.linux.org.ru/books/unix-nt.html - вместо писульки этого Криса. Хоть и статья 98-го года, но всё же...

>А с каких пор UNIX = Linux ?

так ты же сам начал орать что в Linux есть, а теперь уже утверждаешь обратное

Что Линукс, что Винды - с каждой версией все медленее работает.

Уже четвертого пня им мало...

>Что Линукс, что Винды - с каждой версией все медленее работает.

RedHat != Linux
Linux != RedHat

ставь нормальный дистр и тогда будет работать всё быстро

Эту статью явно писал человек, даже близко не видевший современной UNIX системы. Мастдайщик, блин seppel

В смысле не seppel -- мастдайщик, а подпись -- seppel seppel

у кого-то напряги с логикой...

2 anonymous (*) (20.10.2003 16:49:34):

>>А с каких пор UNIX = Linux ?

> так ты же сам начал орать что в Linux есть, а теперь уже утверждаешь обратное

Во-первых, есть и в Linux ( спросите у google про RSBAC или SELinux ). Если какой-то дистрибутив не работает с RSBAC'-ed kernel -- это проблема этого дистрибутива, и не более.

Во-вторых, цепочка: XXX нет в Linux ==> XXX нет в UNIX, которую Вы [неявно] используете, ошибочна.

В-третьих, речь шла (если я правильно понял) о моделях безопасности, поддерживаемых _ядром_ ( NT и *NIX), а не о том, какую модель безопасности считает основной N'-ный GNU'-тый дистроклепатель.

>Если какой-то дистрибутив не работает с RSBAC'-ed kernel -- это проблема этого дистрибутива, и не более.

есть в где-то виде каких-то патчей это не значит, что есть,
так как сам настривать это мягко говоря зае******,
а сразу оно по крайней мере только в двух _специализированных_ дистрах (возможно есть ещё какие-то _специализованные_ дистры в которых оно есть)

>XXX нет в Linux ==> XXX нет в UNIX, которую Вы [неявно] используете, ошибочна.

где я её использую?

> Тут ключевое слово - "не отходя от flat-модели". В условиях,
> когда УЖЕ РЕАЛИЗОВАНА flat-модель, сделать защиту на уровне
> страниц проще, чем вводить сегментацию.
Так идея (моя по крайней мере) то как раз в том, что работать с
flat моделью реально проще. По этому если есть возможность её
эффективно использовать, то почему бы и нет?

> А если рассматривать вопрос о том, как нужно бы делать
> изначально, то на уровне сегментов было бы логичнее.
Поскольку в х86 защита на уровне страниц весьма ущербна, в данном
случае возразить нечего. Однако если бы всё нормально было, то
сегментация была бы, имхо, не сильно нужна. Я понимаю конечно,
что все мы к ней ещё со времён ДОСа привыкли, но всё же этот
механизм сильно усложняет работу введением дополнительных конструкций.
Гораздо удобнее работать с непрерывным пространством адресов,
а не сегмент:смещение, хотя бы уже по тому, что данные и код
располагаются в одном физическом адресном пространстве.
Для сравнения: есть такая архитектура mcs51 (однокристалка).
Вот там данные и код (а так же регистры) имеют физически разные
адресные пр-ва. Там я бы согласился с целесообразностью сегментной
модели, однако там всё сделано по-другому (для доступа к разным
адресным пр-вам используются различные команды процессора просто).
А здесь сегментация просто как дополнительный наворот выглядит,
ну и, естественно, компенсирует недостатки страничной защиты иногда.

anonymous:
> В 32-битных архитектурах использовать сегментную
> модель вместо flat это полное безумие, до которого только
> "начитанные ламера" могут додуматся.
Ламера или пользователи х86? Нет нормальной защиты на уровне страниц
здесь, по этому эти подходы иногда приходится комбинировать.

> А с защитой стека никаких проблемм в модели flat нет можно
> для каждой страницы поставить отдельно режим доступа.
На какой архитектуре?

> Можно для всех страниц памяти которые принадлежат стеку
> поставить запрет на выполнение, если ОС
> этого не делает значит есть уже много разного кода который
> требует исполнения в стеке.
Да нельзя этого на х86 сделать! Хочется, а нельзя. По тому как нет
битика соответствующего. Если бы было можно, всего этого спора
не было бы вообще и mprotect() бы работал:)

> В смысле не seppel -- мастдайщик, а подпись -- seppel seppel

seppel - это убогий кретин, не могущий разобраться с постингом сообщений даже.

Этот автор подельник широко известного клоуна Арви хЭкера и этим о нем все сказано :)

Мда, интересно:

> количество дыр, обнаруженных в NT за все время ее
> существования, можно свободно пересчитать по пальцам
> одной руки (причем, большая часть из них была обнаружена
> практически случайно). В UNIX же, напротив, дыры
> обнаруживаются постоянно.

> ...К тому же медленное, эволюционное (а не революционное
> как у NT) развитие UNIX отнюдь не способствует появлению
> грубых, легко обнаруживаемых ошибок, которыми так славится NT.

Это только мне кажется, что тут маа-ааленькое противоречие?

Интересно, вроде выступило много умных людей и сколько их еще есть у нас, а свой хоть какой-нибудь ОС нет. Почему?

Даешь свою ОС! (Например как чудо автомобилестроения - запорожец)

Для anonymous (*) (21.10.2003 9:27:39)

Если в этой фразе нет противоречия, то это означает, что у автора статьи не пять пальцев на руке...

Ну что ж, и это возможно... Может быть, у него еще и половины головы нет. Ну, бывают же такие несчастья с людьми.

еще про логику...

2 anonymous (*) (20.10.2003 18:58:07):

> >XXX нет в Linux ==> XXX нет в UNIX, которую Вы [неявно] используете, ошибочна.

>где я её использую?

Идет обсуждение моделей безопасности, реализованных в UNIX и NT. Вы начинаете говорить о том, что дистрибутивов Linux с RSBAC|SELinux|grsec|OpenWall|... мало.

> есть в где-то виде каких-то патчей это не значит, что есть, так как сам настривать это мягко говоря зае******

Да все равно это надо руками настраивать -- разумные значения по умолчанию вряд ли возможны. ( Собственно, хотели fine grained security -- ее и получили ). Точно так же в NT нужно настраивать политики безопасности -- с тем, что там по умолчанию, страшно не то что в сеть выходить, но и питание включать :)

штатный клоун конференции RU.HACKER в 97м ? как же.. помним, чтим ;)) а еще мне помнится один из последних его "научных трудов", в одном из номеров покойного ныне журнала "Программист", где он расписывал как можно достичь увеличения скорости копирования данных из памяти в пямять конструкцией типа

while (что-то там)
*(p_target_buff++) = *(p_source_buff++);

кстати, он заявлял, что во всех библиотеках функция strcpy() реализована примерно так... ну так вот, вся соль метода состояла в том, что при копировании предлагалось учитывать расположение блоков данных относительно физических банков памяти (!!!), причём даже как-то и не рассматривались такие глупые и несущественные моменты как: невозможность получения подобной информации в принципе, даже при её наличии полная её бесполезность в связи с виртуализацией памяти в современных ОС и необходимость замены пары строковых процессорных инструкций целой функцией с десятком арифметических инструкций и т.д.
Вобщем... парню явно стоило пойти в цирковое училище ;)

Господа, неужели вы не видите реального смысла этой статьи? Он ведь явно выражен в следующих словах, когда автор подводит итоги:

"... но ломают чаще всего все-таки UNIX, а не NT. Парадокс? Или все-таки отсутствие исходных текстов дает о себе знать? Во всяком случае, других причин мы просто не видим..."

Что тут еще объяснять. Все предельно ясно. Интересно, с какой стороны ОНИ еще зайдут...

>Идет обсуждение моделей безопасности, реализованных в UNIX и NT.

а я думал мы обсуждаем многоуровневую и одноуровневую систему привелегий в NT и UNIX


>Вы начинаете говорить о том, что дистрибутивов Linux с RSBAC|SELinux|grsec|OpenWall|... мало.

а каким боком grsec и OpenWall сюда относятся?
не то что мало - практически нет.

и вообще изначальная фраза автора статьи была "применяемая в большинстве UNIX, является одноуровневой" , согласись, что это верно?

>Точно так же в NT нужно настраивать политики безопасности -- с тем, что там по умолчанию, страшно не то что в сеть выходить, но и питание включать :)

по крайней мере тут уже есть работающая система и не надо еб***** с прикручиванием патчей и приблудных утилит

про grsec и "приблудные" утилиты...

2 anonymous (*) (21.10.2003 23:34:51):

> а каким боком grsec и OpenWall сюда относятся?

grsec -- это не одноуровневая система привилегий (хотя все равно примитивная)

>>Точно так же в NT нужно настраивать политики безопасности -- с тем, что там по умолчанию, страшно не то что в сеть выходить, но и питание включать :)

> по крайней мере тут уже есть работающая система и не надо еб***** с прикручиванием патчей и приблудных утилит

1) Что-то мне не приходилось е****** с прикручиванием RBAC к Solaris

2) Собственно корректная настройка любой role-based системы безопасности _гораздо_ сложнее "прикручивания" патча

В AMD64 добавили такой бит в page table - NX (NoExecute). А API Windows NT изначально поддерживал эту возможность, но не x86 архитектура. Microsoft-овцев специально об этом спросили, и они ответили, что Windows поддерживает этот бит на всех платформах, где его поддерживает аппаратура.

>Если развести данные, код и стек по разным сегментам, то им можно установить разные флаги доступа. Код - только исполнение и чтение, данные и стек - только чтение и запись (не исполнение), и следить за этим будет процессор (аппаратно).

Так и делают - но на уровне страниц. А за ненулевую базу сегмента процессоры x86 давно получают такой пенальти, что мало не покажется. И только повсеместное использование flat модели делает это малозаметным. AMD64 вообще требует нулевую базу в native 64-битном режиме - точнее не требует, а игнорирует при расчете :)

>Линейные адреса аморфны, в них уже нет информации о том, в каком качестве используется память

Вот только именно по ним лежат байты - а каждый байт изначально принадлежал коду или данным - противоречие :) ?

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