forum.opennet.ru - "Уязвимость в Docker, связанная с предоставление доступа к /p..." (119)

"Уязвимость в Docker, связанная с предоставление доступа к /p..."

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

"Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
Сообщение от opennews (??), 20-Авг-18, 10:07
Раскрыты (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10892) сведения об уязвимости (https://github.com/moby/moby/pull/37404) (CVE-2018-10892 (https://security-tracker.debian.org/tracker/CVE-2018-10892)) в инструментарии управления контейнерами Docker. Проблема вызвана тем, что Docker не фильтрует из отображаемого внутри контейнеров пространства /proc подкаталог /proc/acpi, что позволяет из контейнера изменять режимы работы оборудования, например, включать и выключать Bluetooth (echo "enable" >/proc/acpi/ibm/bluetooth), активировать подсветку клавиатуры (echo 2 >/proc/acpi/ibm/kbdlight) и т.п. Дистрибутивы с appArmor (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-10892) и SELinux (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10892), включенном в режиме "enforcing", эффективно блокируют данную проблему. URL: https://access.redhat.com/errata/RHSA-2018:2482 Новость: https://www.opennet.ru/opennews/art.shtml?num=49157
Ответить \| Правка \| Cообщить модератору

Оглавление

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (1), 10:07 , 20-Авг-18, (1) +3

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (-), 11:13 , 20-Авг-18, (11) +15

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (17), 11:34 , 20-Авг-18, (17)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Ivan_83 (ok), 13:26 , 20-Авг-18, (46)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Anonymouss (?), 16:33 , 20-Авг-18, (61) +3

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (-), 11:41 , 20-Авг-18, (20) +20
Уязвимость в Docker, связанная с предоставление доступа к /p..., anonymous (??), 16:14 , 20-Авг-18, (58)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (59), 16:18 , 20-Авг-18, (59) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (-), 17:33 , 20-Авг-18, (65) –1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 18:04 , 20-Авг-18, (66) +6

Уязвимость в Docker, связанная с предоставление доступа к /p..., лютый охохоня (?), 07:28 , 21-Авг-18, (85)

Уязвимость в Docker, связанная с предоставление доступа к /p..., шухер (?), 20:43 , 20-Авг-18, (73) +3
Уязвимость в Docker, связанная с предоставление доступа к /p..., Michael Shigorin (ok), 23:23 , 21-Авг-18, (119) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноний (?), 18:20 , 20-Авг-18, (67) +1
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (110), 17:33 , 21-Авг-18, (110) –2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Wladmis (ok), 19:51 , 21-Авг-18, (111) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Michael Shigorin (ok), 23:21 , 21-Авг-18, (118) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., имя (?), 11:13 , 20-Авг-18, (12) –1
Уязвимость в Docker, связанная с предоставление доступа к /p..., Харитон (?), 13:21 , 20-Авг-18, (45)

Уязвимость в Docker, связанная с предоставление доступа к /p..., ОМЖ (?), 01:08 , 22-Авг-18, (126) –1

Уязвимость в Docker, связанная с предоставление доступа к /p..., SysA (?), 14:07 , 20-Авг-18, (50)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (2), 10:21 , 20-Авг-18, (2) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., SysA (?), 15:31 , 21-Авг-18, (104)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 10:36 , 20-Авг-18, (4) +4

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (5), 10:41 , 20-Авг-18, (5)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (7), 10:54 , 20-Авг-18, (7) +5
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (17), 11:36 , 20-Авг-18, (18) –2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (59), 16:21 , 20-Авг-18, (60) +4
Уязвимость в Docker, связанная с предоставление доступа к /p..., Michael Shigorin (ok), 23:25 , 21-Авг-18, (120) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., lxc (?), 14:14 , 20-Авг-18, (52) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Некто (??), 10:41 , 20-Авг-18, (6)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 11:16 , 20-Авг-18, (13) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (22), 11:51 , 20-Авг-18, (22)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 11:59 , 20-Авг-18, (27) –2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (22), 12:02 , 20-Авг-18, (28) +3

Уязвимость в Docker, связанная с предоставление доступа к /p..., ABATAPA (ok), 08:39 , 21-Авг-18, (87) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Michael Shigorin (ok), 23:27 , 21-Авг-18, (121) +3

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (-), 12:04 , 20-Авг-18, (29) +8

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (8), 10:56 , 20-Авг-18, (8)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Ага (?), 10:58 , 20-Авг-18, (9) +4

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (22), 11:52 , 20-Авг-18, (23)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Ага (?), 13:46 , 20-Авг-18, (49) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (56), 15:02 , 20-Авг-18, (56)

Уязвимость в Docker, связанная с предоставление доступа к /p..., имя (?), 15:29 , 20-Авг-18, (57)

Уязвимость в Docker, связанная с предоставление доступа к /p..., нах (?), 13:05 , 20-Авг-18, (42) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., имя (?), 11:57 , 21-Авг-18, (92) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 12:13 , 21-Авг-18, (95) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., имя (?), 13:11 , 21-Авг-18, (96)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 14:07 , 21-Авг-18, (100) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., имя (?), 15:38 , 21-Авг-18, (105)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 16:35 , 21-Авг-18, (108) +2
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 16:44 , 21-Авг-18, (109) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., ОМЖ (?), 01:13 , 22-Авг-18, (127)

Уязвимость в Docker, связанная с предоставление доступа к /p..., лютый охохоня (?), 13:19 , 21-Авг-18, (97)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 14:03 , 21-Авг-18, (99)

Уязвимость в Docker, связанная с предоставление доступа к /p..., лютый охохоня (?), 07:24 , 23-Авг-18, (135)

Уязвимость в Docker, связанная с предоставление доступа к /p..., лютый охохоня (?), 13:22 , 21-Авг-18, (98)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 14:10 , 21-Авг-18, (101)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Тьфу (?), 15:08 , 21-Авг-18, (102)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (66), 15:26 , 21-Авг-18, (103) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Тьфу (?), 16:07 , 21-Авг-18, (107) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., topin89 (?), 21:30 , 23-Авг-18, (137)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (10), 10:58 , 20-Авг-18, (10) +1
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноняшка (?), 11:20 , 20-Авг-18, (14) +8
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (17), 11:23 , 20-Авг-18, (15) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., нах (?), 12:57 , 20-Авг-18, (39)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Anonymus (?), 10:40 , 21-Авг-18, (89) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., SysA (?), 13:34 , 20-Авг-18, (47) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (17), 11:26 , 20-Авг-18, (16)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (21), 11:44 , 20-Авг-18, (21)

Уязвимость в Docker, связанная с предоставление доступа к /p..., anonymous (??), 11:58 , 20-Авг-18, (26) +8

Уязвимость в Docker, связанная с предоставление доступа к /p..., anonymous (??), 11:57 , 20-Авг-18, (24) +1
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (-), 11:58 , 20-Авг-18, (25) +7

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (71), 20:29 , 20-Авг-18, (71) +6

Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 20:43 , 21-Авг-18, (116)

Уязвимость в Docker, связанная с предоставление доступа к /p..., имя (?), 11:36 , 20-Авг-18, (19)
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (41), 13:04 , 20-Авг-18, (41) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., нах (?), 13:08 , 20-Авг-18, (43) +3
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (-), 13:15 , 20-Авг-18, (44) –2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (51), 14:12 , 20-Авг-18, (51)
Уязвимость в Docker, связанная с предоставление доступа к /p..., anonymous (??), 14:42 , 20-Авг-18, (54)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Animemous (?), 19:15 , 20-Авг-18, (68)
Уязвимость в Docker, связанная с предоставление доступа к /p..., mikhailnov (ok), 23:11 , 20-Авг-18, (76)
Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (77), 23:56 , 20-Авг-18, (77) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., нах (?), 14:46 , 20-Авг-18, (55) +3
Уязвимость в Docker, связанная с предоставление доступа к /p..., Michael Shigorin (ok), 23:33 , 21-Авг-18, (122)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Alex_hha (?), 16:45 , 20-Авг-18, (62)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (64), 17:22 , 20-Авг-18, (64) +3
Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 20:21 , 20-Авг-18, (70) +2

Уязвимость в Docker, связанная с предоставление доступа к /p..., Gemorroj (ok), 21:03 , 20-Авг-18, (74)

Уязвимость в Docker, связанная с предоставление доступа к /p..., DevOps (?), 23:57 , 20-Авг-18, (78) –1
Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 20:39 , 21-Авг-18, (115) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., ALex_hha (ok), 00:07 , 21-Авг-18, (79) +3

Уязвимость в Docker, связанная с предоставление доступа к /p..., DevOps (?), 00:11 , 21-Авг-18, (80)
Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 07:44 , 21-Авг-18, (86)

Уязвимость в Docker, связанная с предоставление доступа к /p..., ALex_hha (ok), 11:00 , 21-Авг-18, (90) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 20:07 , 21-Авг-18, (113) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., ALex_hha (ok), 11:02 , 21-Авг-18, (91) –4

Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 20:21 , 21-Авг-18, (114) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., ALex_hha (ok), 23:53 , 21-Авг-18, (124)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Michael Shigorin (ok), 23:38 , 21-Авг-18, (123) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., ALex_hha (ok), 09:02 , 22-Авг-18, (129) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., anonymous (??), 12:01 , 22-Авг-18, (131)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Alex_hha (?), 13:52 , 22-Авг-18, (133)

Уязвимость в Docker, связанная с предоставление доступа к /p..., angra (ok), 23:45 , 22-Авг-18, (134) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., ALex_hha (ok), 12:22 , 23-Авг-18, (136)

Уязвимость в Docker, связанная с предоставление доступа к /p..., anonymous (??), 11:55 , 22-Авг-18, (130)

Уязвимость в Docker, связанная с предоставление доступа к /p..., Alex_hha (?), 16:47 , 20-Авг-18, (63) +1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (72), 20:30 , 20-Авг-18, (72) –1

Уязвимость в Docker, связанная с предоставление доступа к /p..., Аноним (84), 03:34 , 21-Авг-18, (84) +3

Уязвимость в Docker, связанная с предоставление доступа к /p..., пох (?), 21:52 , 21-Авг-18, (117) +2

Уязвимость в Docker, связанная с предоставлением доступа к /..., ПавелС (ok), 09:20 , 21-Авг-18, (88) +1

Уязвимость в Docker, связанная с предоставлением доступа к /..., Ant (??), 12:09 , 21-Авг-18, (93)

Уязвимость в Docker, связанная с предоставлением доступа к /..., Аноним (94), 12:12 , 21-Авг-18, (94) +2

Уязвимость в Docker, связанная с предоставлением доступа к /..., anonymous (??), 15:48 , 21-Авг-18, (106)

Уязвимость в Docker, связанная с предоставлением доступа к /..., пох (?), 20:04 , 21-Авг-18, (112) +1
Уязвимость в Docker, связанная с предоставлением доступа к /..., ALex_hha (ok), 00:14 , 22-Авг-18, (125) +1

Уязвимость в Docker, связанная с предоставлением доступа к /..., Аноним (72), 04:26 , 22-Авг-18, (128)

Уязвимость в Docker, связанная с предоставлением доступа к /..., Alex_hha (?), 13:44 , 22-Авг-18, (132)

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

1. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от Аноним (1), 20-Авг-18, 10:07

Epic Fail товарищи

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +15 +/–

Сообщение от Аноним (-), 20-Авг-18, 11:13

Контейнеры... Изоляция... LOL.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

17. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (17), 20-Авг-18, 11:34

>>Контейнеры... Изоляция... LOL.
Так недавно ж снова всплыла уязвимость в процессорах (Foreshadow), ставящая под угрозу безопасность vps и облачных хостингов.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

46. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Ivan_83 (ok), 20-Авг-18, 13:26

Так с интела пора валить.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

61. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от Anonymouss (?), 20-Авг-18, 16:33

На докер, да.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

20. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +20 +/–

Сообщение от Аноним (-), 20-Авг-18, 11:41

> Контейнеры... Изоляция... LOL.
The 's' in Docker stands for security!

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

58. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от anonymous (??), 20-Авг-18, 16:14

Контейнер != изоляция. Docker контейнер, но без изоляции.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

59. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Аноним (59), 20-Авг-18, 16:18

какой смысл тогда в контейнере? вот у vz и изоляция, и контейнеры настоящие.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

65. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –1 +/–

Сообщение от Аноним (-), 20-Авг-18, 17:33

> какой смысл тогда в контейнере? вот у vz и изоляция, и контейнеры настоящие.
И где все ваши vz, zones, jails?
Теоретические академподелки, не приспособленные для продакшена, хайлода в кластерах на кубернете с битчейном, вымерли естественным путем, как динозавры и остались лишь у немногих надутых гусей и ветеран-админов!

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

66. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +6 +/–

Сообщение от Аноним (66), 20-Авг-18, 18:04

А docker прямо приспособлен к прудукшену по самые помидоры! Щаз: https://habr.com/post/346430 . Агрессивной рекламой запудрили мозг умам неокрепшим, пока поймут, что этот docker-фуфел чистейшей воды, пройдёт время. И да, jail-ы и zone-ы где надо, во-первых, как раз используются, во вторых, только они и используются. Но фанатам docker-a об этом неизвестно ибо таковых к тем системам на пушечный выстрел не подпускают, не доросли ещё.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

85. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от лютый охохоня (?), 21-Авг-18, 07:28

Докер используют в основном для шедулинга ресурсов тысяч серверов, например одноглазики ру, а изоляция там особо не нужна. ОпенВЗ на дешёвых впс тарифах приплетать не надо, оно совсем для другого

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

73. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от шухер (?), 20-Авг-18, 20:43

OpenVZ используется тучей хостеров vds/vps
Выходите из погреба.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

119. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:23

> Теоретические академподелки, не приспособленные для продакшена
Смотрите, люди, на "практика".  Он-то наверняка знает уш-у, карате и много других страшных слов.  Вот только не сечёт ни хрена в том, что несёт, но это ведь и не важно...

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

67. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноний (?), 20-Авг-18, 18:20

Переносимость. Изоляция часто мешает, например без танцев с бубнов нельзя получить доступ к файлам.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

110. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –2 +/–

Сообщение от Аноним (110), 21-Авг-18, 17:33

давайте вы не будете раскатывать о VZ который по сути прослойка поверх namespace + cgroups..

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

111. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Wladmis (ok), 21-Авг-18, 19:51

> давайте вы не будете раскатывать о VZ который по сути прослойка поверх namespace + cgroups..
Во-первых, VZ появился задолго до namespaces+cgroups, во-вторых, Parallels хорошо законтрибьютила в развитие этих самых namespaces для того, чтобы уменьшить объём патч-сета на ядро, которое каждый релиз довольно-таки сложно заредиффить, и побольше использовать нативные ядерные механизмы изоляции, в-третьих, патч-сет на современные VZ-ядра всё ещё внушительный, и там много как раз про настоящую изоляцию.

Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

118. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:21

> Контейнеры... Изоляция... LOL.
Ну покажите мне такое на openvz.  А дыркер -- он и есть дыркер.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –1 +/–

Сообщение от имя (?), 20-Авг-18, 11:13

Container Linux by CoreOS stable (1800.5.0)
$ docker exec -it d911de0408c3 /bin/ash
/ # ls -la /proc/acpi/
total 0
dr-xr-xr-x    2 root     root             0 Aug 20 08:09 .
dr-xr-xr-x   99 root     root             0 Jul 31 15:37 ..
-rw-r--r--    1 root     root             0 Aug 20 08:09 wakeup
/ # cat /proc/acpi/wakeup
Device    S-state      Status   Sysfs node
/ #

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

45. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Харитон (?), 20-Авг-18, 13:21

Epic Fail тем, кто при настройке cервера отключает SeLinux.
Изучить как им пользоваться видать собственная важность запрещает.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

126. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –1 +/–

Сообщение от ОМЖ (?), 22-Авг-18, 01:08

я отключаю.
селинукс сложный.
домен-роль-тип-контекст, чегобль, не ну наx

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

50. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от SysA (?), 20-Авг-18, 14:07

Ну, да! Не понятно только почему она в мини... :)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Аноним (2), 20-Авг-18, 10:21

in the word Docker `s` letter means security!
P.S. уязвимость раскрыта на прошлой неделе, с разморозочкой

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

104. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от SysA (?), 21-Авг-18, 15:31

Вообще-то в начале прошлого месяца!.. :)

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +4 +/–

Сообщение от Аноним (66), 20-Авг-18, 10:36

Кто просветит, почему всегда качественные системы уходят в забвение, а всякое дерьмо вроде docker-а занимает рынок и приобретает кучу фанатичных поколонников? Все мухи?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (5), 20-Авг-18, 10:41

> качественные системы
какие?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +5 +/–

Сообщение от Аноним (7), 20-Авг-18, 10:54

BeoS

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

18. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –2 +/–

Сообщение от Аноним (17), 20-Авг-18, 11:36

Знавал чела, который на полном серьезе считал "качественным аналогом" докера OpenVZ =)) Еще и админом в небольшом воронежском банке при этом работал.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

60. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +4 +/–

Сообщение от Аноним (59), 20-Авг-18, 16:21

OpenVZ - аналог Docker'а? Это он отжог! У OpenVZ изоляция настоящая.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

120. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:25

> Знавал чела, который на полном серьезе считал "качественным аналогом" докера OpenVZ =))
> Еще и админом в небольшом воронежском банке при этом работал.
Так он, поди, какой-нить мехмат ВГУ кончал, а не факультет словоблудия.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

52. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от lxc (?), 20-Авг-18, 14:14

LXC?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Некто (??), 20-Авг-18, 10:41

что по вашему качественная система, peacemaker ?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Аноним (66), 20-Авг-18, 11:16

Solaris Zone

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

22. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (22), 20-Авг-18, 11:51

И чем оно лучше докера? Чем армяне? Вроде бы нет, потому что соплярис больше никому не нужен, кроме терпил, посаженных на иглу 20 лет назад.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

27. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –2 +/–

Сообщение от Аноним (66), 20-Авг-18, 11:59

Потому что просто работает, стабильно и на любой нагрузке, а не падает, глючит и сыпется как docker.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

28. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от Аноним (22), 20-Авг-18, 12:02

Ай да шутник, и где же оно у тебя работает? В Серьёзном Бизнесе? Где 96 вычислительных ядер занимают шкаф размером с советский платяной шкаф?

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

87. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от ABATAPA (ok), 21-Авг-18, 08:39

Вот про шкаф Вы зря. Старые шкафы, бывает, уже лет 50 живут, на них могут прыгать четверо детей или двое взрослых, и им ничего не будет. Дверцы на сплошных петлях не отвисают за те самые полвека, дети на них вообще катались. А сейчас? Всё из опилок, чуть надавишь — шканты вылетают с мясом.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

121. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:27

> Вот про шкаф Вы зря. Старые шкафы, бывает, уже лет 50 живут
Это чудо, поди, не видело советских холодильников.  Которые по те же полвека не просто живут, а *работают*.
Поколение "купил-выбросил-купил", будь оно неладно, способно только всё вокруг себя загаживать одноразовыми "вещами" -- неважно, делает оно их тяп-ляп или так же себе под стать и подбирает.
Тьфу, противно.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

29. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +8 +/–

Сообщение от Аноним (-), 20-Авг-18, 12:04

> Вроде бы нет, потому что соплярис больше никому не нужен, кроме терпил, посаженных на иглу 20 лет назад.
А паровые турбины не лучше электровелосипеда, потому что паровозы больше никому не нужны, а вот велосипеды совсем наоборот!
Альтернативная логика фанатов видна во всей красе.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

8. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (8), 20-Авг-18, 10:56

Решил я как-то перевести прод на докер. 10 минут потыкал что-то там и все готово. Выглядит удобно и чистенько. Безопасность - как минимум не хуже чем было до этого, а во многих местах - лучше.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +4 +/–

Сообщение от Ага (?), 20-Авг-18, 10:58

А вы уже пробовали, на своем севрере блютуз выключать ? на моем что то не срабатывает, может блютуза нет

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

23. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (22), 20-Авг-18, 11:52

У тебя докер притянул в зависимостях блютуз, и ты больше не можешь без блютуза работать?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

49. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Ага (?), 20-Авг-18, 13:46

ДА! Уже заказал трансфер донгла в ДЦ, чортов докер не заводится :(

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

56. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (56), 20-Авг-18, 15:02

> А вы уже пробовали, на своем севрере блютуз выключать ? на моем что то не срабатывает, может блютуза нет
А кроме блютуза там ничего больше нет? Ни fan, ни cpu/, ни /sleep?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

57. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от имя (?), 20-Авг-18, 15:29

А вы проверьте сами. Я ничего из этого не нашёл.
Только wakeup и PCI0:
root@c8b0390d3ce6:/# cat /proc/acpi/wakeup
Device    S-state      Status   Sysfs node
PCI0      S5    *disabled  no-bus:pci0000:00
и так выключен. Включение ничего не меняет:
root@c8b0390d3ce6:/# echo PCI0 > /proc/acpi/wakeup
root@c8b0390d3ce6:/# cat /proc/acpi/wakeup
Device    S-state      Status   Sysfs node
PCI0      S5    *enabled   no-bus:pci0000:00
host centos 6.9 на HP ProLiant DL360 G5
# /sbin/lspci
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1)
...

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

42. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от нах (?), 20-Авг-18, 13:05

качественные - сложный дизайн, языки программирования для взрослых, часто надо заплатить денег за удовольствие почитать документацию (не говоря уже про пользоваться). Настраивать простые вещи сложно, надо понимать что делаешь, сложные - примерно так же, но до сложных немногие доходят.
А всякое дерьмо - любая обезьянка, кое-как научившаяся новому-модному язычку, может принять участие в разработке. Любой деврукиизопс- может осилить docker run, а то и compose.
Ну и имеем, что имеем. А sun - банкрот.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

92. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от имя (?), 21-Авг-18, 11:57

>Настраивать простые вещи сложно
действительно, почему же ими не пользуются?
красноглaзие для фана - это иногда полезно
красноглaзие на продакшене - это диагноз.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

95. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (66), 21-Авг-18, 12:13

Чудес на свете не бывает, простых решений для сложных задач тоже, это всё сказки для мелочи пузатой, докеры админящей. Поэтому, с шелухой всякой сваггерной возиться дозволяют докерной мелочи, а для работы с террабайтными rdbms зовут васю-админа соляры, а для работы с тем шкафом от междельмаша, прокручиваующем финтранзакци на лярды в сутки, вообще зовут семидесятилетнего cobol-иста https://habr.com/post/403037/.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

96. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от имя (?), 21-Авг-18, 13:11

ответ один - легаси.
У миноборны США до сих пор в строю остались компьютеры из 70-х, вы же не кажете, что они лучше современных?

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

100. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (66), 21-Авг-18, 14:07

Один вопрос: в мире клепается тонны кода для всякой вебни на сваггерах, голынгах и прочих докерах. Если так просто взять и просто решить сложные вещи, то почему любители смузи не клепанут кучу софта, который бы мог обрабатывать миллионы транзакций? анагеры будут только рады. Оно ведь потому легаси везде и держится, потому что замениить нечем. То что наклёпано любителями простоты-работать не будет. Оно работатет только на локалхосте у докерщиков.

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

105. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от имя (?), 21-Авг-18, 15:38

не переписывается по нескольким причинам:
1. работает? не трожь.
2. как оно работает? не трожь.
контейнеры удобны тем, что есть конфиг и настроенное окружение, в котором гарантированно будет работать приложение, на какмо бы железе оно не запустилось (не берем, конечно, в расчет ассемблеры)

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

108. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Аноним (66), 21-Авг-18, 16:35

>>контейнеры удобны тем, что есть конфиг и настроенное окружение, в котором гарантированно будет >>работать приложение, на какмо бы железе оно не запустилось (не берем, конечно, в расчет ассемблеры)
В случае с докером-это объявлено в рекламных буклетах. В реальности же оно совсем не так, работоспособность докера сильно зависит от железа, ОС, системных либ. Чуть в сторону-ловишь странные глюки. И вообще мелких недоделок и багов в докере куча, докер просто лидрует по их количеству в сравнении с другим софтом.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

109. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от Аноним (66), 21-Авг-18, 16:44

Разрабы же докера-это особый прикол. Чаще всего они тупо игнорируют репорты, не заводят баги и даже не удосуживаются проверить что-то. Самый частый их ответ-ставить какую-то версию убунты, на которой такая-то бага не воспроизводится. Конечно, взять такую версию убунты, запустить на ней, и некоторой баги действительно уже не будет, только в этом случае уже речи быть не может о наличии в докере тех фич, о которых так кричат докерные буклеты.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

127. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от ОМЖ (?), 22-Авг-18, 01:13

ответ прост до безобразия: а кто и сколько мне за это заплатит?

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

97. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от лютый охохоня (?), 21-Авг-18, 13:19

В банках транзакции обрабатывают не реляционные СУБД, по крайней мере в современных как например сбербанг ,)

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

99. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (66), 21-Авг-18, 14:03

А что там обрабатывает? Уж не не то ли поделие на gridgain+hadoop, которое сбертех пилил и проект которого недавно был признан провальным. OLTP  у них на оракеле,  и будет так, пока сам оракел не перекроет поставки.

Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

135. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от лютый охохоня (?), 23-Авг-18, 07:24

Кем признан провальным? Экспертами опеннета? Я так тоже могу наплести что у сбера от оракле только железо и легаси, а процессинг в жабе. И доказывал что не верблюд ,)

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

98. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от лютый охохоня (?), 21-Авг-18, 13:22

Если где-то стоит в продакшоне шкаф снятый с поддержки вендором, это признак болота загнившего. Шкафы от междельмаша уже давно проиграли бой

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

101. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (66), 21-Авг-18, 14:10

Скажите это амерканцам, у которых эти шкафы обрабатывают 80% всех финтранзакций, и заменить-то нечем. Тазики с убунтой попадают в первые же секунды той нагрузки.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

102. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Тьфу (?), 21-Авг-18, 15:08

Шкафы стоят потому что софт, который на них крутиться слишком старый и работает только на этих шкафах. Софт старый и переписать некому, многие разработчики уже померли или с деменцией дружат крепко.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

103. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (66), 21-Авг-18, 15:26

>>Софт старый и переписать некому
Как так, а где та куча некрасноглызых, умеющих делать просто, с голынгом и докером наперевес? Локалхост админять?

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

107. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Тьфу (?), 21-Авг-18, 16:07

Аппаратно-программная платформа на базе COBOL, еще вопросы есть?
Принцип: "работает - не трогай", а в последнее время и трогать особо не кому, вот и получается черный ящик. Можно еще ради интереса поискать вакансии для программистов на Cobol...

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

137. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от topin89 (?), 23-Авг-18, 21:30

Вопрос риторический, конечно, но я всё равно отвечу:
1. Херовое продвижение. Пример: BeOS. Отличная во всех отношениях операционка, но её пытались продавать дуалбутом с Виндой, причём Винда загружалась по-умолчанию. Куча людей тупо никогда её не видела
2. Именитые конкуренты. Pebble: часы были неплохими, но за брендами вроде Apple или Samsung им было не угнаться
3. Легальные проблемы. (Free|Net|Open)BSD: Операционки были и остаются нормальными, но из-за исков AT&T по Unix в целом многие начали развивать Linux, чтобы избежать легальных проблем. Это не помогло, но когда на Linux начались нападки юристов, большинство верили, что шансов выиграть больше, чем у FreeBSD.
4. Наследие прошлого. Windows: сейчас это пристойная операционка, глюки которой довольно редки и начинается процесс интеграции POSIX-плюшек (например, уже есть аналог UNIX-сокетов). Но вспоминать её как эталон глючности будут ещё долго.
5. Субъективность оценки. systemd: какие бы не были у него достоинства, её будут считать отстоем по причине не UNIX-way, личности создателя, откровенному навязыванию и другими нетехническими вещами.
6. Неудобство/сложность. Ручная коробка передач: по всем параметрам надёжности, простоты исполнения, ремонтопригодности и цены она уделывает автомат. Но она активно вытесняется потому что автомат гораздо удобнее и проще в использовании.
7. Вытеснение новыми технологиями. ЭЛТ: к концу своего развития они были очень хороши: приличные диагонали(для того времени), хорошая частота развёртки, хорошая цветопередача. Когда LCD появлялись, они все их характеристики были говном, включая надёжность и цену. Время шло, техника развивалась, и где теперь ЭЛТ?
Может, ещё что-то, не знаю.
Docker -- это тот самый LCD-монитор. Он говно полное на данный момент, но он очень удобен для задач быстрой единообразной развёртки и борьбы с тоннами зависимостей. Ну серьёзно,
docker pull x && docker run x
гораздо быстрее весёлой возни с тоннами конфигов, отличающихся от системы к системе, от версии к версии и железа к железу. Технические недостатки преодолеют, пользоваться станут почти все, но по старой памяти продолжат называть кучей кала.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (10), 20-Авг-18, 10:58

Удобно для хостера, удобно для клиента. Только надо помнить, что ничего важного там держать не следует.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +8 +/–

Сообщение от Аноняшка (?), 20-Авг-18, 11:20

Банально, включая и выключая блютус, можно "морзянкой", по нескольку байт в минуту, "сливать" пароли, куки, /etc/shadow....

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (17), 20-Авг-18, 11:23

>>включать и выключать Bluetooth
>>активировать подсветку клавиатуры
Очень актуально для серверов, да.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от нах (?), 20-Авг-18, 12:57

> Очень актуально для серверов, да.
а это смотря чего-серверов и из чего.
Как тебе такая красота:
# apt-get -s remove bluez
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
[неважно]
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  bluez:i386 bluez-alsa:i386 dh-python libcgmanager0:i386 libdb5.3:i386
  libdbus-1-3 libdbus-1-3:i386 libexpat1 libexpat1:i386 libexpat1-dev liblzma5
  liblzma5:i386 libnih-dbus1:i386 libnih1:i386 libpython3-stdlib:i386
  libpython3.4-minimal:i386 libpython3.4-stdlib:i386 libreadline6
  libreadline6:i386 libudev1 libudev1:i386 mime-support python3:i386
  python3-dbus:i386 python3-minimal:i386 python3.4:i386 python3.4-minimal:i386
Suggested packages:
  bluez-hcidump:i386 python3-doc:i386 python3-tk:i386 python-dbus-doc:i386
  python3-dbus-dbg:i386 python3.4-venv:i386 python3.4-doc:i386 binutils:i386
  binfmt-support:i386
Recommended packages:
  python3-gi:i386 python3-dbus.mainloop.qt:i386
The following packages will be REMOVED:
  bluez
The following NEW packages will be installed:
  bluez:i386 dh-python libcgmanager0:i386 libdb5.3:i386 liblzma5:i386
  libnih-dbus1:i386 libnih1:i386 libpython3-stdlib:i386
  libpython3.4-minimal:i386 libpython3.4-stdlib:i386 libreadline6:i386
  libudev1:i386 python3:i386 python3-dbus:i386 python3-minimal:i386
  python3.4:i386 python3.4-minimal:i386
The following packages will be upgraded:
  bluez-alsa:i386 libdbus-1-3 libdbus-1-3:i386 libexpat1 libexpat1:i386
  libexpat1-dev liblzma5 libreadline6 libudev1 mime-support

ну охренеть же, дайте два? Пожалуй, не стоит ее пытаться удалять.
нет, эта проблема в современных версиях исправлена, но где гарантия что завтра все это не притащат обратно очередными кривыми зависимостями всего-от-всего?
ну и в /proc/acpi часто оказываются и более интересные вещи, чем какой-то там блютухл, и как раз на серверах.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

89. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Anonymus (?), 21-Авг-18, 10:40

Что то, товарищ, делаете не то... Или систему менять надо.
root@evm:~# apt remove  bluez bluez-cups   bluez-obexd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  linux-headers-4.15.0-29 linux-headers-4.15.0-29-generic linux-image-4.15.0-29-generic linux-modules-4.15.0-29-generic
  linux-modules-extra-4.15.0-29-generic
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  blueman bluez bluez-cups bluez-obexd pulseaudio-module-bluetooth
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
After this operation, 10,7 MB disk space will be freed.
Do you want to continue? [Y/n]

Заметка для фашистов граматики: я не русскоязычный

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

47. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от SysA (?), 20-Авг-18, 13:34

Вообще-то этот пример был дан из расчета на уровень домохозяек, чтобы внушительнее выглядело и не особо пугать...
На самом деле там можно управлять всем, что на ACPI выходит: например, разгонять/тормозить вентиляторы, выключать питание и пр.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (17), 20-Авг-18, 11:26

А самое главное - чтобы софт в контейнере мог писать что-то в /proc/acpi, он должен выполняться под root, что само по себе дыра в безопасности.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (21), 20-Авг-18, 11:44

От задачи зависит. Это же фича контейнера - изолировать приложения в юзерспейсе и предоставлять возможность запускать их даже в *изолированном* руте.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

26. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +8 +/–

Сообщение от anonymous (??), 20-Авг-18, 11:58

> Это же фича контейнера - изолировать приложения в юзерспейсе
Идиоты, которые верят что docker хоть какое-то отношение имеет к безопасности, обречены майнить чужие коины.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

24. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от anonymous (??), 20-Авг-18, 11:57

> он должен выполняться под root
Ха, как будто кто-то из смузихлебателей знает про ключ -u или смотрят в Dockerfile под каким пользователем запускается entrypoint. В docker-compose до сих пор нет нормального способа задать пользователя. Поэтому считай. что у всех все работает под рутом.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

25. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +7 +/–

Сообщение от Аноним (-), 20-Авг-18, 11:58

> А самое главное - чтобы софт в контейнере мог писать что-то в
> /proc/acpi, он должен выполняться под root, что само по себе дыра в безопасности.
Вообще-то задумка в изоляции как раз и была в том, чтобы можно было спокойно дать софту виртуального рута или ограничить ущерб при взломе.
Но то ведь было в старперских джейлах, зонах и прочем крапе, когда ничего не понимали в проектировании и поддержке современных систем! И только потом пришло просветление и все умные люди внезапно поняли, что контейнерам поддержка изоляции приложений не нужна, ведь они не для этого!

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

71. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +6 +/–

Сообщение от Аноним (71), 20-Авг-18, 20:29

Докеры для того, чтобы даже тот, кто не умеет читать и писать конфиг, мог почувствовать себя девопсом.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

116. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от пох (?), 21-Авг-18, 20:43

потому что те кто умеют - заглянут в dockerfile - и обоср..ся это запустить ;-)

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

19. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от имя (?), 20-Авг-18, 11:36

centos 6
# docker --version
Docker version 17.12.0-ce, build c97c6d6
$ docker run -it ubuntu bash
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
c64513b74145: Pull complete
01b8b12bad90: Pull complete
c5d85cf7a05f: Pull complete
b6b268720157: Pull complete
e12192999ff1: Pull complete
Digest: sha256:3f119dc0737f57f704ebecac8a6d8477b0f6ca1ca0332c7ee1395ed2c6a82be7
Status: Downloaded newer image for ubuntu:latest
root@c8b0390d3ce6:/# ls -la /proc/acpi
total 0
dr-xr-xr-x   4 root root 0 Aug 20 08:17 .
dr-xr-xr-x 191 root root 0 Aug 20 08:17 ..
dr-xr-xr-x   2 root root 0 Aug 20 08:17 ac_adapter
dr-xr-xr-x   2 root root 0 Aug 20 08:17 battery
-rw-r--r--   1 root root 0 Aug 20 08:17 wakeup
root@c8b0390d3ce6:/# ls -la /proc/acpi/wakeup
-rw-r--r-- 1 root root 0 Aug 20 08:17 /proc/acpi/wakeup
root@c8b0390d3ce6:/# cat /proc/acpi/wakeup
Device    S-state      Status   Sysfs node
PCI0      S5    *disabled  no-bus:pci0000:00
root@c8b0390d3ce6:/# ls -la /proc/acpi/battery/
total 0
dr-xr-xr-x 2 root root 0 Aug 20 08:18 .
dr-xr-xr-x 4 root root 0 Aug 20 08:18 ..
root@c8b0390d3ce6:/# ls -la /proc/acpi/ac_adapter/
total 0
dr-xr-xr-x 2 root root 0 Aug 20 08:18 .
dr-xr-xr-x 4 root root 0 Aug 20 08:18 ..
root@c8b0390d3ce6:/# echo PCI0 > /proc/acpi/wakeup
root@c8b0390d3ce6:/# cat /proc/acpi/wakeup
Device    S-state      Status   Sysfs node
PCI0      S5    *enabled   no-bus:pci0000:00
root@c8b0390d3ce6:/# echo PCI0 > /proc/acpi/wakeup
root@c8b0390d3ce6:/# cat /proc/acpi/wakeup
Device    S-state      Status   Sysfs node
PCI0      S5    *disabled  no-bus:pci0000:00
выходим и смотрим на хосте
# /sbin/lspci
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (41), 20-Авг-18, 13:04

А где же эта хваленая изоляция? Где она? Мы говорим о ней постоянно!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от нах (?), 20-Авг-18, 13:08

синенькая? Так вот же ж она, щас подмотаем... опа, /proc/acpi добавлен в список неположенного докерам, всем обновляться! До следующего (из миллиона того что может оказаться в /proc) спим спокойно.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

44. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –2 +/–

Сообщение от Аноним (-), 20-Авг-18, 13:15

> А где же эта хваленая изоляция? Где она? Мы говорим о ней постоянно!
Для изоляции приложения есть специально заточенный под это дело, простой, понятный и безбаговый SELinux. А изоляция в контейнерах не нужна (знают все умные люди)!

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

51. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Аноним (51), 20-Авг-18, 14:12

LXD-docker пашет на rhel

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

54. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от anonymous (??), 20-Авг-18, 14:42

Я вот уже давно мучаюсь одним вопросом. А что если изоляция нужна не руту, а простому пользователю. Как он может создать для себя песочницу, если все нужные для этого вызовы - привилегированные?
Может есть какой-нибудь сервис systemd-namespaces, который проксирует запросы от пользователей и выполняет от имени рута?

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

68. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Animemous (?), 20-Авг-18, 19:15

Не все. Кое-что можно без рута. Bubblewrap на это дело и пилят.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

76. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от mikhailnov (ok), 20-Авг-18, 23:11

fakeroot?

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

77. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Аноним (77), 20-Авг-18, 23:56

посмотрите на firejail

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

55. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от нах (?), 20-Авг-18, 14:46

> Для изоляции приложения есть специально заточенный под это дело, простой, понятный и
> безбаговый SELinux.
лолшто?
>  А изоляция в контейнерах не нужна (знают все умные люди)!
а, понял, понял.
Вы бы эта, тег "сарказм" аккуратнее расставляли. "специально заточенный под это дело" должно было быть снаружи.
кстати, странно что "специально заточенный под это дело, простой и безбаговый apparmor" (у которого есть профиль для докера) не помог. Впрочем, первоисточник новости - rhn, а они такими вещами не особенно интересуются.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

122. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:33

> Для изоляции приложения есть специально заточенный под это дело, простой,
> понятный и безбаговый SELinux. А изоляция в контейнерах не нужна
> (знают все умные люди)!
Вы крашеная, простите?
PS: s/на//;s/нн/н/ для большей понятности вопроса, а то мало ли...

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

62. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Alex_hha (?), 20-Авг-18, 16:45

> Для изоляции приложения есть специально заточенный под это дело, простой, понятный и безбаговый SELinux
запустите на одном хосте 5 приложений, каждое из которых будет требовать свою версию glibc/ruby/python/php

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

64. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от Аноним (64), 20-Авг-18, 17:22

>> Для изоляции приложения есть специально заточенный под это дело, простой, понятный и безбаговый SELinux
> запустите на одном хосте 5 приложений, каждое из которых будет требовать свою версию glibc/ruby/python/php
Это был сарказм (в ином случае "простым и понятным" selinux назвать не получится).
Потому что чуть выше (правда, уже в удаленных) один из ярых воЕнов, брызгая слюной, доказывал что несогласные с супремностю докера на самом деле суть бзшники-вантузятники-путтиэкзешники, которые не читали новость полностью, ведь там ясно написано, что изоляция делается через селинукс, а не в самом контейнере.

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

70. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от пох (?), 20-Авг-18, 20:21

1. а можно вместо этого один раз выпороть пять разработчиков, чтобы они не требовали ненужной херни?
2. в редчайших случаях (когда переходный период, когда мержатся разные проекты и не хватает мощностей) - мы, не поверите, держали две версии и glibc, и пихона, и пехепе. И оно у нас работало без всяких докеров. Вы не умеете? Значит вы безграмотны и криворуки, см пункт 1.
Работало бы и по пять, но см пункт 1. Зоопарк версий в продакшн - ненужно. Ни в контейнере, ни без него. В том числе и потому, что генитальный разработчик не собирается отвечать за баги и нестабильность в не своем коде.
И нет, ни один разработчик не уволился потому, что "у вас надо программировать на php5.6, а я хочу 7.2"
Но вот возможность отделить систему, в которой крутится продукт разработчиков, от системы, предоставляющей ему физические ресурсы - в целом, полезна. К сожалению, докер реализует ее практически никак - из-за кривой overlayfs, сломанной концепции volumes, хранения информации важной для внутренности контейнера - отдельно от контейнера, недоделанной сетевой инфраструктуры, неумения его разработчиков пользоваться shell... и так до бесконечности.
Часть этих проблем кое-как затыкают ненужные "системы оркестрации", притаскивая взамен еще миллион своих собственных.

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

74. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Gemorroj (ok), 20-Авг-18, 21:03

если я правильно понял, то разрабам из-за жопорукости админа приходиться кодить на пхп5.6 без возможности обновиться до 7.2 (ненужная херня, на сколько я понял)?
это тогда причина не разрабам увольняться, а уволить админа.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

78. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –1 +/–

Сообщение от DevOps (?), 20-Авг-18, 23:57

Уволить задним числом заранее кинув на последнюю зарплату и без возможности восстановления.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

115. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от пох (?), 21-Авг-18, 20:39

разрабам предлагается объяснить, письменно, какие бенефиты компании принесет переход на другую версию. С графиком разработки в руках - "вот тут мы копались столько, а с новой прекрасной версией все это заняло бы столько, правда вот там и вон там у нас <? и в ем код который еще php4 помнит, его пришлось бы переписать вот за столько". Админам это неинтересно и они в этом даже и участвовать не будут (мы же помним, что у нас - админы, и они поставят новую версию, ничего не сломав в системе, а не будут городить докер на докере в докере, потому что вместе с новым пехепе приехала новая версия дистрибутива, а в ней нет старого пихона, на котором, ой, внезапно, ключевой кусок написан, да еще с какими-то бинарными so от которых уже никто не помнит где правильная версия исходника - все равно его планировалось переделать сто лет назад)
И дальше - либо переходим, либо нет, потому что еще на этапе написания выясняется, что фича выеденного яйца не стоила, и никакой пользы бизнесу не принесет.
Чаще, почему-то, оказывается что нет ;-)  Потому что хочухочухочу обламывается о необходимость свои хотелки обосновать а потом отвечать за выполнение этих графиков. А заморачиваться никто не любит.
Докер используется по назначению - как средство деплоймента фиксированных окружений, слишком замороченных, чтобы обойтись скриптами для пакетного менеджера. В этом качестве даже и можно пользоваться - хотя временами кажется, что во времена bsd'шных jail'ов с unionfs проблем было поменьше в разы.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

79. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от ALex_hha (ok), 21-Авг-18, 00:07

Если у вас на локалхосте используется одна версия, то это ещё не значит, что и в реальном мире будет так же. А в реальном мире есть понятие легаси. И никто вам не выделит пару лет, чтобы перевести бекэнд с руби 1.8 на 1.9. Вот так и живем.
Та можно и 10 версий держать, вопрос лишь удобства и докер справляется с этой задачей на отлично.
Покажите мне пример запуска 3х версий php как модуля апача, а то я может что то пропустил

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

80. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от DevOps (?), 21-Авг-18, 00:11

lsPHP умеет вроде.

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

86. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от пох (?), 21-Авг-18, 07:44

выделили. Переводят. Именно со словами "поддерживать старый хлам - слишком дорого для нашей компании".
Причем в "реальном мире" нет никакой задачи сочетать бэкэнд на старой версии с куском кода на новой - не то что в рамках одного хоста, а часто даже в рамках одного кластера - мощностей всегда не хватает, это у локалхостера они в избытке.
> Та можно и 10 версий держать, вопрос лишь удобства и докер справляется с этой задачей на отлично.
а ответственность за стабильность, безопасность и контролируемость - переложена на никого?(с)
Мне вполне хватало геморроя с двумя разными версиями, каждую из которых отдельно кормить апдейтами и затыкать в ней дыры.
> Покажите мне пример запуска 3х версий php как модуля апача, а то я может что то пропустил
"production", "реальный мир"... php как модуль апача. Опаньки. Знаете, вы еще очень многое пропустили, нет смысла на вас время тратить.

Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

90. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от ALex_hha (ok), 21-Авг-18, 11:00

> слишком дорого для нашей компании".
оно и понятно, в "рога и копыта" на локалхосте такого и не нужно. Дальше можно не продолжать

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

113. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от пох (?), 21-Авг-18, 20:07

модули апача - это именно уровень ваших рогов и копыт. fpm ниасилен, понятен.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

91. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –4 +/–

Сообщение от ALex_hha (ok), 21-Авг-18, 11:02

> а ответственность за стабильность, безопасность и контролируемость - переложена на никого?(с)
в нормальных фирмах она переложена на devops, но у вас по ходу такого не слышали. Ну ничего, бывает.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

114. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от пох (?), 21-Авг-18, 20:21

> в нормальных фирмах она переложена на devops
это и есть никто. Админы-недоучки, для которых, о ужас, две версии пехепе на одном хосте - неразрешимая проблема, apt-get install так не могёт. Зато они знают докер, къебенетес и много других страшных слов и, самые продвинутые, умеют писать скрипт для ansible.
что отслеживают проблемы безопасности в давно протухших "пяти версиях libc" и способны пересобрать пакет вручную, сбэкпортив патчи - это вряд ли, те кто на это способны, обычно как раз понимают, что это и бесполезно, и времени не хватит на полезную деятельность. Ждут ебилдов, а если че - "это не мы, это вот пакет гнилой, или в докере s stands for security"...

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

124. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от ALex_hha (ok), 21-Авг-18, 23:53

Э как бомбануло у админа :D

Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

123. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:38

>> ответственность
> devops
И в чём же она выражается?

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

129. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от ALex_hha (ok), 22-Авг-18, 09:02

> И в чём же она выражается?
да во всем том же, в чем и у обычных сисадминов. В отслеживании уязвимостей и устранении их. А вот каким способом, это уже вопрос другой. Если обычный сисадмин, условно, сделает yum update и /или наложит патч и соберет новый rpm, то девопс по сути сделает тоже самое, просто запустит соотв джобу в CI/CD, которая сделает тоже самое, только внутри докера ;)
Очень давно был проект на php 4, который просто работал и все, естественно перевести на 5ку его не реально, там по сути заново надо было бы все переписать, так и работал в докере и отлично себя чувствовал.
А совсем недавно был у меня проект на ruby 1.8, который был в докере, ибо там такое легаси, что туда лучше не смотреть. Но как тут рассказывают некоторые сказочники локалхостов, что всех разработчиков таких систем надо уволить и переписать на современные версии, в том случае это было не реально, от слова совсем. При этом это был один из крупнейших сервисов америки по продажам gift карточек, а там крутится много много денег. И все отлично работало и работает, насколько я знаю, проблем с безопасностью не было.
Так что реальный мир он такой и немного отличается от розовых фантазий :)

Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

131. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от anonymous (??), 22-Авг-18, 12:01

> да во всем том же, в чем и у обычных сисадминов. В отслеживании уязвимостей и устранении их.
За исключением того что у них (девопсов этих ваших) как правило нет для этого ни знаний, ни умений.

Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

133. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от Alex_hha (?), 22-Авг-18, 13:52

> За исключением того что у них (девопсов этих ваших) как правило нет
> для этого ни знаний, ни умений.
с какого перепуга? Я вот проработал 10 лет сисадмином, последние 3 года работаю девопс. Никаких проблем не испытываю. Возвращаться к скучной работе сисдамина нет никакого желания :)
P.S.
вы ведь понимаете, что devops это лишь методология разработки и доставки продукта, а не какая то новая чудо специальность? Но тут стоит учитывать, что многие админы локалхостов, которые хоть раз в жизни запускали docker и установили nginx через ansible на две виртуалки, гордо бьют себя в грудь и кричат, что они devops инженеры. А потом ты начинаешь их собеседовать, а там полный мрак.

Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

134. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от angra (ok), 22-Авг-18, 23:45

> Я вот проработал 10 лет сисадмином, последние 3 года работаю девопс.
И за всё это время не сталкивался с chroot, jail, vserver, openvz, lxc, а также kvm и xen? Только с появлением docker смог решить задачу запуска в изолированном окружении?

Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

136. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от ALex_hha (ok), 23-Авг-18, 12:22

> И за всё это время не сталкивался с chroot, jail, vserver, openvz, lxc, а также kvm и xen?
Конечно сталкивался, просто в докере это на порядок удобнее. Я вот посмотрел бы, сколько у вас ушло времени на поднятие elk стека в chroot/jail/openvz. А в докере это одна команда и минута времени. И таких примеров очень много. При этом я не утверждаю, что docker это панацея и всем срочно надо на него переходить. Но во многих моментах разработки - он очень здорово облегчает жизнь.
Так и представляю ситуацию - выходит к вам новый qa/developer/devops, ему надо поднять у себя на машине тестовое окружения, чтобы понять что и как, или что то проверить. А вы ему такие - ставь себе  openvz/kvm/xen, потом ставь и настраивай 100500 программ, в лучшем случае будет bash скрипт для сборки всего этого добра. Ведь тут некоторые кричали, что ansible это новомодная хипстерская подделка девопсов и не нужна от слова совсем, так что только хардкор, только bash скрипты.
В моем случае, я даю человеку docker-compose файл и через 5-15 минут у него уже готовое окружение. И у нас не бывает случаев - "а у меня на машине все работает" :D Единственный случай, когда в докере реально могут быть различия, это когда ваш софт сильно завязан на версию ядра, тогда могут быть проблемы.

Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

130. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +/–

Сообщение от anonymous (??), 22-Авг-18, 11:55

А нахрена их запускать на одном хосте ?

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

63. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +1 +/–

Сообщение от Alex_hha (?), 20-Авг-18, 16:47

> Идиоты, которые верят что docker хоть какое-то отношение имеет к безопасности, обречены майнить чужие коины.
О какой изоляции тут можно говорить, после Meltdown/Spectre/Foreshadow ?!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

72. "Уязвимость в Docker, связанная с предоставление доступа к /p..." –1 +/–

Сообщение от Аноним (72), 20-Авг-18, 20:30

AMD

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

84. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +3 +/–

Сообщение от Аноним (84), 21-Авг-18, 03:34

Что самое интересное, что изначально Docker начинался, как песочница для разработчиков, позволяющая сэкономить время... Потом нашлись "мудрецы", которые посчитали, что этот сырец можно втащить в прод. И понеслась!...
Тео Де Раадт давно объяснял причины, почему он не вкладывается в виртуализацию, тем, что на дырявой архитектуре ваять такие же абстракции сверху и потом пытаться добиться общей безопасности хоста и виртуальных машин на нём, это равносильно черпанию воды кружкой из дырявой лодки - если черпать достаточно быстро, то будешь держаться на плаву. Ха-ха-ха!
Бизнесу не нужна безопасность - ему нужны деньги. Поэтому мы имеем docker в проде. Поэтому мы имеем целые ботнеты, хостинги спамерские, которые засерают трафик. Бизнесу без разницы, что гонять по сети: спам, ddos, почту, картинки, мультимедиа - всё равно! Лишь бы бабки платили.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

117. "Уязвимость в Docker, связанная с предоставление доступа к /p..." +2 +/–

Сообщение от пох (?), 21-Авг-18, 21:52

> Что самое интересное, что изначально Docker начинался, как песочница для разработчиков,
> позволяющая сэкономить время...
ну так они - сэкономили. Теперь то, что они разработали, "прекрасно работает" не "на моем компьютере, а у вас наверное что-то сломано, почините", а "в моем контейнере", переносить на прод бережно, стараясь чтоб крышка не открылась, а то содержимое-то расплещешь, хрен отмоешься.
Причем писали это именно такие разработчики "мне удобно на моей убунточке, и плевать, что у вас там в проде и почему именно оно", поэтому они и написали "как удобно", половину недоделав и бросив. Поэтому у нас default network - "unsupported legacy", неdefault открывает все порты настеж. Поэтому у нас есть volumes, но пользоваться ими нельзя, заманаешься выгребать потом из системы мусор.
Поэтому у нас бесконечно растет storage и параллельно растет регистри, не смотря на череззадничные операции по их периодической чистке с риском все поломать.
> Бизнесу не нужна безопасность - ему нужны деньги
бизнес разный бывает. Некоторые еще не продают shitAAS, а продают что-то, за что можно подержаться руками. Безопасность ради безопасности им, понятно, не нужна, поделка Тео "двадцать лет без уязвимостей, если не втыкать в розетку" там не котируется, но если очередной монгачервяк пошифрует им данные клиентов - они потеряют деньги, а этого они очень не любят.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

88. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +1 +/–

Сообщение от ПавелС (ok), 21-Авг-18, 09:20

Давненько я присылал на kernel.org патчик с испправлением некоторых пермишенов в /proc. И мне отказали как раз по причине "будут проблеммы с виртуализацией".
Вобщем с пермишенами в /proc следовало бы поразобраться, а то там как сделано так и годами никто не пересматривал.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

93. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +/–

Сообщение от Ant (??), 21-Авг-18, 12:09

Agile

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

94. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +2 +/–

Сообщение от Аноним (94), 21-Авг-18, 12:12

У меня уживаются вместе и docker и lxc, до этого использовал openvz. Везде свои удобства. К примеру на одном из серверов поднята 1С8 + postgres + apache + vnc в Docker и это очень удобно, т.к. можно легко обновлять, деплоить и менять версии или комбинировать в нужном варианте за короткое время. Базы если что за 100Гб. На другом проекте прекрасно живет lxc с проектом. Надо просто делать с понимаем плюсов и минусов, а то получается когда в руках молоток то все вокруг гвозди.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

106. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +/–

Сообщение от anonymous (??), 21-Авг-18, 15:48

А теперь представь себе что что-то пошло не так и тебе нужно вытянуть из докера базу.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

112. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +1 +/–

Сообщение от пох (?), 21-Авг-18, 20:04

ну docker cp же ж... только вот "что-то пошло не так" в случае докера обычно - "навернулась overlayfs и ваша база превратилась в тыкву".
вытаскивай, не вытаскивай...

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

125. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +1 +/–

Сообщение от ALex_hha (ok), 22-Авг-18, 00:14

И в чем проблема? Базы как правило выносятся на volume, так что если что то пошло нет так, то проблем не будет от слова совсем.

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

128. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +/–

Сообщение от Аноним (72), 22-Авг-18, 04:26

volume небезопасны от команды docker ... prune
нужно монтировать как папку

Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

132. "Уязвимость в Docker, связанная с предоставлением доступа к /..." +/–

Сообщение от Alex_hha (?), 22-Авг-18, 13:44

> volume небезопасны от команды docker ... prune
С таким же успехом "обычные" базы не безопасны от rm -fr, но мы тут держимся :D

Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+3 +/–
Сообщение от Аноним (1), 20-Авг-18, 10:07
Epic Fail товарищи
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	11. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+15 +/–
	Сообщение от Аноним (-), 20-Авг-18, 11:13
	Контейнеры... Изоляция... LOL.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	17. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от Аноним (17), 20-Авг-18, 11:34
	>>Контейнеры... Изоляция... LOL. Так недавно ж снова всплыла уязвимость в процессорах (Foreshadow), ставящая под угрозу безопасность vps и облачных хостингов.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	46. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от Ivan_83 (ok), 20-Авг-18, 13:26
	Так с интела пора валить.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	61. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+3 +/–
	Сообщение от Anonymouss (?), 20-Авг-18, 16:33
	На докер, да.
	Ответить \| Правка \| ^ к родителю #46 \| Наверх \| Cообщить модератору


	20. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+20 +/–
	Сообщение от Аноним (-), 20-Авг-18, 11:41
	> Контейнеры... Изоляция... LOL. The 's' in Docker stands for security!
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	58. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от anonymous (??), 20-Авг-18, 16:14
	Контейнер != изоляция. Docker контейнер, но без изоляции.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	59. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+2 +/–
	Сообщение от Аноним (59), 20-Авг-18, 16:18
	какой смысл тогда в контейнере? вот у vz и изоляция, и контейнеры настоящие.
	Ответить \| Правка \| ^ к родителю #58 \| Наверх \| Cообщить модератору


	65. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	–1 +/–
	Сообщение от Аноним (-), 20-Авг-18, 17:33
	> какой смысл тогда в контейнере? вот у vz и изоляция, и контейнеры настоящие. И где все ваши vz, zones, jails? Теоретические академподелки, не приспособленные для продакшена, хайлода в кластерах на кубернете с битчейном, вымерли естественным путем, как динозавры и остались лишь у немногих надутых гусей и ветеран-админов!
	Ответить \| Правка \| ^ к родителю #59 \| Наверх \| Cообщить модератору


	66. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+6 +/–
	Сообщение от Аноним (66), 20-Авг-18, 18:04
	А docker прямо приспособлен к прудукшену по самые помидоры! Щаз: https://habr.com/post/346430 . Агрессивной рекламой запудрили мозг умам неокрепшим, пока поймут, что этот docker-фуфел чистейшей воды, пройдёт время. И да, jail-ы и zone-ы где надо, во-первых, как раз используются, во вторых, только они и используются. Но фанатам docker-a об этом неизвестно ибо таковых к тем системам на пушечный выстрел не подпускают, не доросли ещё.
	Ответить \| Правка \| ^ к родителю #65 \| Наверх \| Cообщить модератору


	85. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от лютый охохоня (?), 21-Авг-18, 07:28
	Докер используют в основном для шедулинга ресурсов тысяч серверов, например одноглазики ру, а изоляция там особо не нужна. ОпенВЗ на дешёвых впс тарифах приплетать не надо, оно совсем для другого
	Ответить \| Правка \| ^ к родителю #66 \| Наверх \| Cообщить модератору


	73. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+3 +/–
	Сообщение от шухер (?), 20-Авг-18, 20:43
	OpenVZ используется тучей хостеров vds/vps Выходите из погреба.
	Ответить \| Правка \| ^ к родителю #65 \| Наверх \| Cообщить модератору


	119. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:23
	> Теоретические академподелки, не приспособленные для продакшена Смотрите, люди, на "практика". Он-то наверняка знает уш-у, карате и много других страшных слов. Вот только не сечёт ни хрена в том, что несёт, но это ведь и не важно...
	Ответить \| Правка \| ^ к родителю #65 \| Наверх \| Cообщить модератору


	67. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+1 +/–
	Сообщение от Аноний (?), 20-Авг-18, 18:20
	Переносимость. Изоляция часто мешает, например без танцев с бубнов нельзя получить доступ к файлам.
	Ответить \| Правка \| ^ к родителю #59 \| Наверх \| Cообщить модератору


	110. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	–2 +/–
	Сообщение от Аноним (110), 21-Авг-18, 17:33
	давайте вы не будете раскатывать о VZ который по сути прослойка поверх namespace + cgroups..
	Ответить \| Правка \| ^ к родителю #59 \| Наверх \| Cообщить модератору


	111. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+2 +/–
	Сообщение от Wladmis (ok), 21-Авг-18, 19:51
	> давайте вы не будете раскатывать о VZ который по сути прослойка поверх namespace + cgroups.. Во-первых, VZ появился задолго до namespaces+cgroups, во-вторых, Parallels хорошо законтрибьютила в развитие этих самых namespaces для того, чтобы уменьшить объём патч-сета на ядро, которое каждый релиз довольно-таки сложно заредиффить, и побольше использовать нативные ядерные механизмы изоляции, в-третьих, патч-сет на современные VZ-ядра всё ещё внушительный, и там много как раз про настоящую изоляцию.
	Ответить \| Правка \| ^ к родителю #110 \| Наверх \| Cообщить модератору


	118. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:21
	> Контейнеры... Изоляция... LOL. Ну покажите мне такое на openvz. А дыркер -- он и есть дыркер.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	12. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	–1 +/–
	Сообщение от имя (?), 20-Авг-18, 11:13
	Container Linux by CoreOS stable (1800.5.0) $ docker exec -it d911de0408c3 /bin/ash / # ls -la /proc/acpi/ total 0 dr-xr-xr-x 2 root root 0 Aug 20 08:09 . dr-xr-xr-x 99 root root 0 Jul 31 15:37 .. -rw-r--r-- 1 root root 0 Aug 20 08:09 wakeup / # cat /proc/acpi/wakeup Device S-state Status Sysfs node / #
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	45. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от Харитон (?), 20-Авг-18, 13:21
	Epic Fail тем, кто при настройке cервера отключает SeLinux. Изучить как им пользоваться видать собственная важность запрещает.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	126. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	–1 +/–
	Сообщение от ОМЖ (?), 22-Авг-18, 01:08
	я отключаю. селинукс сложный. домен-роль-тип-контекст, чегобль, не ну наx
	Ответить \| Правка \| ^ к родителю #45 \| Наверх \| Cообщить модератору


	50. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от SysA (?), 20-Авг-18, 14:07
	Ну, да! Не понятно только почему она в мини... :)
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

2. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+2 +/–
Сообщение от Аноним (2), 20-Авг-18, 10:21
in the word Docker `s` letter means security! P.S. уязвимость раскрыта на прошлой неделе, с разморозочкой
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	104. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от SysA (?), 21-Авг-18, 15:31
	Вообще-то в начале прошлого месяца!.. :)
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору

4. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+4 +/–
Сообщение от Аноним (66), 20-Авг-18, 10:36
Кто просветит, почему всегда качественные системы уходят в забвение, а всякое дерьмо вроде docker-а занимает рынок и приобретает кучу фанатичных поколонников? Все мухи?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+/–
	Сообщение от Аноним (5), 20-Авг-18, 10:41
	> качественные системы какие?
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	7. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+5 +/–
	Сообщение от Аноним (7), 20-Авг-18, 10:54
	BeoS
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	18. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	–2 +/–
	Сообщение от Аноним (17), 20-Авг-18, 11:36
	Знавал чела, который на полном серьезе считал "качественным аналогом" докера OpenVZ =)) Еще и админом в небольшом воронежском банке при этом работал.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	60. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+4 +/–
	Сообщение от Аноним (59), 20-Авг-18, 16:21
	OpenVZ - аналог Docker'а? Это он отжог! У OpenVZ изоляция настоящая.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	120. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 21-Авг-18, 23:25
	> Знавал чела, который на полном серьезе считал "качественным аналогом" докера OpenVZ =)) > Еще и админом в небольшом воронежском банке при этом работал. Так он, поди, какой-нить мехмат ВГУ кончал, а не факультет словоблудия.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	52. "Уязвимость в Docker, связанная с предоставление доступа к /p..."	+1 +/–
	Сообщение от lxc (?), 20-Авг-18, 14:14
	LXC?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору