Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Root-уязвимость из-за некорректных настроек в пакете nginx д..."	+/–
Сообщение от opennews (?), 17-Ноя-16, 20:59
Опубликованы (http://openwall.com/lists/oss-security/2016/11/16/2) подробности и эксплоит для уязвимости (CVE-2016-1247 (https://security-tracker.debian.org/tracker/CVE-2016-1247)) в пакете с nginx, в конце октября устранённой в Debian (https://www.debian.org/security/2016/dsa-3701) и Ubuntu (https://www.ubuntu.com/usn/usn-3114-1/). Проблема специфична (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-P...) для deb-пакета nginx, не касается самого nginx, и может привести к выполнению кода  с правами root при наличии у атакующего прав доступа  "www-data" в системе. Проблема вызвана (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-P...)  некорректными настройками доступа к директории с логами web-сервера. Директория с логами /var/log/nginx имеет владельца "www-data", что позволяет пользователю с данными полномочиями произвольно манипулировать файлами в данной директории.  При запуске или перезапуске nginx в лог добавляются записи от процесса с правами  root. Периодически скрипт ротации логов меняет владельца файлов с логами на "www-data". Локальный пользователь с правами www-data может создать в директории /var/log/nginx символическую ссылку вместо файла с логом "error.log". Таким образом, направив символическую ссылку "/var/log/nginx/error.log" на другой файл перед перезапуском nginx, можно изменить любой файл в системе. Перезапуск nginx по сигналу USR1 осуществляется скриптом ротации логов, который по умолчанию вызывается из cron.daily каждый день в 6:25. Для организации запуска кода с правами root в эксплоите осуществляется создание символической ссылки на файл /etc/ld.so.preload (/var/log/nginx/error.log -> /etc/ld.so.preload), который после перезапуска nginx будет создан, а после ротации лога получит владельца www-data, что позволит прописать в нём произвольную библиотеку атакующего, после чего библиотека  будет активироваться при выполнении любого исполняемого файла, например, можно запустить suid root приложение /usr/bin/sudo. URL: http://openwall.com/lists/oss-security/2016/11/16/2 Новость: http://www.opennet.dev/opennews/art.shtml?num=45515
Ответить | Правка | Cообщить модератору

Сообщения

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

2. Сообщение от Аноним (-), 17-Ноя-16, 21:12	–29 +/–
>ротация логов Камон, сириусли? Зачем их хранить? Линковать на /dev/null, и все дела.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

3. Сообщение от Аноним (-), 17-Ноя-16, 21:12	+5 +/–
Опять дебиан отличился :) сначала OpenSSL, теперь ngnix...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #10

4. Сообщение от user455 (?), 17-Ноя-16, 21:13	+55 +/–
администратор локалхоста в чяте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #11

5. Сообщение от Crazy Alex (ok), 17-Ноя-16, 21:35	+/–
Тоже мне, сравнил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #6

6. Сообщение от Аноним (-), 17-Ноя-16, 22:06	–1 +/–
а что не так? и то и другое от кривых рук маинтейнера пакета. И учитывая распространенность дебиана - можно поспорить что уже ботнет поднялся..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8, #26

8. Сообщение от Crazy Alex (ok), 17-Ноя-16, 22:41	+1 +/–
Угу, ботнет от локальной уязвимости. Которую ты от ремотной, судя по всему, не отличаешь. Хотя даже там, насколько я знаю, ботнет не поднялся. Здесь же - не ssh, который есть вообще на любом сервере, а нгинкс, который может быть, а может и не быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #12, #33

10. Сообщение от Вареник (?), 17-Ноя-16, 22:42	–6 +/–
Каким боком Debian к сборке ngnix под DEB?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #17

11. Сообщение от тоже Аноним (ok), 17-Ноя-16, 22:53	+8 +/–
Перефразируя известный афоризм: есть администраторы, которые еще не хранят логи...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #24

