Йоанна Рутковска (Joanna Rutkowska), известный польский исследователь в области компьютерной безопасности, после трёх лет разработки представила (http://theinvisiblethings.blogspot.com/2012/09/introducing-q...) первый релиз Linux-дистрибутива Qubes (http://www.qubes-os.org), реализующего идею строгой изоляции приложений и компонентов ОС с задействованием системы виртуализации Xen.Для загрузки доступен (http://wiki.qubes-os.org/trac/wiki/InstallationGuide) установочный образ, размером 1.5 Гб. Для работы Qubes необходима (http://wiki.qubes-os.org/trac/wiki/HCL) система с 4 Гб ОЗУ, 64-разрядным CPU Intel или AMD, желательно с поддержкой технологий VT-d или AMD IOMMU. Из графических карт в полной мере поддерживается только Intel GPU, при использовании NVIDIA наблюдаются проблемы, а работа карт AMD/ATI не протестирована.
Приложения в Qubes разделены на классы в зависимости от важности обрабатываемых данных и решаемых задач, каждый класс приложений, а также системные сервисы (сетевая подсистема, работа с хранилищем и т.п.), работают в отдельных виртуальных машинах. Работа с изолированными программами осуществляется через единый рабочий стол - с точки зрения пользователя, программы запускаются как в обычных системах, а виртуализация плотно скрыта "под капотом". При запуске приложения виртуальное окружение выбирается в зависимости от уровня важности и конфиденциальности данных. Например, для просмотра развлекательных сайтов браузер можно запустить в базовом виртуальном окружении, при выполнении текущих задач - в окружении для работы, а при оплате заказа через платёжные системы - в окружении для совершения конфиденциальных операций. Для наглядного разделения информации о том, в окружении соответствующем какому уровню конфиденциальности запущено приложение используется выделение цветом обрамления окна (например, красным выделяются важные для сохранения конфиденциальности окна, такие как платёжные системы).
<center><a href="http://2.bp.blogspot.com/-zJFn81JdryI/UAqu7H9KSHI/AAAAAAAAAJ... src="http://www.opennet.me/opennews/pics_base/0_1343036494.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border="0"></a></center>
В качестве основы для формирования виртуальных окружений используется пакетная база Fedora 17. Содержание виртуальных окружений определяется набором шаблонов. Настройка и управление работой большинства подсистем Qubes осуществляется через простой графический интерфейс Qubes Manager. Для организации междоменных сервисов задействован механизм Qrexec (http://wiki.qubes-os.org/trac/wiki/Qrexec), который позволяет выполнять команды в контексте заданных виртуальных окружений, например, когда пользователь запускает из меню KDE приложение, это приложение стартует в определенной виртуальной машине.<center><img src="http://www.opennet.me/opennews/pics_base/33010_1328554572.pn... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border="0"></center>
Функциональность корневой системы, обслуживающей Dom0, существенно урезана, для обеспечения работы таких функций как сетевые операции, доступ к хранилищу и формирование графического интерфейса используются отдельные виртуальные окружения, изолированные друг от друга. Каждое окружение для запуска приложений имеет доступ на чтение к базовой корневой ФС и локальному хранилищу, не пересекающемуся с хранилищами других окружений. Для организации взаимодействия приложений и системных окружений используется специальный управляющий сервис. Все данные хранятся в зашифрованном виде, ключ шифрования корневой ФС известен только управляющему окружению, поэтому взлом окружений приложений повлечет за собой потерю контроля только над данными запущенных в текущем окружении приложений, но не над всей файловой системой.
<center><a href="http://theinvisiblethings.blogspot.com/2011/03/partitioning-... src="http://www.opennet.me/opennews/pics_base/30243_1302769645.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="Структура взаимодействия доменов в Qubes" border="0"></a></center>Дополнительно поставляется несколько приложений, специфичных для Qubes. Например, плагин для почтового клиента Thunderbird, позволяющий в один клик открыть вложение в отдельной виртуальной машине или сохранить вложение в любом выбранном виртуальном окружении.
URL: http://theinvisiblethings.blogspot.com/2012/09/introducing-q...
Новость: http://www.opennet.me/opennews/art.shtml?num=34732
Крутая ОС.
Джоанна Рутковская изобрела VM/370 через 40 лет? :-)
а оно было тогда с граф интерфейсом? :)
> а оно было тогда с граф интерфейсом? :)40 лет назад оно было БЕЗ граф. интерфейса! Но сейчас с ним!
Неумолима поступь прогресса! :-)
"Чем новая система лучше старой?" - "У новой цветное руководство!" (с) TRON-2010
Btw... Xen == "микроядро". Domain'ы и OS в них == "процессы-сервера". Вот так при помощи нехитрых инструментов можно из буханки^W того что есть сделать троллейбус^W нечто с дизайном на который так дро^W любители микроядер.
Нет.
эх, видюшка моя не протестирована.. надо будет попробовать систему
для параноиков, компаний и госсектора самое то
Ну если в таком виде, то да. А вообще, на аналогичной системе, под названием СВМ (клон VM/370) мои родители работали на ЕСке.
Как-то подозрительно это всё. В протоколе X11 нет никаких разграничений доступа, любое приложение имеет полный доступ к GUI (может захватывать изображение и посылать события ввода, например).
Насколько я понял по скриншоту, все приложения выполняются в одних иксах.
Сам только что хотел сказать то же самое.
Простенький X11-кейлоггер (которому и root-права не нужны) в руки и вперёд.
Вы владеете тайным кунг-фу. Зачем вам qubes, вперед к взлому хостеров из предоставленных ими виртуалок. А дальше глядишь научитесь взламывать машины тех, кто подключился по ssh, там ведь тоже, о боже мой, полный контроль над терминалом.
Там есть ряд защит от такого, они сильно патчили X-ы.
Статью не читай @ Пиши ерунду
>>Для организации вывода в каждом виртуальном окружении для приложений запускается отдельный X-сервер, упрощённый оконный менеджер и видеодрайвер-заглушка, транслирующий вывод в управляющее окружение в композитном режиме.
Они навелосипедили SPICE?
Для организации вывода в каждом виртуальном окружении для приложений запускается отдельный X-сервер
> Как-то подозрительно это всё. В протоколе X11 нет никаких разграничений доступа, любое
> приложение имеет полный доступ к GUI (может захватывать изображение и посылать
> события ввода, например).
> Насколько я понял по скриншоту, все приложения выполняются в одних иксах.Нет, там на каждую виртуальную машину свой отдельный X-свервер, а на десктопе окна рисуются через что-то подобное VNC.
> Нет, там на каждую виртуальную машину свой отдельный X-свервер, а на десктопе
> окна рисуются через что-то подобное VNC.Ух, ты, хочу так на домашнем компе сделать, чтобы из-под разных пользователей запускать приложения.
> Ух, ты, хочу так на домашнем компе сделать, чтобы из-под разных пользователей
> запускать приложения.Так сделайте. Только вот отдельный пользователь - сильно менее ядреная защита чем отдельная виртуалка.
С правами отдельного пользователя и сейчас можно запускать.
> Ух, ты, хочу так на домашнем компе сделать, чтобы из-под разных пользователей
> запускать приложения.Так запросто.
1. Набери в иксах команду "xhost +" (чтобы временно разрешить всем запускать приложения в иксах, в том числе кому угодно в сети)
2. Залогинься под каким-нибудь пользователем, отличным от текущего (можно залогиниться там же, в иксах, с помощью команды "sudo login -f имяюзера", можно в консоли)
3. Набери под этим новым юзером команду "DISPLAY=:0 cmd", где вместо :0 поставь дисплей (обычно это :0), а вместо "cmd" - нужное GUI-приложение
4. Готово! Только теперь нужно обязательно набрать в исконных иксах "xhost -", а то тебя по сети сломаютЕсли чё, пиши на e-mail
> 1. Набери в иксах команду "xhost +" (чтобы временно разрешить всем запускать
> приложения в иксах, в том числе кому угодно в сети)Тогда уж xhost localhost, а лучше MIT-куку скопировать.
> 4. Готово! Только теперь нужно обязательно набрать в исконных иксах "xhost -"
Соответственно xhost -localhost.
Либо ssh -Y user@localhost app.
> а лучше MIT-куку скопироватьну, предполагалось же как можно проще, а не «как правильно».
через симлесс моуд?
> Нет, там на каждую виртуальную машину свой отдельный X-свервер, а на десктопе окна рисуются через что-то подобное VNC.Т.е. воспроизведение видео жутко тормозит, а об OpenGL можно вообще забыть?
ну так это ж система для параноиков, а не для геймеров и любителей смотреть видео
А также про Gnome3 и Unity
>> Нет, там на каждую виртуальную машину свой отдельный X-свервер, а на десктопе окна рисуются через что-то подобное VNC.
> Т.е. воспроизведение видео жутко тормозит, а об OpenGL можно вообще забыть?IOMMU + Radeon или VT-d + Intel в руки и можешь даже в крузиз гонять.
Там по сути только оконный менеджер один на всех, всё остальное в кажной виртуальной машине своё. Из-за этого и 4 Гб ОЗУ требует для работы.
много ОЗУ оно требует из-за xen'а. Если бы это был котя бы kvm, потребление стало бы на порядки ниже.
Читайте http://qubes-os.org/files/doc/arch-spec-0.3.pdf почему выбрали Xen, а не KVM. Глава
"Xen vs. KVM security architecture comparison", там очень много и подробно расписано. Если кратко - то KVM не полноценный гипервизор слишком завязанный на ядре Linux, по сути VM в KVM является процессом в пользовательском окружении корневой системы.Вывод:
"We believe that the Xen hypervisor architecture better suits the needs of our project. Xen hypervisor is very small comparing to Linux kernel, which makes it substantially easier to audit for security problems. Xen allows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is crucial in Qubes OS architecture. KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support
driver domains."
Там же можно почитать про GUI: Глава 5.3. Qubes GUI architecture
XEN это тоже ядро как и линкс. Dom0 это просто привелегированный, паравиртаулизированный гость. Такую схему можно реализовать и в KVM: минимальное ядро для запуска гостей и полноценные гости.> "We believe that the Xen hypervisor architecture better suits the needs of
> our project. Xen hypervisor is very small comparing to Linux kernel,
> which makes it substantially easier to audit for security problems.Ядро линуска пилят много больше народу -> больше глаз + есть PAX'ы, grsecurity и тд.
> Xen allows to move most of the “world-facing” code out of Dom0,
> including the I/O emulator, networking code and many drivers, leaving very
> slim interface between other VMs and Dom0.Это можно сделать и в KVM. У меня в основной системе нет драйверов сетевых карт, карты пробшены в виртуалки, где и находятся драйвера.
> KVM relies on the
> Linux kernel to provide isolation, e.g. for the I/O emulator process,
> which we believe is not as secure as Xenʼs isolation based
> on virtualization enforced by thin hypervisor.Это всё основнно на идее использовать KVM хост как Dom0. Но, повторюсь еще раз, в KVM можно реализвать такой же Dom0 (гость в который проброшены все железки и консоль управления виртуалками).
> XEN это тоже ядро как и линкс
> Dom0 это просто привелегированный, паравиртаулизированный
> Это можно сделать и в KVM. У меня в основной системе нет
> еще раз, в KVM можно реализвать такой же Dom0 (гость вты абсолютно не понимаешь, то такое xen, зачем он такой, какой есть, как он работает.
[сообщение отредактировано модератором]
> XEN это тоже ядро как и линкс. Dom0 это просто привелегированный, паравиртаулизированный
> гость. Такую схему можно реализовать и в KVM: минимальное ядро для
> запуска гостей и полноценные гости.Вы берётесь рассуждать не понимая что такое Xen. Для начала http://xen.org/files/Marketing/HowDoesXenWork.pdf
The Xen hypervisor is the basic abstraction layer of software that sits directly on the
hardware below any operating systems. It is responsible for CPU scheduling and memory
partitioning of the various virtual machines running on the hardware device. The
hypervisor not only abstracts the hardware for the virtual machines but also controls the
execution of virtual machines as they share the common processing environment. It has
no knowledge of networking, external storage devices, video, or any other common I/O
functions found on a computing system.
А теперь попробуйте описать чем CPU scheduling, memory pratitioning, controling execution of virtual machines отличается от того, чем занимается KVM хост? Да, KVM хост может работать как полноценная ОС, но если установить только qemu и его зависимости, получится "basic abstraction layer".> It has no knowledge of . . . external storage devices, video, or any other common
> I/O functions found on a computing system.Это всё отключается в make menuconfig. :) Для работоспособности девайсов, пробрасывайте их в гостей.
> много ОЗУ оно требует из-за xen'а. Если бы это был котя бы
> kvm, потребление стало бы на порядки ниже.- на "порядки", ха-ха, наверно путаете с Virtuoso/OpenVZ, да и там от силы один порядок набежит. Кроме того актуальные версии Xen используют общие страницы памяти для виртуалок, что позволяет получить экономию ОП на одинаковых виртуалках. Да, и вроде для KVM требуется поддержка виртуализации в процессоре?
> Кроме того актуальные версии Xen используют общие
> страницы памяти для виртуалок, что позволяет получить экономию ОП на одинаковых
> виртуалках.В KVM это появилось раньше (KSM, transparent huge tables).
> Да, и вроде для KVM требуется поддержка виртуализации в процессоре?
Qubes требует не только виртуализацию, но и iommu.
Надеюсь, Qubes Manager попадёт в апстрим проекта KDE, чтобы подобную систему можно было собрать, например, на базе Gentoo.
Надеюсь, как раз не попадет или в худшем случае, будет опционален и по-умолчанию выключен - большинству людей он не нужен, а значит в апстриме тоже (высказанное выше, естественно, имхо).
думал, что до такого идиотизма не доживу. Интересно, рутковская знает о существовании контейнеров
> думал, что до такого идиотизма не доживу. Интересно, рутковская знает о существовании
> контейнеровКонтейнеры работают поверх одного ядра, поэтому не защищены от ошибок и дыр в ядре, что сводит на нет их эффективность. В Xen в каждом VM своё ядро и полная изоляция, вплоть до отдельных VM для сетевых и блочных драйверов.
А в гипервизоре, конечно, дырок нет.
> А в гипервизоре, конечно, дырок нет.Размер кода гипервизора примерно 0.001% от кода ядра.
и он, конечно же, крутится не ядром.
> и он, конечно же, крутится не ядром.В том то и дело, что НЕТ !
в том то и дело, что да. учите мат.часть
Сами учите, даже подскажу где - http://qubes-os.org/files/doc/arch-spec-0.3.pdf
KVM - да, Xen - нет. Xen Dom0 не зависит от ядра ОС.
> и он, конечно же, крутится не ядром.Xen до ядра запускается. Из-за этого куча проблем с драйверами выскакивает.
А на сколько порядков сложнее писать код для гипервизора, чем для ядра ОС?
> В Xen в каждом VM своё ядро и полная изоляция, вплоть до отдельных VM для сетевых и блочных драйверов.Кто-то ведь все равно должен иметь всю функциональность вместе, для работы пользователя.
чем эта херомантия лучше злобно настроенного strict policy selinux?
> чем эта херомантия лучше злобно настроенного strict policy selinux?тем же чем selinux лучше стандартных прав доступа.
> чем эта херомантия лучше злобно настроенного strict policy selinux?Сюрприз, но selinux ничем не помогает против уязвимостей и ошибок, он лишь не даёт сделать больше чем нужно защищаему процессу для работы. SELinux не защитит от экплуатации уязвимости и не поможет недопустить начать рассылать спам или читать файлы пользователей, если атакованный процесс в штатном режиме мог отправлять сетевые пакеты или имел доступ к ФС.
Сюрприз, но Qubes OS ничем не помогает против уязвимостей и ошибок, он лишь не даёт сделать больше чем нужно защищаему процессу для работы. Qubes OS не защитит от экплуатации уязвимости и не поможет недопустить начать рассылать спам или читать файлы пользователей, если атакованный процесс в штатном режиме мог отправлять сетевые пакеты или имел доступ к ФС.
Если сломают защищённый SELinux Firefox то получат доступ ко всем файлам пользователя и всем данным, с которыми пользователь работает из этого браузера.
Если сломают Firefox в Qubes то получат доступ только к данным текущей помойки, доступа к не связанным с браузерной сессией файлам пользователя не будет, не будет доступа к приватным данным (работа с банком производится в другом VM), не будет возможности запустить троянский процесс для мониторинга за пользователем (мониторить можно только браузерную помойку в текущем VM).
>Если сломают защищённый SELinux Firefox то получат доступ ко всем файлам пользователянет
>и всем данным, с которыми пользователь работает из этого браузеракак и Qubes
>мониторить можно только браузерную помойкукак и для SELinux
>>Если сломают защищённый SELinux Firefox то получат доступ ко всем файлам пользователя
> нетвы не правы.
>>и всем данным, с которыми пользователь работает из этого браузера
> как и Qubesнет.
>>мониторить можно только браузерную помойку
> как и для SELinuxнет.
>>Если сломают защищённый SELinux Firefox то получат доступ ко всем файлам пользователя
> нетSELinux выступает в роли фильтра, то что разрешено - остаётся открытым и доступным для взлома на уровне всей системы. В Qubes вводится дополнительная изоляция уровня приложения.
Например, если будет дыра в пропущенном в SELinux системном вызовы, то скомпрометирована будет вся система. В Qubes будет атакован только VM в котором ничего нет, кроме приложения, минимального набора библиотек и принадлежащих приложению файлов.
>>и всем данным, с которыми пользователь работает из этого браузера
> как и QubesВ Qubes, например, данные браузера для работы с банком вообще не пересекаются с данными для чтения почты.
>>мониторить можно только браузерную помойку
> как и для SELinuxВ случае SELinux вся система как на ладони, в Qubes только VM уровня текущего приложения.
точно так же ff можно запустить просто под другим пользователем
> точно так же ff можно запустить просто под другим пользователемВ Android примерно так и делается для изоляции приложений в сочетании sandbox-изоляцией системных вызовов, что вполне хорошо работает.
http://source.android.com/tech/security/ - очень подробно описано что сделано в Android для защиты.
От всего этого изоляция помогает примерно так же, как и SE - всё зависит от правильно выбраной схеме политик/изоляции. Здесь уже встаёт вопрос удобства настройки. SE настраивать явно сложнее, но и виртуализация на XEN слишком топорна и тупа для такой задачи. Да и навряд ли были учтены все варианты выхода из вируатлки.[сообщение отредактировано модератором]
> От всего этого изоляция помогает примерно так же, как и SEPS. Читайте http://qubes-os.org/files/doc/arch-spec-0.3.pdf, там всё написано, почему Xen и почему методы типа SELinux бесполезны.
[сообщение отредактировано модератором]
Осталось скрестить Qubes, SELinux и Liberte Linux (http://www.opennet.me/opennews/art.shtml?num=34724) )))))
Где и что там сказано про selinux?
> Где и что там сказано про selinux?Там аргументировано сказано почему выбрана виртуализация и Xen, а не контейнеры и разные виды изоляции отдельных процессов.
А если не видно разницы, то зачем платить больше?
То же самое можно реализовать через, например, ESXi. Поставил Windows для игр, Ubuntu - для работы и развлечений, Gentoo Hardened в ro-режиме - для конфиденциальных операций в Live режиме, без сохранения изменений. Переключаешься на лету, всё работает... Слишком переусложнённые Qubes получились, если что-то случится в одном из Dom, особенно Dom0 - забудьте про свои накопленные данные (они зашифрованы) и нормальную работу на ближайшее время.
Сейчас немного погонял сие поделие на тестовом стенде: AMD Athlon II X2 255, 4 ГБ DDR3 1600 МГц, NVidia GeForce GT 630. Работать невозможно. Вынул видеокарту, использовал встроенное в материнку видео AMD/ATI - ничего не изменилось, всё так же плохо. Как можно было такое 3 года готовить? Виртуализация съела лучшее время жизни Джоанны...
И ещё: знаменитая "blue pill" - вовсе не её идея, до неё об этом упоминали не раз, например:
http://dl.acm.org/citation.cfm?id=1130383
>в полной мере поддерживается только Intel GPU
Тогда зачем упоминать AMD IOMMU? Эта технология специфична для платформ AMD, Intel там никаким боком не влезет. Или предлагаете видеокарту от Intel в древний PCI-слот втыкать?
> То же самое можно реализовать через, например, ESXiВы наверное щутки шутите. Qubes - ОС для параноиков, а вы проприетарный ESXi в пример привели.
> если что-то случится в одном из Dom, особенно Dom0
С ESXi случится ничего не может?
Параноикам никто не запрещает самим развернуть инфраструктуру Xen и перечисленные выше ОС для своих нужд, переключаясь между ними на лету. А вот доверять некоей Рутковской с её готовыми сомнительными поделиями параноикам не стоит. Либо все исходники просмотреть, вдруг где какая закладочка just for fun оставлена...
Правила взаимодействия виртуальных окружений уже написаны?
По сути ничего нового.Поменяли код ядра линукс, которому не доверяем, на собственный. Сравнение размера линукса с размером гипервизора не корректно. Ко второму нужно добавить собственно qubes. Хотя расклад явно не изменит. :D
Очень удивлюсь, если оно будет удобно (приемлемо) в использовании.
единственное что сделано хорошо в этой самодеятельности это картинки к новости. Давно не видел настолько хорошо оформленного концепта. Остальное (т.е. сам концепт и реализация), конечно же, гогно.
Сайт Qubes испытал на себе Slashdot-эффект. :)))О юзабельности: юзабельна ещё с Beta 2. Работает совершенно шикарно, правда, конечно, за всё надо платить -- ОЗУ кушает немеряно.
Сделали бы не на основе Федоры, а на основе Gentoo Hardened - вот тогда была бы тема.
А этим параною не прикроешь :F
ага, http://www.opennet.me/openforum/vsluhforumID3/86291.html#59
Мдя, на каждое новое поколение железа программеры отвечают несколькими дополнительными слоями абстракции и виртуализации.В результате, то, что раньше прекрасно считалось на счетах, теперь и на суперкомпьютере тормозит :)
> Мдя, на каждое новое поколение железа программеры отвечают несколькими дополнительными
> слоями абстракции и виртуализации.
> В результате, то, что раньше прекрасно считалось на счетах, теперь и на
> суперкомпьютере тормозит :)прув (про "тормозит") или gtfo
Месье тот самый программист? ;)
>> В результате, то, что раньше прекрасно считалось на счетах, теперь и на
>> суперкомпьютере тормозит :)
> прув (про "тормозит") или gtfoЕщё как может тормозить, если совсем не параллелится и сидит на одном ядре.
Схожие грабли у горе-погромистов и в датацентре: http://lwn.net/Articles/441790/
> Схожие грабли у горе-погромистов и в датацентре: http://lwn.net/Articles/441790/потому что инженеров почти никогда не слушают, увы. «а, авось как-нибудь…»
Точно, мертвому припарки ни к чему
Сгласен с dalco, зачем дополнительные слои абстракций, виртуализаций, вообще-то следить за приложениями и за тем чтобы они не совались куда не положено - это работа нормальной ОС. И вместо того чтобы олавливать баги и дыры в ОС, приедется еще ксен полировать, который по сложности примерно как ОС.
>ксен полировать, который по сложности примерно как ОС.вызывающе неверная информация.
> Йоаннафэйспалм с размаху. опеннет не перестаёт радовать перлами «пиривота».
Польский - твой нативный язык?
> Польский — твой нативный язык?а что, так сложно найти, как правильно передавать это имя?
и, кстати, да: увы, я польский знаю. тяжёлое детство, журналы bajtek…
И как же верно?
> И как же верно?смотря откуда брать. если с английского — то Джоанна. если не с английского — то, например, Иоанна (как Хмелевская). или Яна (но это уже спорно).
Это вы опозорились, они из Польши, Joanna читается как Йоанна
http://ru.wikipedia.org/wiki/%D0%A0%D1%8...,_%D0%99%D0%BE%D0%B0%D0%BD%D0%BD%D0%B0
> Это вы опозорились, они из Польши, Joanna читается как Йоаннаа «Paris», видимо, следует писать как «Парис».
я все же так и не понял.. проще запускаем XP in VirtualBox, делаем шо надо, откатываем снапшот не ?? а тут 4 Гб подай 64bit..
Если не считать уязвимости в ядре, то можно сделать проще, на AppArmor, например.
О чем я писал давным-давно на хабре - http://habrahabr.ru/post/113143/
