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

Продолжение начала конца

Andy Updegrove анализирует Новелловскую форму 8-K: http://www.consortiuminfo.org/standardsblog/article.php?story=20101124103213556

  • Сделка имеет форму "обратного треугольного слияния" -- Attachmate создаст пустышку, которая по завершении сделки вольется в Novell, а не наоборот. Это стандартная форма защиты компании-поглотителя от неизвестных проблем поглощаемой компании.

  • За вычетом 450млн за патенты для CPTN, имеющегося Новелловского кэша в 1.09млрд, на долю продаваемого старого Новелла останется около 660млн. Attachmate вкладывает существенно меньше 660млн в сделку, поскольку Elliot Associates сохранит свой пакет в старой компании в ее новой форме.

  • Условия завершения сделки можно трактовать так, что Attachmate использует 450млн, которые выплачивает CPTN (консорциум под руководством Microsoft), чтобы расплатиться за Novell.

  • Скорее всего этот оборот -- попытка Microsoft продлить патентное соглашение, которое истекает в 2011, и в то же время не подставиться опять в антимонопольном процессе. Потому и консорциум, а не напрямую.

  • Судя по 8-К, самим Attachmate придется затратить 425млн своих денег (плюс оперативные расходы), которые они постараются также отбить через последующие продажи по частям того, что останется.

  • По всей видимости, продажа патентов в CPTN -- это не полная и безоговорочная передача прав, а какое-то их перераспределение между Новым Новеллом и CPTN, видимо, аналогично предыдущему патентному соглашению, но с большим перекосом в сторону CPTN/Microsoft.

  • Интересно. что если кто-нибудь до завершения сделки с Attachmate предложит лучшую цену, то CPTN может остаться совсем без патентов, но не в случае, если в новой покупке будет использоваться та же схема, как и с Attachmate -- в этом случае у CPTN есть право, но не обязанность, сделку заключить.

  • Однако, если сделка с Attachmate совсем сорвется, то у CPTN будет право выбрать себе что-нибудь (хоть все 822) из патентного портфолио старого Новелла. При этом Новелл все равно получит 450млн и, возможно, что-то из портфолио CPTN, если таковое будет создано. То есть, Microsoft в этом случае получит вечные лицензии на патенты Новелла, а если пожелает, то даст Новеллу вечные лицензии на какие-то из своих патентов, "влитых" в CPTN.

  • Последнее также означает, что CPTN скорее всего формируется как противовес Open Invention Network -- механизм для формирования пула патентов, с правами лицензирования их всеми участниками консорциума. Скорее всего, результатом будет увеличение "акций по принуждению", направленных на лицензирование этого пула (или его части).



Более подробно о сделке мы узнаем из того пакета документов, который Новелл обязан разослать всем своим владельцам акций (сделка должна получить большинство голосов владельцев акций) и из отчета 10-К, который Новелл будет обязан предоставить в SEC по результатам своего финансового года. Уже сейчас есть как минимум два групповых иска от владельцев акций, которые считают, что сделка менее выгодна, чем предыдущее предложение от Eliott Associates и обвиняют совет директоров в пренебрежении интересами акционеров.

Update: http://www.novell.com/company/ir/message.html
Novell will continue to own Novell’s UNIX copyrights following completion of the merger as a subsidiary of Attachmate.