12. Сообщение от тоже Аноним (ok), 17-Ноя-16, 22:56	–1 +/–
Ну, на шаред-хостингах нгинкс обычно не может не быть - ради ускорения его непременно ставят перед тем, на чем крутятся клиентские сайты. Правда, при этом вход от имени www-data (пользователя, от имени которого работает nginx) по ssh может быть вовсе заблокирован. А что там себе наваляют в домашних папочках пользователи - будет проигнорировано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #19, #20, #21, #56

13. Сообщение от odd.mean (ok), 17-Ноя-16, 22:59	+3 +/–
Казалось бы, что мешает использовать deb http://nginx.org/packages/debian/ CODENAME nginx или deb http://nginx.org/packages/mainline/debian/ CODENAME nginx ? Хотя мэйнтэйнерам, конечно, двойка.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59

17. Сообщение от Michael Shigorin (ok), 17-Ноя-16, 23:40	–2 +/–
> Каким боком Debian к сборке ngnix под DEB? Угадайте с двух, нет, с трёх попыток.  Третья -- на прочтение DSA-3701.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

18. Сообщение от ALex_hha (ok), 17-Ноя-16, 23:52	+1 +/–
> Опять дебиан отличился :) сначала OpenSSL, теперь ngnix.. еще стоит вспомнить exim в их исполнении ;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #35

19. Сообщение от Sw00p aka Jerom (?), 17-Ноя-16, 23:57	+1 +/–
думаю не опасно, если nginx и пхп на разных вирт серверах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

20. Сообщение от Sw00p aka Jerom (?), 17-Ноя-16, 23:59	+/–
> по ssh может быть вовсе заблокирован. там пхп реверсный шел юзается, ссх там тока админская консоль чтоб запустить ротацию логов, в реале нуно ждать конца дня )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

21. Сообщение от Аноним (-), 18-Ноя-16, 00:09	+/–
По умолчанию под пользователем www-data выполняются, например, php-скрипты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #22

22. Сообщение от тоже Аноним (ok), 18-Ноя-16, 00:19	+3 +/–
На шаредах php-скрипты выполняются от имени юзеров. А nginx, как я это понимаю - от имени пользователя, которому шелл вообще не требуется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27

23. Сообщение от Аноним (-), 18-Ноя-16, 00:34	+1 +/–
Сила мелочей, классный эффект. Не по теме а почему черепашка а не обезьяна с гранатой :D
Ответить | Правка | Наверх | Cообщить модератору

24. Сообщение от Аноним (-), 18-Ноя-16, 01:37	+1 +/–
некоторые гоняют при помощи syslog
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #31

25. Сообщение от Аноним (-), 18-Ноя-16, 02:03	+/–
exim стоит вспомнить безотносительно дебиана. Хотя что с его конфигаме делают в дебиане - это какой-то бесконечный ужас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

26. Сообщение от Аноним (-), 18-Ноя-16, 02:30	+2 +/–
> и то и другое от кривых рук маинтейнера пакета. Ну не совсем, изменение в OpenSSL одобрили сами авторы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

27. Сообщение от Sw00p aka Jerom (?), 18-Ноя-16, 03:09	+/–
>>от имени пользователя, которому шелл вообще не требуется. ну и пхп не требуется, но это же не мешает выполнять system(),exec(),passthru() и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #32

28. Сообщение от Аноним (-), 18-Ноя-16, 07:15	+4 +/–
А почему проблему видят в дебиане, а не в работе nginx с файлами логов? При получении сигнала USR1 он переоткрывает логи, создавая описанную проблему с симлинками. То есть единственное, в чем виноваты некоторые(к примеру в wheezy это не так) из debian дистров, так в том, что /var/log/nginx имеет владельца www-data. Однако ведь точно такая же проблема возникнет, если админ скажет nginx класть логи для виртуалхостов непосредственно в их каталоги, что весьма удобно и никаких предупреждений на этот счет в доке nginx нет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46

29. Сообщение от Аноним (-), 18-Ноя-16, 07:41	+/–
Получается, другие каталоги в /var/log с не-root владельцем тоже потенциально уязвимы...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30

