| |
| |
| 3.4, анон (?), 11:06, 30/03/2017 [^] [^^] [^^^] [ответить]
| +5 +/– |
Позволяющий руту получить права рута. Отличненько.
| | |
| |
| 4.40, Аноним (-), 14:36, 01/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
Позволяющая руту внутри _контейнера_, созданного непривилегированным пользователя, получить права рута на хосте.
| | |
|
| 3.5, Аноним (-), 11:11, 30/03/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Если "фича" увеличивает область атаки на порядок, не является ли она сама уязвимостью?
| | |
| |
| 4.7, Аноним (-), 11:15, 30/03/2017 [^] [^^] [^^^] [ответить]
| +26 +/– | |
> Если "фича" увеличивает область атаки на порядок, не является ли она сама уязвимостью?
Предлагаю удалить из ядра Linux сетевой стек. Во избежание.
| | |
| |
| 5.12, Аноним (-), 11:54, 30/03/2017 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Удалять не стоит. А вот давать кому попало CAP_NET_ADMIN — глупо.
Но жадным долбоё**м хочется "чтоб Jango и Wordpress ставились из коробки без VPS". И все вдруг забывают, для чего нужен root, и почему давать кому-попало "полный но ограниченный" доступ к системе — плохая идея.
| | |
| |
| 6.15, Аноним (-), 12:20, 30/03/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
А зачем джанге и вордпрессу нет_админ? Они там интерфейсы конфигурируют? Или iptables настраивают?
| | |
| |
| |
| 8.23, XXXasd (ok), 14:42, 30/03/2017 [^] [^^] [^^^] [ответить] | +/– |  как минимум хотя бы для того чтобы любая пользовательская программа могла бы сн... текст свёрнут, показать | | |
| 8.27, Аноним (-), 16:58, 30/03/2017 [^] [^^] [^^^] [ответить] | +/– | А вы хотели бы, чтобы и для контейнеров, и для основной системы было одно и то ж... текст свёрнут, показать | | |
|
|
|
|
| 4.19, Нанобот (ok), 13:08, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
 >Если "фича" увеличивает область атаки на порядок, не является ли она сама уязвимостью?
нет, не является
| | |
| 4.24, пох (?), 16:14, 30/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Если "фича" увеличивает область атаки на порядок, не является ли она сама
> уязвимостью?
контейнеризация, которой слепо доверяют в качестве единственной меры безопасности (а именно в этом случае бывае CAP_чтонибудь без реального рута) - да, безусловно, является ;-)
| | |
|
|
|
| 1.14, Аноним (-), 12:18, 30/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Атака также затруднена на старые системы с версиями ядра меньше 3.9 из-за отсутствия в них поддержки "user namespaces".
У рута затруднений не возникнет. Но вот только зачем ему это...
| | |
| |
| 2.25, пох (?), 16:14, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> У рута затруднений не возникнет. Но вот только зачем ему это...
из user namespace вылезать, разумеется. Пробив днищ...э, простите, контейнер.
| | |
|
| 1.17, zfs (??), 13:02, 30/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> ядро Debian и RHEL/CentOS 7 может быть атаковано только после явной активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1).
>...
> Проблема остаётся неисправленной в Fedora, Debian и CentOS/RHEL 7
# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.3.1611 (Core)
Release: 7.3.1611
Codename: Core
# uname -a
Linux gw 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# sysctl -a|grep userns
Но
# lxc-checkconfig |grep -i user
User namespace: enabled
Т.е. в системе напрочь отсутствует /proc/sys/kernel/unprivileged_userns_clone. Но LXC работает.
Зафиксили уже или я что-то не так понял?
| | |
| |
| 2.20, Аноним (-), 13:10, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– | |
unprivileged_userns_clone позволяет любому пользователю (nobody и т.п.) создать себе namespace и сделать там себя "ограниченным" рутом, тем самым получив возможность использовать сплоит.
Если unprivileged_userns_clone отсутствует, уязвимость могут использовать только процессы, которые и так уже имеют рут внутри namespace. То есть тупо только для побега из namespace.
| | |
|
| 1.29, Анонимм (??), 18:15, 30/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Неплохая очередная причина вынести сетку в отдельное адресное пространство?
| | |
| |
| |
| 3.37, пох (?), 18:52, 31/03/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Отличный подход для Enterprise-а!
у энтерпрайса размером поболее подвальной лавчонки как раз обычно есть билдферма, лишние руки для ее обслуживания и, иногда, другие поводы пересобирать ведра.
Только чем это поможет в данном случае (учитывая что ему запросто может быть нужен и ipsec, и namespaces) - загадка.
| | |
| |
| 4.39, Sem (??), 18:32, 03/04/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Это даже не смешно. У вас представление об энтерпрайзе как сборище линукс-гиков?
| | |
|
|
|
| 1.36, Аноним (-), 18:07, 31/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Топикстартер забыл упомянуть, что в Debian это некатит, потому, что
>Unprivileged user namespaces are disabled in Debian, this only affects
non-standard setups
| | |
| |
| 2.38, Аноним (-), 20:31, 31/03/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Топикстартер забыл упомянуть, что в Debian это некатит, потому, что
Вы невнимательно читали новость, там про это написано. "Например, пакеты с ядром для Ubuntu и Fedora уязвимы по умолчанию, а ядро Debian и RHEL/CentOS 7 может быть атаковано только после явной активации поддержки "user namespaces" (sysctl kernel.unprivileged_userns_clone=1)"
| | |
|
|
