форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Безопасность средств IPC sysv, posix"

Сообщение от ZaCo (ok) on 19-Окт-07, 16:46

существует ли относительно универсальный способ БЕЗОПАСНОГО межпроцессорного взаимодействия? то есть, мне необходимо наладить связь между двумя процессами таким образом, чтобы никакой любой третий процесс не смог получить доступ к передаваемым данным, при условии, что третий процесс вполне может быть запущен от пользователей как первого так и второго процессов. естественно, необходимо добиться максимальной скорости передачи данных, поэтому лучше защита на уровне системы, а не приложения, например шифрования. зы безопасность понимается не только в смысле чтения, но и невозможности недоверенным процессам писать в канал или предложенный вами вид ipc.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Безопасность средств IPC sysv, posix"

Сообщение от anonymous (??) on 19-Окт-07, 17:11

pipe() + fork()?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (ok) on 19-Окт-07, 17:27
	>pipe() + fork()? процессы отнюдь не родственные:)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Безопасность средств IPC sysv, posix"

Сообщение от angra (ok) on 19-Окт-07, 17:54

а в чем проблема шифрования? Необязательно ведь выбирать ресурсоемкий алгоритм. Возьмите что-нибудь простое с симметричным шифрованием и диффи-хеллман для обмена ключом.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (ok) on 19-Окт-07, 18:07
	>а в чем проблема шифрования? Необязательно ведь выбирать ресурсоемкий алгоритм. Возьмите что-нибудь >простое с симметричным шифрованием и диффи-хеллман для обмена ключом. за диффи-хеллмана спасибо, интересно:) но мне бы очень не хотелось задействовать для действительно безопасной генерации длинную арифметику и вообще сам факт применения шифрования, возможно все же есть техническое решение уровня системы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Безопасность средств IPC sysv, posix"

Сообщение от pavel_simple (ok) on 19-Окт-07, 18:22

модуль ядра позволит и читать и писать всё что угодно в каком угодно месте любого процесса -- и вообще ИМХО какая-то очень странная задача а вообще есть такие вещи как RSBAC и LIDS например -- в данном случае самое оно. (особенно RSBAC, selinux с его MAC не знаю умеет-ли)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (ok) on 19-Окт-07, 18:39
	>а вообще есть такие вещи как RSBAC и LIDS например -- в >данном случае самое оно. (особенно RSBAC, selinux с его MAC не >знаю умеет-ли) эхх, переносимость без дополнительных надстроек на ядром играет не малую роль, поэтому такой вариант тоже не подойдет. >модуль ядра позволит и читать и писать всё что угодно в каком >угодно месте любого процесса -- и вообще ИМХО какая-то очень странная >задача но разве не логично иметь системную функцию типа flock, только действительно безопасную, где read, например, будет блокироваться без договоренности процессов. я вот и интересуюсь существует ли подобное решение
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Безопасность средств IPC sysv, posix"
	Сообщение от eee (ok) on 20-Окт-07, 21:03
	> существует ли подобное решение fifo и unix socket не подходят? (кроме переносимости). fifo имеет два конца, socket тоже можно сделать лимит соединения 1, третий никак не вклинится. Защищать файл сокета, fifo правами.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (??) on 20-Окт-07, 23:03
	спасибо, очень красивая модель unix-sockets, но опять же - не могу найти способа идентификации программы-клиента. в принципе, используя концепцию сокетов это становится основной проблемой тк вклиниться в существующее соединение по-теории, как я понимаю невозможно. теоретически на пальцах это должно выглядить так: клиент, при подключении, отправляет свой pid, серверная программа проверяет его принадлежность к доверенным процессам и отправляет случайное число, которое должно каким-то образом отобразиться в адресном пространстве процесса или где-то еще, но чтобы это подтверждало, что это тот самый процесс, с отправленным pid, если это происходит, то очевидно что на подключении доверенный процесс. тут логично было бы использовать разделяемую память, однако в поставленной задаче процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента и если при создании shmget, например, указать бит w для владельца, без чего записывать в эту область у нас не будет прав, то все процессы этого пользователя смогут туда писать... мысль вторая, клиент, после получения случайного числа, ставит дополнительно бит записи в /proc/pid, создает там сокет /proc/pid/RANDOM и общение происходит уже по нему, снимает бит записи с каталога.. вполне возможно, что это решение, однако смущает момент установки/снятия бита
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Безопасность средств IPC sysv, posix"
	Сообщение от eee (ok) on 21-Окт-07, 00:25
	> процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента Тогда все завивит от информированости злоумышленика о работе пограммы. Сорцы будут закрыты? :(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Безопасность средств IPC sysv, posix"
	Сообщение от anonymous (??) on 21-Окт-07, 02:26
	>процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента Тогда он сможет использовать ptrace() и ему любые защиты будут "по барабану", так как он сможет читать готовые полученные (и даже расшифрованные) данные прямо из адресного пространства процесса-клиента.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (??) on 21-Окт-07, 10:43
	>>процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента > >Тогда он сможет использовать ptrace() и ему любые защиты будут "по барабану", >так как он сможет читать готовые полученные (и даже расшифрованные) данные >прямо из адресного пространства процесса-клиента. крис касперски писал, что можно вызвать ptrace самому себе, тем самым блокировав все остальные подобные вызовы к этому процессу. отладчики уровня ядра естественно не в счет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Безопасность средств IPC sysv, posix"
	Сообщение от anonymous (??) on 21-Окт-07, 23:03
	>>>процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента >> >>Тогда он сможет использовать ptrace() и ему любые защиты будут "по барабану", >>так как он сможет читать готовые полученные (и даже расшифрованные) данные >>прямо из адресного пространства процесса-клиента. > >крис касперски писал, что можно вызвать ptrace самому себе, тем самым блокировав >все остальные подобные вызовы к этому процессу. отладчики уровня ядра естественно >не в счет. Можно запустить процесс в "спящем" состоянии под ptrace(), а потом забить вызов ptrace() исследуемой программы NOP-ами и запустить процесс дальше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (??) on 21-Окт-07, 23:42
	а откуда права на запись в адресное пространство возьмутся?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Безопасность средств IPC sysv, posix"
	Сообщение от anonymous (??) on 22-Окт-07, 00:03
	>а откуда права на запись в адресное пространство возьмутся? Объясню подробнее: 1. запускаем вашу программу под ptrace() в спящем состоянии.  Она не выполняется. 2. забиваем ей NOP-ами её вызов ptrace() при помощи ptrace(PTRACE_POKEDATA, ...): man ptrace PTRACE_POKETEXT, PTRACE_POKEDATA               Copies the word data to location addr in the child's memory.  As above, the two requests are currently equivalent. 3. запускаем программу дальше -- она ptrace() не вызывает 4. ставим ей breakpoint в нужных местах, и в те моменты считываем данные, полученные из другого процесса
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (??) on 22-Окт-07, 00:16
	дело в том, что запустить приложение в дочернем процессе конечно же будет можно, но в таком случае, в моей конкретной задаче (на уровне реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:) естественно я не говорю про отладку от привилегированного пользователя, например root'а, но от него и защищаться не стоит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Безопасность средств IPC sysv, posix"
	Сообщение от anonymous (??) on 22-Окт-07, 03:29
	>дело в том, что запустить приложение в дочернем процессе конечно же будет >можно, но в таком случае, в моей конкретной задаче (на уровне >реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:) Вы просто в начале сказали, что атакующий может запускать программы от uid процесса-клиента.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (??) on 22-Окт-07, 10:21
	>>дело в том, что запустить приложение в дочернем процессе конечно же будет >>можно, но в таком случае, в моей конкретной задаче (на уровне >>реализации) uid процесса будет НЕдоверительным, а это отследиться перед отправкой данных:) > >Вы просто в начале сказали, что атакующий может запускать программы от uid >процесса-клиента. не совсем, демон запускается от рута, идет fork()+setuid и тут уже дочерний процесс-клиент в распоряжении злоумышленника. более того, из процесса нельзя будет вызвать другую программу, линк на исполняемый файл процесса проверяется сервером. мне кажется, что это не позволит отладить процесс.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Безопасность средств IPC sysv, posix"
	Сообщение от angra (ok) on 24-Окт-07, 00:29
	>не совсем, демон запускается от рута, идет fork()+setuid Зачем тогда махинации с пересылкой pid? Всю "договоренность"(например генерацию подтверждающего ключа) сделайте до fork
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Безопасность средств IPC sysv, posix"
	Сообщение от ZaCo (ok) on 24-Окт-07, 16:36
	>>не совсем, демон запускается от рута, идет fork()+setuid > >Зачем тогда махинации с пересылкой pid? Всю "договоренность"(например генерацию подтверждающего ключа) сделайте >до fork по pid я определяю доверенный это процесс или нет, и тем более управление начинается после fork()
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Безопасность средств IPC sysv, posix"

Сообщение от DeadMustdie (??) on 24-Окт-07, 09:44

Механизмы разграничения прав доступа в UNIX-системах основаны на идентификации пользователей. В описанном виде задача заключается в создании дополнительного механизма, ограничивающего взаимодействие между процессами одного пользователя. Такой механизм должен включать в себя некие средства классификации на уровне кому можно - кому нельзя, плюс механизм отказа во взаимодействии тем, кому нельзя. Стандартного, а тем более переносимого механизма такого вида попросту нет. По моим ощущениям, исходная задача некорректно сформулирована: в нее добавлены избыточные технические ограничения. Что мешает запускать "доверенные" процессы в едином контексте безопасности (организованного на базе механизма пользователей и групп), исключив тем самым все существенные угрозы по "вклиниванию" действий злоумышленников во взаимодействие???

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]