30. Сообщение от angra (ok), 18-Ноя-16, 08:06	+1 +/–
Зависит от того, как программа обрабатывает симлинки. В данном случае nginx создает файл, следуя по симлинке, и меняет ему владельца на своего пользователя. Но не весь софт так делает. Проблема не ограничивается /var/log/*
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

31. Сообщение от Адекват (ok), 18-Ноя-16, 08:11	+/–
> некоторые гоняют при помощи syslog syslog появился до вашего рождения и всех всем устраивал столько лет, сколько вам еще нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #45

32. Сообщение от тоже Аноним (ok), 18-Ноя-16, 08:16	+/–
Удаленно зайти и выполнить описанные в статье действия - мешает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #36, #43

33. Сообщение от тигар (ok), 18-Ноя-16, 09:13	–1 +/–
> Угу, ботнет от локальной уязвимости. Которую ты от ремотной, судя по всему, > не отличаешь. Хотя даже там, насколько я знаю, ботнет не поднялся. > Здесь же - не ssh, который есть вообще на любом сервере, > а нгинкс, который может быть, а может и не быть. а конфиг iptables/sshd нельзя поправить/заменить своим на время, используя эту дыру?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #38

34. Сообщение от Loly (?), 18-Ноя-16, 10:53	+/–
Red Hat говорит что не проблема: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1247 Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #42

35. Сообщение от rt (??), 18-Ноя-16, 10:57	–1 +/–
Это же самый стабильно-серверный дистрибутив. История с openssh туда же)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

36. Сообщение от Онанимус (?), 18-Ноя-16, 10:58	+/–
> Удаленно зайти и выполнить описанные в статье действия - мешает. Вам же объясняют: любой локальный рут - это возможность поднятия ранее полученного  удаленного юзера. Как правило удаленный рут получается цепочкой сплоитов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #37

37. Сообщение от тоже Аноним (ok), 18-Ноя-16, 11:08	+/–
Не понимаю - зачем нужна обсуждаемая уязвимость, если уже получен локальный рут? В теме-то именно действия от имени пользователя, от которого запускается nginx. Если под таким пользователем нет возможности зайти удаленно - эксплойт неприменим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #39

38. Сообщение от Онанимус (?), 18-Ноя-16, 11:13	+/–
> а конфиг iptables/sshd нельзя поправить/заменить своим на время, используя эту дыру? Зачем? Если есть возможность добраться до этой дыры, то надо ставить реверс шелл. Ибо, насколько я понимаю, в файл, на который Вы сделаете ссылку, nginx будет гадить логами. ЗЫ: напомните, что за "конфиг iptables"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #49

39. Сообщение от Онанимус (?), 18-Ноя-16, 11:30	+/–
> Не понимаю - зачем нужна обсуждаемая уязвимость, если уже получен локальный рут? Издеваетесь что ли? Если хэккер получил удаленного www-data, то его возможности ограничены правами www-data. Вот тут то и приходит время обсуждаемой дыры. Если же Вам охота обсудить возможности получения удаленного www-data, то это тема для отдельного треда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #40

40. Сообщение от тоже Аноним (ok), 18-Ноя-16, 12:40	+1 +/–
Конкретно эта ветка и начинается с моего утверждения, что на шаредах пользователю, от имени которого запускается nginx, не нужна возможность удаленного входа. То есть он, при грамотной настройке - и не имеет такой возможности. Доступ же простого юзера (с оплаченным тарифом) не дает доступа к nginx.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

41. Сообщение от анонимус вульгарис (?), 18-Ноя-16, 13:41	+2 +/–
И после этого ещё катят бочку на Debian, где дыру сразу закрыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

42. Сообщение от Stax (ok), 18-Ноя-16, 14:47	+2 +/–
В редхат nginx не поставку входит, если что. Только в epel. Это несколько другой уровень ответственности. А низкий приоритет потому, что selinux из коробки от этой уязвимости защищает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #53

43. Сообщение от Sw00p aka Jerom (?), 18-Ноя-16, 15:45	+/–
на видео видно как автор через якобы багу загружает на сервер реверсивный пхп шел вот вам и удалённо, нет смысла обсуждать как он получил реверсивный шелл ибо это выходит за рамки самой уязвимости, а суть уязвимости в эскалации привилегий, он с правами www-data в итоге получил права root-а.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #44

44. Сообщение от тоже Аноним (ok), 18-Ноя-16, 16:26	+/–
Еще раз: если даже вы получили шелл с правами юзера шаред-хостинга - конкретно этот эксплойт вам не поможет поднять привилегии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #48

45. Сообщение от Аноним (-), 18-Ноя-16, 17:12	+3 +/–
Во-первых, отучайся говорить за всех. Это плохая привычка. Во-вторых, если бы syslog всех всем устраивал, что не появилось бы пачка альтернатив. В-третьих, syslog совершенно не устраивает многих админов в хайлоаде, например Сысоева. Сам нагуглить осилишь, почему он столько времени не хотел добавлять поддержку syslog в nginx?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #65

46. Сообщение от Аноним (-), 18-Ноя-16, 20:21	+/–
Проблемы debian разработчиков nginx не колышат, это только их проблемы - мы лучше будем контрибутить FreeBSD и Ubuntu с RHEL и SUSE
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #52

48. Сообщение от Sw00p aka Jerom (?), 18-Ноя-16, 23:44	+/–
я чёт не понял смысла вашего предложения. Конкретно эксплоит выполнится, если у вас такой же дебиан с теми же правами на логи и ротатором, и в случае получения шелла от имени того пользователя (будь хоть ссх шелл или пхп без разницыыыыы) позволит повысить права до рута - ФАКТ!!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #50

49. Сообщение от Sw00p aka Jerom (?), 18-Ноя-16, 23:46	–1 +/–
> nginx будет гадить логами. а суть в том, что сразу после сработки логротейта нджинкс не успеет нагадит в него, и эксплоит сразу же выполнит нужную ему команду ну как в примере сюидную какую нить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #51

50. Сообщение от тоже Аноним (ok), 19-Ноя-16, 00:15	+/–
> Директория с логами /var/log/nginx имеет владельца "www-data", что позволяет пользователю с данными полномочиями произвольно манипулировать файлами в данной директории. А юзеры на шареде - это не тот пользователь www-data, от имени которого запускается nginx на сервере шаред-хостинга. И у нормального хостера такой пользователь вообще не будет иметь внешнего шелла, ибо незачем. Вот и все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

51. Сообщение от angra (ok), 19-Ноя-16, 01:05	+/–
Походу, ты вообще не понял, как работает эта уязвимость. Дело не в logrotate, а в nginx и не играет никакой роли, запишет ли он что-либо в лог.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

52. Сообщение от angra (ok), 19-Ноя-16, 01:09	–3 +/–
Для танкистов повторяю, проблема не в debian, а в способе работы с логами в nginx. И проявится это может в любом другом дистре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #54

53. Сообщение от angra (ok), 19-Ноя-16, 01:24	+/–
Точно защищает? Проверял? А вот я взял образ centos 6 и проверил [root@Falcon /]# cd /var/log/nginx/ [root@Falcon nginx]# ls -al total 8 drwx------ 2 nginx nginx 4096 Nov 18 17:18 . drwxr-xr-x 3 root  root  4096 Nov 18 17:18 .. -rw-r--r-- 1 root  root     0 Nov 18 17:18 access.log -rw-r--r-- 1 root  root     0 Nov 18 17:18 error.log [root@Falcon nginx]# rm access.log rm: remove regular empty file `access.log'? y [root@Falcon nginx]# ln -s /etc/test access.log [root@Falcon nginx]# kill -USR1 734 [root@Falcon nginx]# ls -al total 8 drwx------ 2 nginx nginx 4096 Nov 18 17:20 . drwxr-xr-x 3 root  root  4096 Nov 18 17:18 .. lrwxrwxrwx 1 root  root     9 Nov 18 17:20 access.log -> /etc/test -rw-r--r-- 1 nginx root     0 Nov 18 17:18 error.log [root@Falcon nginx]# ls -al /etc/test -rw-r--r-- 1 nginx root 0 Nov 18 17:21 /etc/test [root@Falcon nginx]# cat /etc/issue CentOS release 6.8 (Final) Kernel \r on an \m
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #55, #57, #60

54. Сообщение от Аноним (-), 19-Ноя-16, 01:48	+3 +/–
Из за ваших детских болезней костыли в софт никто добавлять не собирается, если майнтейнер малолетнее ……
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

55. Сообщение от пет (?), 19-Ноя-16, 01:58	+/–
а центось это не рэдхэт)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #61

56. Сообщение от Аноним (-), 19-Ноя-16, 05:54	+/–
> Ну, на шаред-хостингах нгинкс обычно не может не быть Если у кого shared хостинг и логи нжинкса доступны всем подряд - как минимум это уже vuln поскольку атакующий может проводить наглейший data mining на ресурсах которые ему вообще не принадлежат, изучая чужих посетителей. Более того - если атакующий может что-то менять под www-data он скорее всего может раздестроить к чертям все сайты и например редиректнуть всю толпу на свой сайт, допустим с малварью или какой там еще фэйковой формой логина гмыл/втентакля/кого там еще по вкусу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #58

57. Сообщение от fi (ok), 19-Ноя-16, 12:08	+/–
а что с selinux?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

58. Сообщение от тоже Аноним (ok), 19-Ноя-16, 12:43	+/–
Поэтому?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

59. Сообщение от Savely Krasovsky (?), 20-Ноя-16, 01:01	+/–
В случае в дебианом там статично слинкована старая OpenSSL 1.0.1, которая не поддерживает ALPN для HTTP/2. Так что приходится собирать из исходников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #62

60. Сообщение от Stax (ok), 20-Ноя-16, 15:28	+/–
Эээ я прямо даже теряюсь. Вы слово "selinux" видите? Политика selinux по умолчанию targeted - она защищает конкретные демоны, для которых создана политика, а не произвольный программный код, запускаемый от пользователя (его тоже можно, но это требует сложного подхода и не разу ни из коробки). От пользователя у вас получится сделать все, что угодно (ps -Z - можете убедиться, что вы в контексте unconfined_t). Из nginx'а, работающего в другом контексте у вас эти операции проделать не получится. В nginx будет ошибка, в audit-логе - событие AVC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #63

61. Сообщение от Stax (ok), 20-Ноя-16, 15:29	+/–
> а центось это не рэдхэт) В данном контексте - они эквивалентны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

62. Сообщение от odd.mean (ok), 20-Ноя-16, 21:16	+/–
А вы на какой ветке (ветках)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

63. Сообщение от fi (ok), 21-Ноя-16, 13:42	+/–
> Эээ я прямо даже теряюсь. Вы слово "selinux" видите? > Политика selinux по умолчанию targeted - она защищает конкретные демоны, для которых > создана политика… Эээ я прямо даже теряюсь. Вы это видили?: Default SELinux policies on RHEL and Fedora protect against this flaw by limiting the files nginx's (uid 0) logging process can write to (httpd_log_t). Only systems running with `setenforce 0` or running nginx unconfined are vulnerable to privilege escalation. И так вопрос - selinux был включен?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #64

64. Сообщение от Stax (ok), 21-Ноя-16, 14:58	+/–
Какое отношение то, что вы написали имеет к командам шелла, выполненным выше (которые предположительно что-то там должны показывать)? Если процесс nginx в тесте не фигурирует, selinux с targeted-политикой не вмешивается в процесс вообще никак. Запустите nginx и посмотрите на вывод команд ps auxZ|grep nginx и ps auxZ|grep $$ наконец...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #66

65. Сообщение от XoRe (ok), 21-Ноя-16, 20:31	+1 +/–
> В-третьих, syslog совершенно не устраивает многих админов в хайлоаде, например Сысоева. > Сам нагуглить осилишь, почему он столько времени не хотел добавлять поддержку > syslog в nginx? Syslog - это понятие, обобщающее клиента, протокол и сервер. Насколько я понял, Сысоева не устраивал протокол syslog из за возможной потери пакетов и загрузка syslog сервера (syslogd): http://www.lexa.ru/nginx-ru/msg17262.html > Я тут имел несчастье наблюдать 130 сообщений в секунду через syslogd. > Машинка, конечно, не первой мододости, 2x P3-700, но отжирать при этом 12% > процессора только на чтение и запись сообщения - это слишком. Ну, во первых, с тех пор компьютеры стали чуть мощнее. Во вторых syslogd - не тот инструмент, которым надо ловить логи веб сервера. Тогда хотя бы можно было использовать syslog-ng. А сейчас для этого есть отличные связки вида Logstash+ElasticSearch+Kibana, или Statsd+Graphite, которые отлично обрабатывают 10k rps. Ну и на хайлоаде потеря пары пакетов не страшна, когда у тебя нагрузка 1к rps. Так что syslog на хайлоаде - вещь хорошая, только её нужно правильно приготовить. Отправка логов по сети помогает разгрузить сервер - ему не нужно тратиться на дисковый I/O.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

66. Сообщение от fi (ok), 23-Ноя-16, 01:14	+/–
> Если процесс nginx в тесте  не фигурирует, selinux с targeted-политикой не вмешивается в процесс вообще никак. а какой процесс по вашему фигурирует тут? > [root@Falcon nginx]# kill -USR1 734 Прямо детский сад. зы. "selinux с targeted-политикой" следит и за пользовательскими процессами, by ex: >  SELinux is preventing /usr/lib64/firefox/plugin-container from sendto access on the unix_dgram_socket @nvidia9dc15530.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #67

67. Сообщение от Stax (ok), 23-Ноя-16, 15:10	+/–
> а какой процесс по вашему фигурирует тут? bash, ls, ln, kill (впрочем, тк не /usr/bin/kill, тот же bash), cat. Сделайте на бинарники ls -lZ и убедитесь, что это unconfined_t Но дело даже совсем не в этом. Даже если *был бы* контекст и selinux что-то им запрещал - это был бы *совершенно другой* контекст, чем у nginx (впрочем, в этом случае ls -Z не показал бы всей правды - нужно смотреть через selinuxexeccon, что во что может перейти, а что во что не может). Поэтому данный тест не имеет смысла по определению для выяснения вопроса "влияет selinux на nginx или нет". Если вы не верите умению читать политику selinux, реальный тест можно провести только из самого приложения. Ну или сделайте себе копию /bin/bash, через chcon поставьте на нее контекст как у nginx, запустите (убедитесь через ps -Z, что в нужном контексте) и оттуда уже делайте ваш эксперимент. Если вообще дадут запустить. > зы. "selinux с targeted-политикой" следит и за пользовательскими процессами, by ex: *фейспалм* $ ls -lZ /usr/lib64/firefox/plugin-container -rwxr-xr-x. 1 root root system_u:object_r:mozilla_plugin_exec_t:s0 279824 ноя 15 01:47 /usr/lib64/firefox/plugin-container Ну логично, что. Конечно, selinux следит и за не-рутовыми процессами (которые формально пользовательские - пусть и не всегда того пользователя, который залогинен). Не надо придираться, я имел ввиду совсем не это. Когда вы дергаете из консоли утилиты общего назначения, ни на что из них политика не распространяется, вот и все. Несколько хитрых штук типа plugin-container являются исключениями, но это очень редкие случаи, да и помощи там от selinux с точки зрения практической безопасности не так много. Лично от меня сейчас в контексте, отличном от unconfined_t выполняются только Xorg и dbus-daemon.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #68

68. Сообщение от fi (ok), 23-Ноя-16, 18:08	+/–
>> а какой процесс по вашему фигурирует тут? > kill о боже! вы не знаете что делает "kill"??? посылает сигнал процессу nginx который в нужном контексте  - это же очевидно!!! «Управление nginx: USR1    переоткрытие лог-файлов» зы2 > Когда вы дергаете из консоли утилиты общего назначения, ни на что из них политика не распространяется смотрим: -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xvinfo -rwxr-xr-x. root root    system_u:object_r:xserver_exec_t:s0 Xvnc -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xwininfo -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xxd -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xxkb -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xz lrwxrwxrwx. root root    system_u:object_r:bin_t:s0       xzcat -> xz lrwxrwxrwx. root root    system_u:object_r:bin_t:s0       xzcmp -> xzdiff -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xzdec -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xzdiff lrwxrwxrwx. root root    system_u:object_r:bin_t:s0       xzegrep -> xzgrep lrwxrwxrwx. root root    system_u:object_r:bin_t:s0       xzfgrep -> xzgrep -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xzgrep -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xzless -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       xzmore -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yacc -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yelp -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yes lrwxrwxrwx. root root    system_u:object_r:bin_t:s0       ypdomainname -> hostname -rwxr-xr-x. root root    system_u:object_r:rpm_exec_t:s0  yum -rwxr-xr-x. root root    system_u:object_r:rpm_exec_t:s0  yum-builddep -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yum-config-manager -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yum-debug-dump -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yum-debug-restore -rwxr-xr-x. root root    system_u:object_r:bin_t:s0       yumdownloader как видете у всех есть своя политика! И можно даже подкрутить права для них :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #69

69. Сообщение от Stax (ok), 23-Ноя-16, 19:47	+1 +/–
> о боже! вы не знаете что делает "kill"??? посылает сигнал процессу nginx который в нужном контексте  - это же очевидно!!! > «Управление nginx: USR1    переоткрытие лог-файлов» Ну тут уж прямо без комментариев. Вы новость вообще читали? В чем уязвимость, смотрели? Из-за прав на каталог, принадлежащих nginx, можно сделать манипуляцию из кода, выполняющегося из под nginx с правами www-data (напр cgi и прочему). В редхате политика selinux БЛОКИРУЕТ данную возможность. Нельзя из под nginx ничего там делать. Только логгер с правами рута может туда что-то писать и что-то менять, а обычный код, выполняющийся из-под nginx с правами www-data - не может. Хотя по привилегиям возможно, как и в дебиане, но selinux блокирует. Что вы пытаетесь показать этим бессмысленным тестом, создавая симлинк из-под рута, я не понимаю. Разумеется, selinux не распространяется на команду ln из рутового шелла. И дает вам это сделать. Но предполагаемый реальный вектор атаки - блокируется. А kill тут вообще не при чем. Для вашего эксперимента с симлинком вы УЖЕ рут - да, имея права рута, можно подготовить систему так, чтобы эта "уязвимость" проявилась в nginx несмотря на selinux. Только это не имеет отношения к реальности, т.к. для демонстрации повышения привилегий вы выполняете злонамеренные действия из рута. > как видете у всех есть своя политика! И можно даже подкрутить права для них :) Если вы рут - можете вообще все, что угодно делать, крутите что хотите. Политика - ну откройте-таки доки по selinux и посмотрите, что такое bin_t и как это используется.. Если не понимаете - ну запустите любую из утилит выше (yes или там xz удобно, они сами не завершатся) и посмотрите ps'ом ее контекст во время выполнения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #70

70. Сообщение от fi (ok), 24-Ноя-16, 10:41	+/–
> Что вы пытаетесь показать этим бессмысленным тестом, Вы точно уверенны что это был я???  я всего лишь спросил автора теста - был ли при этом selinux, а вы возбудились не по-детски. и нагородили при этом какую-то кашу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #71

71. Сообщение от Stax (ok), 25-Ноя-16, 15:09	+/–
Да неважно, кто. Я, кстати, тоже оригинальному автору писал, да что-то в моем комментарии вам не понравилось. И зачем вы пытаетесь доказать, что selinux имел какое-то отношение к тому тесту - когда даже при активной политике на nginx, защищающей от уязвимости, в текущем виде он не может продемонстрировать ровным счетом ничего - понять не могу! Вопрос "был ли там включен selinux" (думаю, ответ "да") просто нерелевантен, это ни на что не влияет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

73. Сообщение от Виктор (??), 16-Май-20, 20:34	+/–
Я мучую детей в школе.
Ответить | Правка | Наверх | Cообщить модератору

74. Сообщение от Виктор (??), 16-Май-20, 20:36	+/–
Stax лучше бы ты сосал
Ответить | Правка | Наверх | Cообщить модератору

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

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема