ANTICHAT — форум по информационной безопасности, OSINT и технологиям
ANTICHAT — русскоязычное сообщество по безопасности, OSINT и программированию.
Форум ранее работал на доменах antichat.ru, antichat.com и antichat.club,
и теперь снова доступен на новом адресе —
forum.antichat.xyz.
Форум восстановлен и продолжает развитие: доступны архивные темы, добавляются новые обсуждения и материалы.
⚠️ Старые аккаунты восстановить невозможно — необходимо зарегистрироваться заново.
 |
|
Безопасность средств IPC sysv, posix |

19.10.2007, 16:16
|
|
Banned
Регистрация: 20.06.2005
Сообщений: 880
Провел на форуме: 4610226
Репутация:
1332
|
|
Безопасность средств IPC sysv, posix
существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия? то есть, мне необходимо наладить связь между двумя процессами таким образом, чтобы никакой любой третий процесс не смог получить доступ к передаваемым данным, при условии, что третий процесс вполне может быть запущен от пользователей как первого так и второго процессов. естественно, необходимо добиться максимальной скорости передачи данных, поэтому лучше защита на уровне системы, а не приложения, например шифрования.
зы безопасность понимается не только в смысле чтения, но и невозможности недоверенным процессам писать в канал или предложенный вами вид ipc.
|
|
|

19.10.2007, 17:35
|
|
Banned
Регистрация: 20.06.2005
Сообщений: 880
Провел на форуме: 4610226
Репутация:
1332
|
|
одним из логических решений была бы ПОЛНАЯ блокировка канала(при его использовании) на чтение одним процессом. возможно ли это с точки зрения безопасности?
|
|
|

20.10.2007, 15:07
|
|
ы
Регистрация: 11.02.2007
Сообщений: 750
Провел на форуме: 1347723
Репутация:
1477
|
|
Сообщение от ZaCo
существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия?
Видимо всё-таки имелось ввиду межпроцессное взаимодействие, а не межпроцессорное. Способ для *nix существует, как буду дома - отпишусь.
__________________
..когда же кто-нибудь выпустит MD5(Unix) брутер на GPU.... жду....
Последний раз редактировалось ShadOS; 20.10.2007 в 15:23..
|
|
|

20.10.2007, 19:23
|
|
Banned
Регистрация: 20.06.2005
Сообщений: 880
Провел на форуме: 4610226
Репутация:
1332
|
|
заранее спасибо
|
|
|

20.10.2007, 20:08
|
|
Pagan Heart
Регистрация: 12.08.2004
Сообщений: 3,791
Провел на форуме: 6490435
Репутация:
2290
|
|
да блин, через банальные пайпы с асимерт. шифр. =)
|
|
|

20.10.2007, 20:30
|
|
Banned
Регистрация: 20.06.2005
Сообщений: 880
Провел на форуме: 4610226
Репутация:
1332
|
|
>>да блин, через банальные пайпы с асимерт. шифр. =)
я ищу способ, не затрагивающий шифрования. кстати, я подумал, и шифрование тоже внедрить сложно: даже используя алгоритм диффи-хеллмана для генерации ключа симм. шифра не смог найти способа нужной идентификации клиента-процесса.. чтобы шифрованное сообщение дошло в "те руки".
забавно, но только сейчас вспомнил о unix-сокетах, попробую посмотреть
Последний раз редактировалось ZaCo; 20.10.2007 в 21:48..
|
|
|

20.10.2007, 21:57
|
|
ы
Регистрация: 11.02.2007
Сообщений: 750
Провел на форуме: 1347723
Репутация:
1477
|
|
Кстати, а почему бы прото к каждому блоку данных не добавлять некий Sequence ID и проверять его?
__________________
..когда же кто-нибудь выпустит MD5(Unix) брутер на GPU.... жду....
|
|
|

20.10.2007, 22:08
|
|
Banned
Регистрация: 20.06.2005
Сообщений: 880
Провел на форуме: 4610226
Репутация:
1332
|
|
этот блок данных может быть перехвачен. а как id не подтвердит того, что данные пришли от кого нужно? отсюда и возвращать данные не пойми кому тоже не вариант
|
|
|

20.10.2007, 22:21
|
|
ы
Регистрация: 11.02.2007
Сообщений: 750
Провел на форуме: 1347723
Репутация:
1477
|
|
Вот, собственно я нащёл что искал. В книге Р.Стиверса "unix - Взаимодейсвие процессов" читай пункт 3.6 "Повторное использование идентификаторов".
Надеюсь, поможет.
__________________
..когда же кто-нибудь выпустит MD5(Unix) брутер на GPU.... жду....
|
|
|

20.10.2007, 22:50
|
|
Banned
Регистрация: 20.06.2005
Сообщений: 880
Провел на форуме: 4610226
Репутация:
1332
|
|
а при чем здесь это? у меня серверная часть имеет вполне открытое и постоянное имя ipc на файловой системе, поэтому злоумышленник может вполне добросовестно получать дескриптор ftok("server")  меня интересует как перехватить посланное сообщение к серверной части первым, то есть самим сервером.
очень красивая модель unix-sockets, но опять же - не могу найти способа идентификации программы-клиента. в принципе, используя концепцию сокетов это становится основной проблемой тк вклиниться в существующее соединение по-теории, как я понимаю невозможно.
теоретически на пальцах это должно выглядить так: клиент, при подключении, отправляет свой pid, серверная программа проверяет его принадлежность к доверенным процессам и отправляет случайное число, которое должно каким-то образом отобразиться в адресном пространстве процесса или где-то еще, но чтобы это подтверждало, что это тот самый процесс, с отправленным pid, если это происходит, то очевидно что на подключении доверенный процесс.
тут логично было бы использовать разделяемую память, однако в поставленной задаче процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента и если при создании shmget, например, указать бит w для владельца, без чего записывать в эту область у нас не будет прав, то все процессы этого пользователя смогут туда писать...
мысль вторая, клиент, после получения случайного числа, ставит дополнительно бит записи в /proc/pid, создает там сокет /proc/pid/RANDOM и общение происходит уже по нему, снимает бит записи с каталога.. вполне возможно, что это решение.
|
|
|
|
 |
|
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
|
|
|
|