[Часть первая ;)]
[...]
> это уже не по теме форума, тем не менее.
> умение проводить аналогии - полезно. но использовать в качестве
> доказательства - моветон.
Моветон, говоришь? ;)
ты> [...] и мало кто может оценить качество софта/услуги. посему введено ты> обязательное лицензирование деятельности по проектированию и
ты> производству криптосредств [...] по аналогии с магазином: и продавец
ты> должен иметь сан. книжку, и колбаса - сертификат СЭС.
еще ты> hint: сертифицированный замок можно поставить на картонную
еще ты> дверь. и ругать разработчиков замка.
и еще> [...] это был не SecretNet, другое изделие, н осути не меняет... ;)
опять ты, аналогия с личным жизненным опытом> знаешь, сколько мне
опять ты> приходилось возить фейзом по клавиатуре разработчиков
опять ты> доморощенных защит системы "рулез немерянный,
опять ты> самособранный"?
Это только очевидные, употребленныетобойв сходных обстоятельствах, аналогии (далеко не все, надо полагать). Надеюсь, ты таки найдешь в себе силы одолеть учебник философии (гносеологии) и мне не придется углубляться в оффтопичный ликбез ;-\
>> >> ... сильно смахивающая на аффилированную структуру
>> >> органам же запрещено напрямую торговать ...
>> > не угадал ;)
>> Я и не гадал.
> т.е. ты обвиняешь контору в аффилированности.
"сильно смахивающая" это не обвинение. Это мнение пообьективнотруднодоказумому вопросу.
> это надо делать аргументировано, или не делать вообще, в противном
> случае,
Я свои аргументы привел. При этом отнюдь не пытался выдать свои выводы за истину в последней инстанции (подтвержденные факты).
> это смахивает на клевету.
Так что, как говорится, мимо тазика.
[...]
>> опровержения изначального тезиса (о том, что "Р" -- "это
>> хорошие/очень хорошие/лучшие [...] специалисты в области
>> безопасности") достаточно сертифицированности SN и
>> использования ее в серьезных (вроде как) проектах типа
>> "Выборов".
> давайте, мух и котлеты отдельно?
> уровень квалификации "Р" ну никак не связан с характеристиками SN и
> уровнем ее разработчиков.
На мой взгляд связаны: незаметно, чтобы "Р" каким-либо образом противодействовало сертификации и впариванию сей очевиднейшей туфты (втч государственным организациям, втч для значимых проектов типа ГАС "Выборы") / способствовало направлению ее разработчиков на путь истинный. Т.е. они, очевидно, не видят вопиющих плюх, дилетантского дизайна -> их собственный уровень невысок.
>> Ну невозможно же поверить в то, что они а) не в курсе б) в
>> белых фраках, хотя коллеги из других госструктур того же
>> уровня по уши в дерьме ...
> м-да. весна ;)
Ты с чем-то не согласен или просто не понял?
>> >> 1. Из песни слова не выкинешь -- были пальцы
>> насчет ГАС
>> >> "Выборы", были (и есть) всевозможные сертификаты
>> > у кого? ;)
>> У НИП "ИНФОРМЗАЩИТА". На SN. От Гостехкомиссии, МинОбороны
> медленно и печально идем изучать систему сертификации.
Медленно и печально обьясняем, причем тут система сертификации.
> hint: сертифицированный замок можно поставить на картонную дверь. и
> ругать разработчиков замка.
Разве я где-то выводил слабость SN из подобных случаев?
>> И в чем же ты видишь принципиальные изменения (кроме
>> ролевой модели, базирующейся, судя по описанию, на все той
>> же импотентной схеме ~восьмилетней давности) ?
> если ты путаешь дискретную и мандатную системы, то объяснить
> сложно...
Я не путаю (с чего ты взял?). Мандатную систему я здесь вообще [еще] не рассматривал -- она, IMNSHO, нужна лишь узкому кругу клиентов, особенно в том виде, в каком она присутствует в SN.
>> Впрочем, думается, теоретически это вполне можно проделать
>> прямо в форуме.
> Ну так ты бы и обрисовал для начала "в общих чертах", как ты себе
> представляешь защиту этого дела на самописных скриптах и примочках.
Я и не предлагалэтозащищатьисключительно"на [...] скриптах и примочках".
Вотмойтезис:
> Для тех времен: filelock от Е.Музыченко, dprot (не помню уже чей).
> Для нынешних: BestCrypt, RSBAC, tripware (ну и встроенные средства).
>
> Да, разумеется, это только основные подсистемы -- остальное при
> необходимости
> довешивается в ходе настройки на конкретном обьекте, благо что при
> правильном дизайне многие из фич этого монстра обеспечиваются
> скриптами / утилитками на несколько десятков строк.
В filelock и т.п. ACL-схемах пользователь также не имеет прав на доступ к данным, ему позволено только запускать интерфейсную программу (ну и прочий нужный ему софт из установленного на машине). Интерфейсная же программа обьявляется "привилегированной" (исполняющейся с правами, отличными от прав запускающего ее пользователя), с предоставлением ей доступа к файлам БД:
---- filelock.doc ----
Раздел привилегированных программ
Описание каждой программы в разделе начинается с ключевого
слова %Program:
[...]
На следующих строках могут перечисляться полномочия прог-
рамм по отношению к другим файлам/каталогам, логическим/физи-
ческим секторам, аналогично правилам общего раздела.
[...]
Раздел пользователей
Описание каждого пользователя в разделе начинается с клю-
чевого слова %User:
%User <Имя> 00000000
[...]
Вслед за строкой %User перечисляются полномочия пользова-
теля, как в предыдующих разделах.
[...]
S - поиск файлов, запрос атрибутов
E - исполнение программ
R - чтение файлов
W - запись файлов
C - создание файлов/каталогов
D - удалением файлов/каталогов
---- Пример: ----
%User operator 00000000
c:tools se
d:db s ; optional?
d:db\db_iface.exe e
...
%Program d:db\db_iface.exe
d:db scdrw
---- cut ----
В NT встроены сходные возможности (начиная с Win2K -- поддержка на уровне GUI).
В *nix-схеме такое делается через set[ug]id враппер к интерфейсной программе (если она сама не поддерживает переключения), права на собственно данные даются только соответствующему псевдопользователю.
> Я ведь не знаю, какая степень подробности тебе нужна...
Не проблема -- уточним в процессе. Я же тоже не знаю, с какой степенью подробности описывать тебе задачу ...
>> Итак, имеется БД и интерфейсная программа к ней. Доступ к
>> БД должен осуществляться исключительно через эту программу,
>> которая производит необходимые специфичные проверки
>> вводимой информации, оперируя закрытыми для оператора
>> данными, [отчасти] хранимыми локально (в той же БД).
> Разработчик этой байды - имбецил?
1. Да хоть бы и да. Для "давно используемого виндозный софта" это скорее правило, чем исключение ;(
2. Ну зачем же так грубо о SN-щиках? ;) Я, разумеется, не их имел в виду, но в SN тоже есть БД с такими характеристиками ...
>> Работа с БД -- не единственная обязанность пользователя.
>> Для обеспечения других выполняемых им задач на машине стоит
>> масса других программ, включая архиваторы, редакторы, шелл
>> ("интерпретатор команд", если угодно). Кроме того, по роду
>> деятельности, этому пользователю необходимо обмениваться
>> данными с внешним миром. Т.е внешние (отчуждаемые) носители
>> доступны как на чтение, так и на запись. С точки зрения
>> исполняемого кода среда замкнутая.
>>
>> С тебя описание (в общих чертах) конфигурирования SN.
> Какие проблемы?
> Завести юзеров с разными правами. "Базнику" дать доступ к базе только
> через приложение, не давать доступа к левым ресурсам/тулзам.
> Остальным - дать доступ к нужным ресурсам, не давать доступ к
> базе/приложению.
_КАК_ в SN "дать доступ к базетолько_через_ приложение"? Цитату из документации и пример, please (Господи, неужели сейчас хотя бы по одному пункту ты скажешь что-то конкретное?;)
На всякий случай: реальных пользователей там только два -- оператор и администратор, и ограничивать последнего запуском только одного приложения в каждый момент времени неприемлимо: та интерфейсная БД-программа и прочие запускаемые им софтины (из числа разрешенных, разумеется) должны иметь возможность работать параллельно.
> Хотя, если эта базанастольковажна, я бы ее вынес на отдельный комп
> и закрыл тем же "Соболем".
Это не всегда возможно / оптимально. Втч по соображениям важности информации в БД.
> Собственно, защиту чего угодно начинают с планирования, т.е.
> составляют план доступа к ресурсам, а потом смотрят, чем реализовать.
Угу.
> Ты не сделал первого шага,
BTW, мое изложение покрывает намного больше аспектов, чем твоя аналогичная попытка ниже (в вопросе о стойкости программной защиты).
> а предлагаешь мне набросать реализацию?
Нет. Я тебе предлагаю всего лишь изложить идею таковой через функциональность SN. Выше приведен пример для filelock (можно я обойдусь без примера и цитат из документации для *nix и NT? Спасибо;)
> Так для этого ты не дал исходных данных ;)
Тебе что-то непонятно? Я разжую, не впервой ... ;-\
> Не говоря уже о том, что это и есть та часть работы, которая требует
> квалификации безопасника - дальнейшую реализацию может сделать
> любой технарь. И она, как правило, дороже остальных ;)
Мне не нужна реализация. Она у меня есть, причем для куда более сложных случаев реальной жизни. Здесь приведен рафинированный, максимально упрощенный пример, призванный показать потенции обсуждаемого продукта в одном из аспектов. В том же ключе ожидается твой ответ.
>> > платы я в свое время снимал "защиту от изъятия
>> аппаратной части" за 7
>> > минут ;) это был не SecretNet, другое изделие, н осути
>> не меняет... ;)
>>
>> Еще одно доказательство ламерства SN-щиков ...
> да ну? ну-ка, г-не "не-ламер", порази концептуальной идеей, как сделать
> защиту от изъятия, которую не обойдешь? ась?
Защиты, "которую не обойдешь" не существует. Но сделать программную защиту прочнее, чем на "7 минут" вполне можно.
Например, прозрачным [де]шифрованием раздела целиком, начиная c MBR (пролонгированного). После загрузки ядра ОС оно, естественно, "подхватывает" эту функциональность.
На уровне приложений -- шитый код (некоторые разновидности прям как специально созданы для этих целей) с использованием данных, хранимых на том, что изьято, ну и с перекрестными проверками на целостность, само собой. Можно и пошифровать код (помодульно, с расшифровкой, естественно, только по обращению, ключ брать все оттуда же).
> вот и не надо извращать тезис.
Взаимно -- я разве где-то претендовал на знание "как сделать защиту [...], которую не обойдешь"?
> чисто программная защита обьходится по определению...
Любая защита теоретически обходится. Вопрос только в том, стоит ли защищаемый обьект требуемых усилий. "7 минут" это, в твоей терминологии, "курятник, который никому не нужен как Неуловимый Джо". Можно спорить, нужна ли программная защита от изьятия как таковая, но "7 минут" это столь низкий уровень защиты, что кроме как для "курятников" его можно считать несуществующим вовсе. Заявлять о наличии таковой -- либо обман (довольно таки бессмысленный в такого рода вещах), либо добросовестное заблуждение, равно недопустимое для специалиста.
>> > м-да. rsbac на винде - мсье знает толк в половых
>> извращениях ;))
>>
>> Отчего же "извращениях"-то (особенно сравнивая с SN)?
> оттого, что Rsbac - RULE SET BASED ACCESS CONTROL, разработанная
> исключительно под линукс.
Под "разработанная исключительно под линукс" надо понимать "дизайн базируется на специфике линукс" или что-то иное?
> что-то я не слышал про ее портирование на винду.
Из этого, что, следует извращенность? ;)
>> > а dprot - даже не замочек от честных людей, а
>> шпингалет. даже на то
>> > время...
>>
>> Возможно, я его с чем-то попутал ... времени-то сколько
>> прошло ... Ленты ворошить лень ...
>> Разумеется, в сколь-нибудь серьезных задачах я такого рода
>> (шифрование "на лету") утиль не использовал. Просто ничего
>> бОльшего SN не представляет -> аналогии проводить не с
>> чем.
> мсье, вы бредите. "такого рода утиль" - dprot? и там было шифрование на
> лету?
Это Вы бредите -- да, dprot (втч) осуществляет прозрачное ("на лету") шифрование. Так что, оказывается, это не я попутал ...
> а после заявления, что СН предоставляет только это, я не поверю, что
> документация прочитана хотя бы по диагонали...
Контекст намерено игнорируем?
SN предоставляет что-нибудь кроме "шифрования данных на диске" для прозрачной работы с даннми, которым в некриптованном виде дозволено находиться лишь в ОЗУ?
>> > какие, в %опу, скрипты на винде?! мы ничего не путаем?
>>
>> На этот раз нет. Скрипты на "родном" cmd, 4nt, tcl, perl.
>> Портированное по принципу минимальных затрат -- на bash.
>> Разумеется, не все так элегантно, шустро и ловко, как в
>> родной среде, но для данных целей в большинстве случаев
>> вполне приемлимо.
> "скрипты на cmd" - единственная родная вещь. хотя, не разгонишься там
> сильно. все остальное - привнесенное, со всеми вытекающими
> (разработчик интерпретатора накосячил, плюс разработчик скрипта, да
> все это вместе никто не проверял независимо...).
Во-первых, почему же "никто не проверял независимо", а во-вторых, использование тех или иных привнесенных(*) приложений (модулей) / собственноручно сделанных настроек (не суть важно каким способом -- главное, чтобы адекватным) само по себе не плохо и не хорошо -- зависит от того, _что за приложения (модули) / настройки_,ктоикаких применил. Они вполне могут и улучшить исходную среду, исправить "косяки" от производителя ОС / прикладных программ, для чего, собственно, вся эта открытость (модульность) и предназначена ...
(*) jfyi: виндовсы содержат преизрядное количество кода, заимствованного у не-MS-овских разработчиков.
>> > не, можно, конечно и зайца научить курить, но зачем?
>>
>> Ровно затем же, зачем и весь этот виндовс вообще. См. ниже
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> вы не любите виндовс? ;) а может, просто не умеете готовить? ;)
Судя по Вашей реакции на вопрос о применении скриптов, это _у Вас_ проблемы с его использованием на уровне выше минимиального ;-\
Впрочем, она и с униховой стороны Вас характеризует не лучшим образом:
>> я - не против. только вот разработчики не торопятся. посему
>> приходится, матерясь сквозь зубы, пытаться делать из винды юникс.
Так "юникс" (пусть и сделанный "из винды") Вам представляется без скриптов?
Без привнесенных программ? Ну кроме SN, для которого Вы почему-то сделали исключение, хотя к *nix он имеет примерно такое же отношение, как и, например, DOS ;)
На что ж он в таком случае годен-то будет (если исключать привнесенное на том же уровне -- MS вон доказывает, что это чуть ли не невозможно)?
> мы ведь о ситуации, когда нет возможности пользоваться юникс, и надо
> защитить задачу на винде.
Здесь -- да. А я в подчеркнутом разве возражал? Разве "надо защитить задачу на винде" каким-то образом противоречит использованию скриптов для этой цели?
>> твой же собственный пассаж про "давно используемый
>> виндозный софт". Если уж взялись его поддерживать, и не
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
