информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеВсе любят медЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[UPD] Это понятно. Но зато возможность _создания_ секурити... 13.08.09 18:09  Число просмотров: 2798
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 13.08.09 21:59  Количество правок: 1
<"чистая" ссылка>
> > Да хрен с ними, с окнами. Просто получается что мона
> свой
> > код инжектить в процессы другого юзера.
> Но этот юзер по любому ты сам, потому что работаешь не
> только в той же сессии, а и на том же десктопе. Другой юзер
> будет работать вообще в другой сессии, а не только на
> другом десктопе/воркстейшене. Так что как по мне здесь все
> чисто. Ну а сервис, буде ему понадобится запустить чего
> нибудь в юзерской сессии будет иметь System IL и
> соответственно будет надежно изолирован от посягательств.
Это понятно. Но зато возможностьсозданиясекурити решений, основанных на принципе работы под отдельным юзером сразу идут лесом, или, как минимум, порядочным геморроем. Отдельный десктоп конечно правильно, но неприемлемо для юзера.
[UPD]
Просто меня угораздило стать разработчиком такого секурити решения, и вышеупомянутое поведение виндовых хуков потребовало следующего финта ушами - грузим во все процессы свою длл (мы ее грузим так же и по другим причинам), затем в каждом процессе патчим IAT user32.dll так чтобы LoadLibraryExW указывало на наш враппер, который связывается с сервисом для того, чтобы выяснять, - разрешать ли user32 всасывать в процесс каждую конкретную длл. Как это выясняет сервис - совершенно отделтый вопрос) Но если бы винда проверяла токен поставившего хук на DACL процесса который создал окно, нормально, а не просто IL'ями - все получилось бы просто и элегантно.

> > EqualSid будет тормозить?.. Несложно было бы даже это
> > соптимизировать...
> Не, это точно тормозить не будет. IL-ы это обычный SID-ы и
> проверяются точно так же как и все остальные SID-ы.
Не совсем обычные. ILы отличаются только одной SubAuthority, т.е. фактически достаточно такого сравнения:
((SID*)(il1->Label.Sid))->SubAuthority[0]<=((SID*)(il2->Label.Sid))->SubAuthority[0]
<operating systems> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach