Re: Выбор технологии ограничения сетевых приложений.
Доброго времени суток, Artem. Спасибо за ответ, Wed, 05 Nov 2014 16:49:08 +0300 вы писали: Чисто с точки зрения изоляции самих систем годится любая. Можно еще Меня смущает, например, что контейнеры используют одно ядро с основной ОС, - тогда как, например, ЯВМ уже использует полностью свою установку ОС. - Т.е., на мой взгляд, Я(дерная)ВМ, более безопасна в случае проникновения к данным ч/з уязвимость в ядре, -- опять же, не к данным основной (домашней) ОС. virtualbox-ose, пакет в дистрибутиве есть. Но будет неудобно. В смысле, если речь идет о защите, то для надежности нужно еще и лишить эти две системы возможности общаться через Xserver. А это как раз неудобно. Да я и не хочу с рабским (не свободным) ПО связываться! Ну и вопрос о необходимых возможностях графики. Тут тоже сетевую систему придется сильно ограничить (полноценный доступ ее к аппаратуре - это не то, к чему ты стремишься), и в результате может не получиться, например, нормально посмотреть видео с ютуба. Да к этому я как раз и стремлюсь: обрезать изолированной ОС/приложениям доступ ко всему по-максимуму. Естественно, что про 3М-ускорение речи не идёт, как и больших вычислительных нагрузок, на изолированное окружение возлагаться не б/т. С уважением, Ста. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106152346.77d1271f@STNset
Re: Выбор технологии ограничения сетевых приложений.
Доброго времени суток, Руслан. Спасибо за ответ, Wed, 5 Nov 2014 22:18:02 +0500 вы писали: Благо что UNIX изначально создавался как многопользовательская система и этим можно воспользоваться. Да, но не микроархитектурная, как Хурд. 1. Заводим двух новых пользователей, например user-internet, для работы с сетью и user-desktop для работы с локальными приложениями. 2. Расставляем нужные права доступа на домашние каталоги пользователей. 3. PROFIT Поэтому, язвимости, например, в ядре, не спасут разделение по пользователям, в то время как в микроархитектуре, ядро с доступом к данным, к. н/о обезопасить, просто не обладало бы доступом к Сети. :о/ С уважением, Ста. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106152651.6651e56a@STNset
Re: Выбор технологии ограничения сетевых приложений.
Ста Деюс - debian-russian@lists.debian.org @ Thu, 6 Nov 2014 15:23:46 +0700: Чисто с точки зрения изоляции самих систем годится любая. Можно еще СД Меня смущает, например, что контейнеры используют одно ядро с основной СД ОС, - тогда как, например, ЯВМ уже использует полностью свою установку СД ОС. - Т.е., на мой взгляд, Я(дерная)ВМ, более безопасна в случае СД проникновения к данным ч/з уязвимость в ядре, -- опять же, не к данным СД основной (домашней) ОС. Ну, через уязвимость в ядре может пробиться любая виртуальная система - поскольку любая из них будет в итоге пользоваться услугами ядра. Причем нынче уже все, включая даже qemu, довольно близко допускают гостевую систему до процессора. Единственное исключение - это как раз qemu в режиме эмуляции несовместимой архитектуры. Но работает он при этом настолько НЕБЫСТРО... Хотя вариант с KVM или virtualbox представляется более безопасным, чем LXC. virtualbox-ose, пакет в дистрибутиве есть. Но будет неудобно. В смысле, если речь идет о защите, то для надежности нужно еще и лишить эти две системы возможности общаться через Xserver. А это как раз неудобно. СД Да я и не хочу с рабским (не свободным) ПО связываться! Это неудобно вне зависимости от степени свободности ПО. И эта, VirtualBox is a free x86 virtualization solution allowing a wide range of x86 operating systems such as Windows, DOS, BSD or Linux to run on a Linux system. У него есть несвободные компоненты, но они как раз для той интеграции, которая снижает безопасность. Ну и вопрос о необходимых возможностях графики. Тут тоже сетевую систему придется сильно ограничить (полноценный доступ ее к аппаратуре - это не то, к чему ты стремишься), и в результате может не получиться, например, нормально посмотреть видео с ютуба. СД Да к этому я как раз и стремлюсь: обрезать изолированной ОС/приложениям СД доступ ко всему по-максимуму. Естественно, что про 3М-ускорение речи не СД идёт, как и больших вычислительных нагрузок, на изолированное окружение СД возлагаться не б/т. flash-player тогда не ставь ни в какой позе. А то ВНЕЗАПНО окажется, что на изолированное окружение без спросу возложили большую вычислительную нагрузку. Проверено, мин есть. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877fz8qzew@wizzle.ran.pp.ru
Re: Выбор технологии ограничения сетевых приложений.
Ста Деюс sthu.d...@openmailbox.org writes: Доброго времени суток. Хочу спросить вашего совета с целью выбора наиболее безопасного варианта. Идея: разделить функционал использования ЭВМ: сетевые приложения пользователя (паутина, почта, болтовня в РВ, и т.п.) и остальные настольные приложения -- с целью обезопасить данные от возможных проникновений их Сети . -- Хорошо бы использовать две ЭВМ, но сейчас вопрос стоит осуществить, пусть более опасное решение, но на одной ЭВМ. Я остановился на рассмотрении технологий: KVM, Xen, изолированный контейнер. Но, может, вы иное предложите. Итак, какую технологию вы бы посоветовали и почему? Как уже правильно заметил Артём Чуприна, с точки зрения безопасности подойдёт любая из систем. Надо всё-таки понимать, что даже если Ваш, например, браузер, загружает из сети и тут же выполняет без проверки какой-нибудь вредоносный JavaScript, или несвободный flash-плагин из-за очередной уязвимости допускает атаку на Вашу систему, - в 99% случаев эксплоиты такого рода окажутся заточены под атаку хост-системы, и не будут пытаться выйти за границы песочницы. Именно для этих задач разрабатывался schroot. Он позволяет создать энное количество песочниц, в которых непривилегированные пользователи смогут запускать приложения. Предоставляется довольно высокая степень изоляции: Вы можете, например, не предоставлять виртуальному окружению доступа к /dev или /tmp. Есть мнение, что полноценные виртуалки надёжнее, но с этим утверждением можно и поспорить. К тому же, не все процессоры поддерживают виртуализацию, и запуск полноценных виртуалок на них - задача очень накладная. Единственный минус изолированного запуска программ - это общение со внешней системой. Вот загрузили Вы, например, pdf-файл, а в браузере нет кнопки открыть в evince, потому что evince у Вас во внешней системе. Естественным способом общения с такой программой будет связанный каталог (например ~/tmp), доступный из обеих систем одновременно. pgp1JbQT6ne39.pgp Description: PGP signature
Re: Выбор технологии ограничения сетевых приложений.
Доброго времени суток, Денис. Спасибо большое за ответ, Wed, 05 Nov 2014 20:59:29 +0200 вы писали: Посмотрите в сторону Qubes: https://qubes-os.org/ Возможно не придется изобретать велосипед. Очень интересный проект! Однако, я хотел бы остаться с поставкой «Дебиан»а, поэтому, и ищу доступные ей технологии. -- Ведь «Дебиан» тем и хорош, что есть много поддерживаемых командой безопасности пакетов, а из это ОС, к. вы указали, м/о подчерпнуть искомую мною технологию: «Ксен», и настройки, к. они сделали. Ещё раз спасибо за указание на сей проект! С уважением, Ста. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107114759.431b5557@STNset
Re: Выбор технологии ограничения сетевых приложений.
Доброго времени суток, Artem. Спасибо за ответ, Thu, 06 Nov 2014 15:36:07 +0300 вы писали: Хотя вариант с KVM или virtualbox представляется более безопасным, чем LXC. Вот и мне нравится в плане безопасности, что ЯВМ стоит дальше от ядра основной ОС. СД Да я и не хочу с рабским (не свободным) ПО связываться! Это неудобно вне зависимости от степени свободности ПО. И эта, VirtualBox is a free x86 virtualization solution allowing a wide range of x86 operating systems such as Windows, DOS, BSD or Linux to run on a Linux system. У него есть несвободные компоненты, но они как раз для той интеграции, которая снижает безопасность. У меня есть неприятный опыт использования этого ПО: не работало ус-во через порт УСБ, вываливался сервер «Х», сильно грузилось ЦПУ -- но и не в этом главная причина, а в том ощущении, что это рабское ПО -- я попробую объяснить: есть разница в установке/использовании свободного и рабского ПО -- в свободном есть свобода действий, а в рабском то, что доктор прописал -- т.е. понуждения делать что-то против своей воли. -- В чём именно дело было, я уже точно не скажу, но то, что это было -- это факт для меня. Помимо того, что это РПО пишет такая гнусная контора как «Оракул» -- например, именно им мир обязан разделению популярного конторского пакету на «апач» и «либре». Мне кажется, это всё равно как, со временем, быть может, использовать «микрософт линукс». :о) Ну, это всё моё мнение, все могут его не разделять, и на то и не претендую. Эта тема не о РПО, в частности, «Виртульной коробке». СД Да к этому я как раз и стремлюсь: обрезать изолированной ОС/приложениям СД доступ ко всему по-максимуму. Естественно, что про 3М-ускорение речи не СД идёт, как и больших вычислительных нагрузок, на изолированное окружение СД возлагаться не б/т. flash-player тогда не ставь ни в какой позе. А то ВНЕЗАПНО окажется, что на изолированное окружение без спросу возложили большую вычислительную нагрузку. Проверено, мин есть. Договорились! :о) С уважением, Ста. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107120118.687d5b1b@STNset
