• XSS.stack #1 – первый литературный журнал от юзеров форума

Virtual Machine vs Dockers

Отслеживать
ValeraSnowdrop

ValeraSnowdrop

RAID-массив
Пользователь
Регистрация
07.08.2023
Сообщения
51
Решения
1
Реакции
60
Почему сообществом считается нормой использовать VM, но не использовать контейнеры?
Я не нашел упоминаний об использовании контейнеров вместо VM в рабочих машинах пользователей. Такие инструменты как docker могут иметь преимущества над использованием VM. Я думаю что благодаря этому можно прибавить в функциональности/производительности отдельных кубов(контейнеров/VM) немного потеряв в безопасности, но не потеряв в анонимности. Знаете ли вы случаи использования контейнеров для построения системы для работы?
 
Хорошая тема для обсуждения 👍 Думаю, главный вопрос тут - безопасность. Хотя, некоторые задачи действительно можно просто решить с помощью контейнеров.
 
ValeraSnowdrop сказал(а):
Why is the community considered the norm to use VM, but not to use containers?
I did not find any mention of using containers instead of VM in user work machines. Tools such as docker may have advantages over using VM. I think that thanks to this, you can add a little loss in the functionality / productivity of individual cubes (containers / VM), but without losing anonymity. Do you know cases of using containers to build a system for work?
let me explain

in VM you have full control over the limitations of physical sources.
while docker is primary made for containers meaning for sharing a part of your kernel from one device over the other in an easy way

why is it considered a norm to use VM i believe its for security reasons while VM provide isolation between the host and the guest using hypervisor which is a virtual machine monitor (VMM), that is a software layer that sits between the physical hardware and the virtual machines. It manages and allocates the physical resources of the host machine to the virtual machines so basically you can say that when the kernel is operating its seeing the hypervisor not the physical components. while Docker containers share the host kernel, they achieve isolation through a combination of Linux kernel features such as namespaces and control groups (cgroups), along with user-space tools. Each container operates within its own isolated namespace for processes, networking, filesystem, hostname, and inter-process communication,while resource usage is controlled and limited by cgroups

i agree that if you are talking about performance docker is faster but it all depends on what do you need vm or docker for exactly for testing environments lets say pentesting i would definitely say VM since you have more control and more dedicated env for you, but lets say for service sharing or for tool sharing for something like a tool that needs some specific OS with a specific version of it rather installing a VM use docker you have more performance and easy to handle

i hope i was clear guys !!
 
Мне кажется, ты не совсем понимаешь, что спрашиваешь. Давай конкретизируем, что есть "система для работы". Все зависит от деталей. Сходу скажу, что ВМ часто делают для построения цепочек VPN. В контейнер ты VPN не поставишь, только пробросишь
 
sysnoob сказал(а):
let me explain

in VM you have full control over the limitations of physical sources.
while docker is primary made for containers meaning for sharing a part of your kernel from one device over the other in an easy way

why is it considered a norm to use VM i believe its for security reasons while VM provide isolation between the host and the guest using hypervisor which is a virtual machine monitor (VMM), that is a software layer that sits between the physical hardware and the virtual machines. It manages and allocates the physical resources of the host machine to the virtual machines so basically you can say that when the kernel is operating its seeing the hypervisor not the physical components. while Docker containers share the host kernel, they achieve isolation through a combination of Linux kernel features such as namespaces and control groups (cgroups), along with user-space tools. Each container operates within its own isolated namespace for processes, networking, filesystem, hostname, and inter-process communication,while resource usage is controlled and limited by cgroups

i agree that if you are talking about performance docker is faster but it all depends on what do you need vm or docker for exactly for testing environments lets say pentesting i would definitely say VM since you have more control and more dedicated env for you, but lets say for service sharing or for tool sharing for something like a tool that needs some specific OS with a specific version of it rather installing a VM use docker you have more performance and easy to handle

i hope i was clear guys !!
Can’t docker-compose control the limitations of the content environment, including CPUs/RAM/Shared memory? From your message, I understand that VM and docker are arranged and work differently. I just can't compare the security level of docker and VM. Specific risks when using a docker instead of a VM. Based on what you wrote, the software can take advantage of core/memory vulnerabilities. Thank you for your detailed answer.

r_as сказал(а):
Хорошая тема для обсуждения 👍 Думаю, главный вопрос тут - безопасность. Хотя, некоторые задачи действительно можно просто решить с помощью контейнеров.
Я уже пробовал использовать qubes-os.org. Она позиционируется именно как безопасная система с изоляцией рабочих пространств (кубов) и ограничения их взаимодействия. Но как я понимаю идентичную систему вполне можно построить используя обычные контейнеры. Тем самым сильно прибавив в производительности/функциональности. Спасибо за проявление вашей заинтересованности к этой теме.

infra сказал(а):
Мне кажется, ты не совсем понимаешь, что спрашиваешь. Давай конкретизируем, что есть "система для работы". Все зависит от деталей. Сходу скажу, что ВМ часто делают для построения цепочек VPN. В контейнер ты VPN не поставишь, только пробросишь
Да я не конкретизировал термин, спасибо за замечание. Понятие "система для работы" я раскрою исходя из наборов критериев:
- Возможность использования средств анонимности (tor/vpn/proxy) как для всего *куба так и для отдельного набора его компонентов, включая возможность связывания этих средств анонимности и создание цепочек из них. vpn -> vpn / vpn -> tor / vpn -> proxy etc...
- Изоляция личностей созданных в рамках системы (под личностями вполне конкретно можно понимать набор виртуальных личностей). Програмные средства призванные защитить смешение/пересечение этих личностей
- Возможность создания бекапов системы/отдельных необходимых блоков информации и простота переноса их на новую систему в случае необходимости (ограничим этот критерий сроком переноса в один день)

Эти критерии могут быть дополнены позднее. Что касается использования vpn то я уже установил подобный инструмент в контейнер и он прекрасно работает, ваше утверждение о его НЕработоспособности НЕобосновано.

flatcat8 сказал(а):
hide malware in leg it looking images too ... reddit.com/r/docker/comments/z8vd2f/over_a_thousand_docker_container_images_found/?rdt=52323
Thank you for your response. I read the thread and the research it mentioned. As I have learned from the vulnerabilities found by the researcher, there are several important comments.
1. This is an automatic scan that can have an error.
2. The article did not mention where a set of malicious IP addresses/domain for scanning was obtained.
3. As I understand it, most (if not all) vulnerable images have not been verified on the docker hub.
Therefore, it can be assumed from the observations above that the use of verified images can reduce the attack surface
 
приятно видеть что граждане посвящаются
только стоит помнить что ит это самое модное что может быть вообще тут оно не прощает тормозов
докер и кубернетес 10 лет технологиям
но хотябы произнесли
P.S можно сделать какой то топик с безопасными образами
 
Итак я смог настроить подобную систему, но она так же имеет ряд ограничений для использования.
1. Не все данные можно портировать на другую систему, например не выйдет сделать портирование настроек firefox/chromium. Потому что в папке с конфигом так же хранится unix-socket который нельзя упаковать либо использовать на другой системе.
2. Хост система должна использовать Wayland, при использовании X server система внутри куба будет иметь input-lag на глаз в 50-80мс.
3. Внутри докера очень сложно заставить работать systemd из-за чего пришлось использовать скрипт его эмулирующий, функционально примерно тоже самое
4. Докер так же плохо дружит с dbus, я смог заставить его частично работать, но он не поддерживает часть функций необходимых некоторому софту.

Теперь перейдем к положительным моментам:
1. Работает tor/vpn через nekoray для всей системы с killswitch. Утечек не обнаружено, для гарантии так же развернут firewall.
2. Большинство софта нужного конкретно мне работает исправно
3. Производительность системы идентична нативной и может быть програмно ограничена для нужных значений. При использовании wayland сложно отличить что это вообще приложение из *куба а не с хост системы
4. Очень удобно использовать готовые образы для контейнеров докера. Можно например использовать контейнер с прокси для обхода cloudflare и через него пусить трафик всей системы. Так же относительно просто можно настроить разные системы debian/fedora/arch/nix в разных *кубах под свои задачи.
5. Частичный перенос данных работает исправно, технически можно сделать mount папки с данными которые вам нужны и потом вместе с dockerfile/docker-compose.yml передать на другой хост и развернуть в кратчайшие сроки идентичную систему.
6. Если использовать syncthing то теоретически можно в real-time работать с двумя синхронизируемыми/идентичными системами одновременно, с синхронизацией данных (не проверял)

Если у вас есть какие либо мысли на этот счет, мне будет интересно послушать
 
ValeraSnowdrop сказал(а):
1. Не все данные можно портировать на другую систему, например не выйдет сделать портирование настроек firefox/chromium. Потому что в папке с конфигом так же хранится unix-socket который нельзя упаковать либо использовать на другой системе.
что за сокет? разве настройки не в prefs.js пишутся?

ValeraSnowdrop сказал(а):
Если у вас есть какие либо мысли на этот счет, мне будет интересно послушать
кажется, ты изобрёл аналог firejail или bubblewrap 🤔
 
Dread Pirate Roberts сказал(а):
что за сокет? разве настройки не в prefs.js пишутся?
Верно, технически есть еще user.js который тож часть флагов может хранить. Под портированием настроек я понимал именно перенос всей папки .config . В нашем случае в .config/firefox/** есть сокет, который я не могу упаковать в тот же tar архив и перенести на другой хост.

Dread Pirate Roberts сказал(а):
кажется, ты изобрёл аналог firejail или bubblewrap 🤔
Как я понял это системы именно для создания самого контейнера. Отвечает за cgroups, неймспейсы и т.п. То что сделал я по сути декларативная система, типа nixos но в контейнере, как я понял.

Если вам интересно я могу написать статью как я это сделал, ну и запостить все что смог наделать соответственно.
 
Последнее редактирование:
ValeraSnowdrop сказал(а):
Верно, технически есть еще user.js который тож часть флагов может хранить. Под портированием настроек я понимал именно перенос всей папки .config . В нашем случае в .config/firefox/** есть сокет, который я не могу упаковать в тот же tar архив и перенести на другой хост.
подозреваю, что это особенности докера, я у себя в хомяке "find . -type s" ничего не нахожу.
ValeraSnowdrop сказал(а):
Если вам интересно я могу написать статью как я это сделал, ну и запостить все что смог наделать соответственно.
интересно!
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Отвечая на главный вопрос - "почему ВМ, а не докер?". Потому что вм проще в обслуживании и работе в GUI среде (привычнее для многих пользователей), отсутствие красноглазия и дрочки конфигов.
Насчет проблем докера с systemd, можете посмотреть в сторону Podman. Вот пример настройки podman под wayland с dbus (root + rootless) gist.github.com/eoli3n/93111f23dbb1233f2f00f460663f99e2
Цитата отсюда tproger.ru/articles/podman-alternativa-docker
Демоны – это процессы, которые выполняются в фоновом режиме системы, они обычно работают непрерывно на заднем плане, ожидая определенных событий или запросов.
Возвращаясь к контейнерам, представьте себе демона Docker в качестве посредника, общающегося между пользователем и самим контейнером.
Использование демона для управления контейнерами приводит к нескольким проблемам:
  1. Одна точка отказа.
  2. Когда демон падает, падают все контейнеры.
  3. Требуются привилегии root
Поэтому демоны в Docker — это идеальная цель для хакеров, которые хотят получить контроль над вашими контейнерами и проникнуть в хост-систему.
Podman решает упомянутые проблемы, напрямую взаимодействуя с реестрами контейнеров, контейнерами и хранилищем образов без необходимости в демоне.
Переходя в режим без прав root, пользователи могут создавать, запускать и управлять контейнерами, что снижает риски безопасности.
 
barnaul сказал(а):
wayland с dbus
C dbus поиграюсь еще. Что касается podman, то я уже пробовал его использовать. В докере я считаю важным что есть docker-compose который может объединять контейнеры в одну сеть из которой они доступны друг для друга. Для podman есть podman-compose но он не умеет в паралельную сборку контейнеров, из за чего время сборки линейно растет от количества контейнеров.

Что касается демона Docker, то как я понял это сокет который нужн для управления контейнерами. И может представлять риск только в случае, если я его закину в сам контейнер, либо при возможности внешнего доступа к нему.
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх