Доброго времени суток, уважаемые.
Случился у нас с г-ном Andrew.W Worobow скромный спор о проблемах сабжа...
Суть "конфликта" — я по незнанию считаю, что для того чтобы удовлетворять условиям некоторого ТЗ
Здравствуйте, Ligen, Вы писали:
L>Доброго времени суток, уважаемые. L>Случился у нас с г-ном Andrew.W Worobow скромный спор о проблемах сабжа... L>Суть "конфликта" — я по незнанию считаю, что для того чтобы удовлетворять условиям некоторого ТЗ
Для того, чтобы удовлетворить условиям вашего ТЗ, достаточно перехватить операцию открытия исполняемого файла. Т.е. предлагается контролировать процедуру открытия файлов на исполнение (FILE_EXECUTE). Соответственно, корректно это решается с помощью (мини)фильтра файловой системы. Можно, конечно, и ZwCreateFile перехватить, но этот вариант обладает уязвимостью (если делать в лоб).
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Для того, чтобы удовлетворить условиям вашего ТЗ, достаточно перехватить операцию открытия исполняемого файла. Т.е. предлагается контролировать процедуру открытия файлов на исполнение (FILE_EXECUTE). Соответственно, корректно это решается с помощью (мини)фильтра файловой системы. Можно, конечно, и ZwCreateFile перехватить, но этот вариант обладает уязвимостью (если делать в лоб).
IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
Здравствуйте, TarasCo, Вы писали:
TC>IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
Этот подход будет работать только для тех файлов, доступ к которым на запуск уже разграничен. Условно говоря, можно прийти с дискетой/флешкой и запустить программу с нее.
Административно проблему можно решить только в XP и выше путем настройки политики ограниченного использования программ (software restriction policies).
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>Здравствуйте, TarasCo, Вы писали:
TC>>IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
Совершщенно согласен... Этого инструменнта более чем достаточно. Есть там свои сложности, но как таковой этот механизм, полностью достаточен.
SS>Административно проблему можно решить только в XP и выше путем настройки политики ограниченного использования программ (software restriction policies).
Однако Вы не правы, МС ещё в далеком уже и не помню каком году, предлагал спец. тулузу... Которая кстати, построена на схожей с изначальной идее...
Здравствуйте, Andrew.W Worobow, Вы писали:
TC>>>IMHO для реализации ТЗ вообще не нужно ничего перехватывать, нужно лишь расставить правильно права доступа на каталоги и наследование прав файлами. Т.е достаточно просто некой админской тулзы, чтобы сделать этот процесс удобнее.
AWW>Совершщенно согласен... Этого инструменнта более чем достаточно. Есть там свои сложности, но как таковой этот механизм, полностью достаточен.
Пожалуйста, приведите пример административного вмешательства, в результате которого пользователь не сможет запустить программу с отчуждаемого носителя.
SS>>Административно проблему можно решить только в XP и выше путем настройки политики ограниченного использования программ (software restriction policies).
AWW>Однако Вы не правы, МС ещё в далеком уже и не помню каком году, предлагал спец. тулузу... Которая кстати, построена на схожей с изначальной идее...
AWW><a target='_blank' class='m' href='http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q320181'>Q320181</a>...
AWW>Ну если не поленитесь прочитать, смешная тулуза...
Сами-то читали?
To restrict access to a program, the program must reside on the Terminal server.
Здравствуйте, Sergey Storozhevykh, Вы писали:
AWW>>Совершщенно согласен... Этого инструменнта более чем достаточно. Есть там свои сложности, но как таковой этот механизм, полностью достаточен.
SS>Пожалуйста, приведите пример административного вмешательства, в результате которого пользователь не сможет запустить программу с отчуждаемого носителя.
Это как это? У себя что-ли на компе мышкой потыкать, или что?... Сказано, всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу... И вообще всё эти перехвадчики, это от незнания... как тоже можно сделать, законными средствами... И от незнания, того что этого перехвата не достаточно...
SS>Сами-то читали?
Читал, и что, а вы пробовали... Я то вот ещё в 2000, году всё это читал...
...
SS>Теперь перечитайте ТЗ от автора. Не поленитесь
Интересно, причем тут "ТЗ", ... Вы сказали, что "Административно проблему можно решить только в XP и выше"... Вы ну вот вам и ответ от МСа...
А по ТЗ, ну бред, всё это... И детский сад... Пусть он перехватит "то", что он хочет, а я запушу "то", что я захочу... причем без административных прав...
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Это как это? У себя что-ли на компе мышкой потыкать, или что?... Сказано, всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу... И вообще всё эти перехвадчики, это от незнания... как тоже можно сделать, законными средствами... И от незнания, того что этого перехвата не достаточно...
То есть вы утверждаете, что встроенного механизма разграничения доступа к файлам "более чем достаточно"
, для того чтобы реализовать замкнутость программной среды. Попробую доказать вам обратное.
Как известно, полноценный (применительно к нашему случаю — способный контролировать доступ к файлу на исполнение) механизм контроля доступа к файловым объектам реализуется средствами файловой системы NTFS и позволяет настроить политику доступа к файлам и папкам в пределах одного логического тома. Следовательно, для того чтобы привести систему в безопасное состояние, необходимо на каждом NTFS-томе отдельно реализовать выбранную модель контроля доступа. Очевидно, что таким образом настроенная система будет сохранять свойства защищенности только в условиях отсутствия возможности подключения к системе новых томов. Т.к. мы не можем установить правила разграничения доступа априори для вновь появляющихся томов.
Другими словами, встроенный механизм разграничения доступа к файлам, охарактеризованный вами как полностью достаточный для обеспечения замкнутости программной среды, будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
Не согласны? Аргументируйте.
Для того чтобы обеспечить замкнутость программной среды в общем случае, механизм контроля доступа должен быть реализован поверх всех файловых систем. С помощью файлового фильтра, например.
SS>>Сами-то читали?
AWW>Читал, и что, а вы пробовали... Я то вот ещё в 2000, году всё это читал...
Для тех, кто в танке, повторяю:
To restrict access to a program, the program must reside on the Terminal server.
Или вы считаете, что защищаться от несанкционированного запуска программ целесообразно только на терминальном сервере? Обоснуйте.
SS>>Теперь перечитайте ТЗ от автора. Не поленитесь
AWW>Интересно, причем тут "ТЗ", ... Вы сказали, что "Административно проблему можно решить только в XP и выше"... Вы ну вот вам и ответ от МСа...
Автор ищет решение проблемы для Win2000.
AWW>А по ТЗ, ну бред, всё это... И детский сад... Пусть он перехватит "то", что он хочет, а я запушу "то", что я захочу... причем без административных прав...
Голословно как-то. Расскажите, как вы обойдете механизм обеспечения замкнутости программной среды, выполненный на основе файлового (мини)фильтра, контролирующего операцию открытия файла на исполнение?
Съемные носители это вечная головная боль для администраторов Windows . Вот если бы томы не монтировались автоматически, а на подобие UNIX требовали команды mount, а для исполнения команды нужны были бы административные привилегии, вот бы было всем счастье .
Кстати, юзер может еще примонтировать сетевой диск, для этого не нужны особые привилегии. Из этого следует, что подобные меры безопасности придется делать на всех машинах сети, иначе юзеры начнут "помогать" друг другу.
Здравствуйте, Sergey Storozhevykh, Вы писали:
SS>То есть вы утверждаете, что встроенного механизма разграничения доступа к файлам "более чем достаточно"
, для того чтобы реализовать замкнутость программной среды. Попробую доказать вам обратное.
Нет, не надо передёргивать, это _вы_ сказали, "встроенного механизма разграничения доступа к файлам", я сказал только... и могу повторить — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу"
Для тех, кто видит разграничение прав доступа, только на NTFS, разжую — Вся система виндов построена на обьектах, у обьекта, если вы конечно знаете, а не только умеете хуки ставить, есть SECURITY_DESCRIPTOR, внутрии которого есть и Owner, Group, Sacl, Dacl...
И причем тут всего лищь, какая то частная NTFS, я не знаю?... Видимо вы сами видите только её, и с этим вашим виденением спорите...
И ещё — IoCreateDeviceSecure, функция не експортируется кернелом, а реализуется через "wdmsec.lib", и не использует IoCreateDevice, а на прямую работает с обьектами.... То есть делает тоже, что и IoCreateDevice, но только SECURITY_DESCRIPTOR берёт не через IopCreateDefaultDeviceSecurityDescriptor, а из переданных её параметров ...
Да, в библиотеке эта фанкция называется WdmlibIoCreateDeviceSecure.
...
SS>Как известно, полноценный ....
Вы так много написали, и всё простите не о чём...
SS>Не согласны? Аргументируйте.
С чем я должен быть не соглаен? С вашим видением ядра WINDOWS?
Могу только постараться обьяснить, в чем ваш подход ошибочен в приципе —
Что, по сути предлагается (вы предлагаете): добавить некий дополнительный признак для файла, "можно запускать/нельзя". И
назначить некие ваши внутрении ACLы типа : "администратору можно" а "другим нет"...
Но зачем? Когда запуск файла начинается с его открытия и причем от имени того кто его запускает. Зачем городить ещё один самопальный атрибут, когда есть и так полный набор, и причем регулируемый для каждого конкретного пользователя, а не тупо АДМИН/ЮЗЕР. Могу только предположить, что всё это скорее всего просто от незнания "как правильно сделать", а сделать надо.
Ну согласитесь, что вместо того чтобы просто расставить права доступа не разумно пихать код (и кстати ведь наверняка с уязвимостями) в ядро.
*******************************************************************
По тому, что ниже спорить :)) Больше не буду... Ибо не о чем.
*******************************************************************
SS>
SS>To restrict access to a program, the program must reside on the Terminal server.
SS>Или вы считаете, что защищаться от несанкционированного запуска программ целесообразно только на терминальном сервере? Обоснуйте.
No comment
AWW>А по ТЗ, ну бред, всё это... И детский сад... Пусть он перехватит "то", что он хочет, а я запушу "то", что я захочу... причем без административных прав...
SS>Голословно как-то. Расскажите, как вы обойдете механизм обеспечения замкнутости программной среды, выполненный на основе файлового (мини)фильтра, контролирующего операцию открытия файла на исполнение?
Знаете, я уже начинаю сомневаться в вашей, простите адекватности... ЧТО голословно? Причем тут какой-то файловый мини-фильтр... Это вы в вашей голове за меня нафантазировали... Я нигде, такого не говорил... Про "ТО" читайте тут
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Нет, не надо передёргивать, это _вы_ сказали, "встроенного механизма разграничения доступа к файлам", я сказал только... и могу повторить — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу"
AWW> Для тех, кто видит разграничение прав доступа, только на NTFS, разжую — Вся система виндов построена на обьектах, у обьекта, если вы конечно знаете, а не только умеете хуки ставить, есть SECURITY_DESCRIPTOR, внутрии которого есть и Owner, Group, Sacl, Dacl...
AWW>И причем тут всего лищь, какая то частная NTFS, я не знаю?... Видимо вы сами видите только её, и с этим вашим виденением спорите...
Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
AWW>Добавлю —
AWW>читайте до прояснение — IoCreateDeviceSecure...
А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
SS>>Не согласны? Аргументируйте.
AWW>С чем я должен быть не соглаен? С вашим видением ядра WINDOWS?
Я утверждаю, что:
Встроенный механизм разграничения доступа к файлам будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
AWW>Могу только постараться обьяснить, в чем ваш подход ошибочен в приципе —
AWW>Что, по сути предлагается (вы предлагаете): добавить некий дополнительный признак для файла, "можно запускать/нельзя". И AWW> назначить некие ваши внутрении ACLы типа : "администратору можно" а "другим нет"...
Так, хотя можно и полномасштабную модель дискреционного контроля доступа развернуть. Можно мандатную, не суть.
AWW>Но зачем? Когда запуск файла начинается с его открытия и причем от имени того кто его запускает. Зачем городить ещё один самопальный атрибут, когда есть и так полный набор, и причем регулируемый для каждого конкретного пользователя, а не тупо АДМИН/ЮЗЕР. Могу только предположить, что всё это скорее всего просто от незнания "как правильно сделать", а сделать надо.
Да, можно разграничить для уже присутствующих в системе файловых объектов, но не для вновь появляющихся в следствие монтирования новых томов. Основная проблема состоит в том, что вы не можете назначить атрибуты доступа тем объектам, которые еще не присутствуют в системе. В пределах одного тома это еще разруливается наследованием, но в рамкай всей системы — никак. Это следствие фундаментального принципа, положенного в основу всей разграничительной политики доступа: права устанавливаются для объекта, но не субъекта доступа.
AWW>Ну согласитесь, что вместо того чтобы просто расставить права доступа не разумно пихать код (и кстати ведь наверняка с уязвимостями) в ядро.
Если бы все было, как вы говорите, зачем MS ввела в Windows XP политику ограниченного использования программ, о которой я уже писал выше? Они, наверное, забыли у вас спросить, как реализовать замкнутость программной среды уже существующими на тот момент средствами?
Кстати, MS "впихнула" код, реализующий process restriction policy, в kernel32.dll — на уровне CreateProcess.
AWW>Знаете, я уже начинаю сомневаться в вашей, простите адекватности... ЧТО голословно? Причем тут какой-то файловый мини-фильтр... Это вы в вашей голове за меня нафантазировали... Я нигде, такого не говорил... Про "ТО" читайте тут
Простите, вы про что? Я никаким, простите боком не отпираюсь ибо нет повода... Вы опять похоже хотите выдать желаемое за действительное, процитируете мои слова, где, я говорил, что-то про "файлы"? Я опять, уже похоже третий раз повторяю — "всё делается через безопасность... И этого механизма вполне достаточно... А если не удобно, то надо делать спец. тутлузу".
Странный, вы всё-таки какой-то, зачем мне приписывать то чего я не говорил, и даже могу сказать больше... Мне это даже во сне не могло приснится! Файлы. Это вы все время с файлами боретесь, вместо того чтобы, один раз и до конца разобраться с моделью безопасности WINDOWS.
SS>Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
Я вообще ничего не понял, вы простите на грубом слове несёте какой то детский лепет — Что такое "контролировать процедуру запуска процесса" Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре ) которая "запускает" процессы.
SS>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
Хотите можете явно указать "запрет", но я думаю что и просто "не разрешить чтение" будет вполне достаточно. А что касается "какого" конкретно устройства, ну итдипенс...
SS>Я утверждаю, что:
SS>
SS>Встроенный механизм разграничения доступа к файлам будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
Ну могу только повторить — в windows, всё построено на объектах, объекты это ВСЁ и файлы и потоки и секции... Да всё, за редким-редким исключением... И как такового нет "Встроенный механизм разграничения доступа к файлам" есть к объектам...
Вы вообще в какой области специализируетесь? Что никогда не слышали про WinObj?
Там в верху у неё есть такая кнопочка "properties", посмотрите... Авось вопросов будет поменьше.
Да и почитайте у Руссиновича — главу "Подсистема ввода-вывода" там в общих чертах все хорошо рассказано...
SS>Да, можно разграничить для уже присутствующих в системе файловых объектов, но не для вновь появляющихся в следствие монтирования новых томов.
Опять какой-то детский сад — да легко! Ну ура, и не раз уже делалось...
SS>Основная проблема состоит в том, что вы не можете назначить атрибуты доступа тем объектам, которые еще не присутствуют в системе.
Да откуда же такая уверенность, что "не можете"... Вы что-нибудь про наследование слышали... Все тома монтируются на каких-то устройствах, так просто "ТОМОВ" не бывает...
SS>Если бы все было, как вы говорите, зачем MS ввела в Windows XP политику ограниченного использования программ, о которой я уже писал выше? Они, наверное, забыли у вас спросить, как реализовать замкнутость программной среды уже существующими на тот момент средствами?
Не знаю, это бизнес... Захотели сделали, а почему 1000 и одна причина может быть для этого...
А вообще, это что аргумент в пользу невозможности? Странный однако...
PS:
Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
> процесс можно создать прямо из памяти > И для этого даже админских прав не надо
если можно, с этого места поподробнее.
или в двух словах, саму идею.
в смысле, не как процесс из памяти создать,
а как без админских прав, как вообще без исполняемого файла.
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
AWW> :))) Да кстати, процесс можно и вообще без исполняемого файла создать... :))) Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
Особенно интересует "без админских прав". Идея? Как?
[skip]
AWW>PS:
AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
Опять двадцать пять А как-же "фундамент".
Пусто
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Я читаю эту ветку, как детектив. Жду каждого нового поста. Не хочу судить кто прав, кто нет, просто получаю удовольствие от чтения. Парни — не останавливайтесь! Все это уже однозначно идет в мемориз .
Здравствуйте, TarasCo, Вы писали:
TC>Я читаю эту ветку, как детектив. Жду каждого нового поста. Не хочу судить кто прав, кто нет, просто получаю удовольствие от чтения. Парни — не останавливайтесь! Все это уже однозначно идет в мемориз .
Не у меня уже дежавю начинается от чтения
Пусто
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, Andrew.W Worobow, Вы писали:
SS>>Пожалуйста, объясните мне: для каких типов объектов, кроме файловых, нужно установить атрибуты доступа, чтобы контролировать процедуру запуска процесса? Я просто не в курсе, потому и написал про NTFS.
AWW>Я вообще ничего не понял, вы простите на грубом слове несёте какой то детский лепет — Что такое "контролировать процедуру запуска процесса" Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре ) которая "запускает" процессы.
Демагогия. Сергей задал конкретный вопрос, а вы ему гнете пальцы про 15 лет
SS>>А, понял! Точно, надо установить запрет исполнения устройства. Блин, только вот не пойму какого. Подскажите, а?
AWW>Хотите можете явно указать "запрет", но я думаю что и просто "не разрешить чтение" будет вполне достаточно. А что касается "какого" конкретно устройства, ну итдипенс...
опять конкретный вопрос, и уклончивый ответ — ит депендс.
SS>>Я утверждаю, что:
SS>>Встроенный механизм разграничения доступа к файлам будет корректно реализовывать свои защитные функции (т.е. обеспечивать защиту от несанкционированного запуска исполняемых файлов) только в системах, где отсутствует возможность подключения отчуждаемых носителей (CD, дискета, флешка).
AWW>Ну могу только повторить — в windows, всё построено на объектах, объекты это ВСЁ и файлы и потоки и секции... Да всё, за редким-редким исключением... И как такового нет "Встроенный механизм разграничения доступа к файлам" есть к объектам...
про объекты все мы прекрасно знаем. Но разговор идет про отчуждаемые носители, а не про то, что поток или мутекс есть объект. Опять демагогия.
AWW>Вы вообще в какой области специализируетесь? Что никогда не слышали про WinObj? Там в верху у неё есть такая кнопочка "properties", посмотрите... Авось вопросов будет поменьше. AWW>Да и почитайте у Руссиновича — главу "Подсистема ввода-вывода" там в общих чертах все хорошо рассказано...
А тут уже просто наезд. Развести демагогию, не дать ни одного конкретного ответа, а затем наехать на оппонента — это наглость уже.
убедительная просьба следить за объемом цитирования — модератор
AWW> Да кстати, процесс можно и вообще без исполняемого файла создать... Да вообще без файла... И все будет прекрасненько работать... И для этого даже админских прав не надо... Прямо из памяти...
чудеса да и только Создайте, а мы всем форумом внимательно понаблюдаем. Или опять сказано не подумав ?
МС ещё в далеком уже и не помню каком году, предлагал спец. тулузу... Которая кстати, построена на схожей с изначальной идее... 
. Вот если бы томы не монтировались автоматически, а на подобие UNIX требовали команды mount, а для исполнения команды нужны были бы административные привилегии, вот бы было всем счастье 
Это вы все время с файлами боретесь, вместо того чтобы, один раз и до конца разобраться с моделью безопасности WINDOWS.
Вы простите про что? Я вот уже почти 15 лет как занимаюсь системным программированием и не знал, что есть какая-то ОСОБАЯ процедура (Наверное в ядре 
) которая "запускает" 
А как-же "фундамент".
