The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Безопасность средств IPC sysv, posix"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

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

по pid я определяю доверенный это процесс или нет, и тем более управление начинается после fork()

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

19. "Безопасность средств IPC sysv, posix"  
Сообщение от DeadMustdie email(??) on 24-Окт-07, 09:44 
Механизмы разграничения прав доступа в UNIX-системах основаны на идентификации пользователей. В описанном виде задача заключается в создании дополнительного механизма, ограничивающего взаимодействие между процессами одного пользователя. Такой механизм должен включать в себя некие средства классификации на уровне кому можно - кому нельзя, плюс механизм отказа во взаимодействии тем, кому нельзя. Стандартного, а тем более переносимого механизма такого вида попросту нет.

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

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

Архив | Удалить

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




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру