Category: it

Category was added automatically. Read all entries about "it".

Speaker Rabbit

Как нашли Badlock

После насыщенного бессонными ночами и напряженной работой месяца, мы выпустили обновления Samba для закрытия дыр Badlock. Я написал статью в блог Red Hat Enterprise Linux, где рассказываю о том, что это такое и как его открыли.
Speaker Rabbit

Roslyn

Микрософт опубликовала исходный код своей платформы компиляторов C# и F# под лицензией Apache License 2.0: http://roslyn.codeplex.com/

Это серьезный сдвиг, оправданный прежде всего с точки зрения бизнеса компании. Думаю, что metaclass теперь может возрадоваться и для своих бухгалтерий собрать свою платформу, и не с простыми червями, а с генетически модифицированными.
Speaker Rabbit

Охлох по-русски

Есть в России и такое: https://www.facebook.com/alena.vladimirskaya/posts/3791109369189

Для нежелающих смотреть в FB, дама-хэдхантер спрашивает, почему Хабр не сделает свой github для русскоязычных программистов "из провинции" и не монетизирует статистику их взаимодействия.

Ей там многое написали, включая "вон из профессии тех, кто не знает что такое и как пользоваться github", но меня интересует другой момент.

Всегда будут те, кто не может или не хочет использовать какие-то конкретные площадки. Хотелось бы понять, как предоставление хостинга проектов на русском языке и интеграция со статистической пузомеркой может помочь вытянуть людей "из провинции", которые сейчас не хотят выкладывать свои работы публично или не имеют для этого времени, не заинтересованы в этом эксгибиционизме, но хотят найти работу. Эти люди и так не идут дальше публикации резюме с непроверяемыми данными о своем трудовом пути. Что они будут делать с новой игрушкой?

Если этот ресурс будет предоставлять коммерческий хостинг для проектов тех индивидуалов, которые не хотят публиковать свой исходный код, то на основании чего ресурс будет использовать статистику коммитов в такие проекты и непубличную тусовку вокруг них для сводничества? Понятно, что условия хостинга можно в том или ином виде определить и заложить в рамки договора, но будет ли доверие со стороны потенциальных пользователей системе хостинга, чья основная задача будет состоять в накоплении информации, которую они сознательно хотят скрывать, раз уж выбрали непубличность своего репозитария, а, следовательно, и непубличность взаимодействий с ним.

Чем такой ресурс/проект может завоевать признание и доверие непубличных пользователей?
Speaker Rabbit

Заначка

Согласно пункту 3.1.5.16 спецификации MS-FSA, "объектное хранилище ДОЛЖНО выставить Open.File.SecurityDescriptor в InputBuffer". Как результат, том NTFS должен хранить как есть данные, записанные приложением в DACL файла. Размер одной записи в ACL -- до 64Кб. Если учесть, что обычными средствами увидеть содержимое этих дополнительных записей невозможно, то вышеописанное представляет собой идеальный способ сокрытия данных на томах WinFS.

Такие дела, в изложении Микрософт: http://lists.samba.org/archive/samba-technical/2012-April/082770.html

Интересно, в специализированном ПО для forensic analysis этот случай учитывается? Если нет, то когда будет учитываться? На постсоветском пространстве эксперты соответствующего профиля о таком знают? А свядомые догадываются?

Теперь это реализовывать в Самбе... Bug for bug, feature for feature. :)
Speaker Rabbit

trust_fetch(): SUCCESS

Скелет начинает обрастать мясом. Одной из важных частей будущего FreeIPA v3.0 является возможность настраивать доверительные отношения с доменами Active Directory. Все это для того, чтобы пользователи FreeIPA и пользователи AD считались в обеих системам доверенными и не надо было их между собой синхронизировать. Теоретически, для того, чтобы это все работало, необходимо "лишь" использовать Kerberos. Проблема в том, что AD считает необходимым атрибутом доверительных отношений ответы по тем протоколам, которые она использует для своей внутренней деятельности. То есть, в первую очередь CLDAP и CIFS, причем так, что контекстуально информация, переданная по одному каналу (например, Kerberos протокол) должна быть понятна и в рамках запросов, использующих другие протоколы (CLDAP, LSA RPC). Это означает, что сервер Kerberos и другие службы как бы работают под одним крылом.

Для решения этой проблемы в Samba4 уже давно реализуются свой LDAP-сервер (и CLDAP в нем) и свой встроенный Kerberos-сервер (на основе Heimdal). Для того, чтобы внешние реализации LDAP и Kerberos могли бы обеспечить аналогичную функциональность, необходимо научить Samba отдавать некоторые операции наружу. В CIFS для этого теоретически существует end-point mapper, аналогичный RPC map для Sun RPC. То есть, один порт слушается smbd, а затем приходящие запросы раскидываются на обработчиков в отдельных процессах. На реализацию работающего диспетчера внешних обработчиков ушло несколько лет в Samba3, этот код стал стабильным относительно недавно.

Для того, чтобы установить доверительное отношение между двумя доменами достаточно не так и много вызовов. Создается пароль для доверительного отношения и, используя необходимые административные привилегии, отправляются два запроса LSA RPC CreateTrustedDomainEx2 -- к нашему серверу домена и к сервер доверяемого домена. Фактически, из основных требований здесь только административный доступ к чужому домену. В Samba3 в утилите net есть специальный раздел 'net rpc trust', который позволяет установить это самое доверие вручную. Утилита предполагает, что она запущена на своем же сервере с правами привилегированного пользователя, поскольку при работе ей требуется запись в некоторые базы данных Samba3, права на запись в которые выданы только руту, а открывает эти базы она самостоятельно.

В случае FreeIPA сам сервер FreeIPA, который занимается настройкой остальных сущностей, запущен как WSGI процесс, работающий под непривилегированным пользователем. При обращении к нему по XML-RPC или JSON со стороны клиента происходит делегирование имеющегося пользовательского билета Kerberos, на основании которого сервер FreeIPA и обращается к различным службам от имени этого пользователя. Службы в этом случае должны понимать авторизацию силами Kerberos, но сами по себе они работают тоже под непривилегированными пользователями, отличными от того, под которым работает WSGI процесс. Коммуникация между процессами идет средствами Unix domain sockets. То есть, использовать net rpc trust для установления доверительного отношения не получится, поскольку утилита net, запущенная из под пользователя apache, не сможет открыть напрямую соответствующую привилегированную базу, права на доступ к которой есть только у root. Впрочем, если бы они были у кого-то другого, это тоже было бы невозможно без принудительной выдачи прав на запись пользователю apache, что ломает всю стройную картину разделения прав.

У Samba4 есть автоматически генерируемые питоновые модули для довольно большой часть внутренних библиотек. Эти модули позволяют реализовать практически весь функционал 'net rpc trust' самостоятельно, обращаясь из кода на Питоне, запущенного под каким угодно пользователем, к соответствующим CIFS серверам, в том числе и локальному, работающему на том же сервере, что и FreeIPA. Беда только в том, что все эти модули не имеют нормальной документации и довольно неустойчивы к некорректным данным.

Это было введение. После некоторого количества итераций и патчей, как к FreeIPA, так и к Samba, удалось, наконец, реализовать подход, при котором все операции по установлению доверительных отношений выполняются из-под непривилегированного пользователя с применением делегированного билета администратора. Вот как выглядит простой запрос информации о домене (LSA RPC OpenInfoPolicy2), необходимый для определения параметров для заполнения запросов на установление доверительных отношений:Collapse )

Осталось дописать вызовы для установления доверительных отношений в код модуля FreeIPA и большая часть функционала для FreeIPA v3.0 будет реализована.
Speaker Rabbit

Бесконечная автоматизация

Конечные автоматы бывают разные. Есть генераторы исходного кода по схемам-описаниям, есть табличные исполнители, а есть неявные конечные автоматы. Они сложнее, но читаются как детективный роман -- со множеством веток предположений и откатов на исходные позиции, а так же с необходимостью найти на них время. Неявные конечные автоматы в разных проектах -- это то, что одновременно удерживает от прихода новых участников (нужно уметь раскручивать детективный сценарий) и позволяет глубже понять, что и как задумывалось. Разгадав очередной автомат, получаешь вполне осязаемое удовлетворение.
Collapse )
Speaker Rabbit

HBAC в SSSD/FreeIPA (часть 2)

Написал модуль для тестирования HBAC:
https://www.redhat.com/archives/freeipa-devel/2011-July/msg00375.html

1. Симулируем доступ к службе, используя все включенные правила в IPA:
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh
--------------------
Access granted: True
--------------------

2. Симулируем доступ к службе, используя все включенные правила + указанные в --rules (возможно отключенные):
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule
--------------------
Access granted: True
--------------------

3. Симулируем доступ, используя только правила, указанные в --rules (--validate ограничивает список правил только теми, что в --rules):
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,new-rule --validate
--------------------
Access granted: True
--------------------
  Passed rules: new-rule
  Denied rules: my-second-rule

4. Симулируем доступ и получаем подробный отчет, какие из включенных в IPA правил сработали:
[root host0 ~]# ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh  --validate
--------------------
Access granted: True
--------------------
  Passed rules: allow_all
  Denied rules: my-second-rule, my-third-rule, myrule

--validate включает детальный показ результатов применения правил, а если используется вместе с --rules, то ограничивает список проверяемых правил только указанными в --rules.

По всей видимости, --validate нужно переименовать во что-то иное (--detail?) и перекрыть --all для указания того, что к --rules надо добавить все включенные правила в IPA, иначе логика не очень ясна, по крайней мере, коллега уже успел ошибиться при тестировании.
Speaker Rabbit

HBAC в SSSD/FreeIPA

Немного о том, чем я сейчас занят. Записи с тегом "заметки-на-полях" -- моя внутренняя кухня, не предназначенная для активного обсуждения и цитирования вне этого ЖЖ. Мой мозг пока с трудом привыкает к большому объему нового (и вспоминанию старого) кода, поэтому заметки скорее для себя, чем разъяснения для других. Если объем превысит выделяемое самим собой время, я просто отключу комментарии, чтобы не отвлекаться, не обессудьте.

Collapse )
Speaker Rabbit

Контейнеры

Бойцы из НезлойИмперии пытаются родить новый формат изображений, WebP. За основу взят кодек VP8 и контейнер RIFF. Желание поскорее использовать VP8 для замены JPEG так велико, что бойцы совсем забыли вторую важную часть любого внятного формата изображений: хранение мета-данных. Я даже могу представить, что ими двигало: предложенные четыре блока мета-данных ICMT, ICOP, IART, INAM без какой-либо спецификации содержимого (кодировка, ожидания по структуре, ...) явно базируются на аналогичных блоках из спецификации PNG.

Если посмотреть на проблему серьезнее, то EXIF+IPTC+XMP сегодня описывают порядка нескольких сотен тегов. Если для каждого из них выделять отдельный блок в контейнере, указывать точные структуры хранения и кодирования, то загнутся реализаторы, а формат просто никто не будет внятно поддерживать.

Игнорирование мета-данных в изображениях в данном контексте отражает общий подход клиентской стороны гугловцев. Лишь относительно недавно в Picasa появилась полноценная поддержка XMP. Параллельного слияния тегов из разных контейнеров у них нет до сих пор (например, title/description могут храниться во всех трех указанных выше типах хранилищ мета-данных в одном изображении -- что делать, если пользователь хочет изменить title, какое из хранилищ будет приоритетным, как изменить данные в остальных?). Теперь Хром хочет ускориться за счет уменьшения объема перекачиваемых данных (это единственная фича, которую объявляют стоящей для себя разработчики WebP). Для браузеров мета-данные в изображениях бесполезны, API доступа к таким данным в рамках спецификаций W3C просто отсутствуют. Вот и рождается очередной контейнер-недоконтейнер. WebM, кстати, тоже поддержку мета-данных зажилил.