SATtva Персональная страница
темы архив все rss xml 2.0
 
 
блог
досье
связь
english
 

Из позднего

20.12.2008
blender

Новое 3d-творчество.

image

Оправдание гигагерцам

07.10.2008
blender

Теперь я знаю, зачем компьютерам гигагерцевые процессоры. Как оказалось, не только для игрушек или пересборки мира (привет гентоводам!), а ещё и для рендеринга 3d-сцен. В конце августа в процессе перевода дизайн-студии на свободное ПО открыл для себя мир Blender'а, а недели четыре назад -- и мир Indigo. Миры оказались довольно увлекательными и вызвали неслабый поток креатива, одно из порождений которого представляю ниже.


image


image


image


image


image


image


image

Медицинские данные в электронном виде

24.07.2008
security

Европейский суд по правам человека вынес решение по делу женщины, работавшей медсестрой в финской клинике. Учреждение отказалось продлить контракт с истицей, ВИЧ-положительной, после того, как слухи о её заболевании поползли по больнице. Сведения о её диагнозе хранились в больничной базе данных. Неудивительно, что база имела недостаточные средства для контроля доступа медперсонала и недостаточные средства аудита, чтобы зафиксировать, кто злоупотребил полномочиями и через кого произошла утечка. Суд постановил, что медицинские данные пациента должны быть доступны исключительно лечащему врачу.

Компьютерные гиганты идут в направлении тех же граблей с сервисами Google Health и Microsoft HealthVault. Разумеется, их privacy policy чёрным по белому утверждает, что только пользователь будет определять круг лиц с доступом к своим медицинским данным. Что ж, здесь хотя бы имеют место взятые на себя обязательства.

А что же у нас? А у нас с полей победно рапортуют об электронизации страны:

В скором времени в российских медучреждениях будут внедрены компьютерные медицинские системы, позволяющие заменить "бумажные" истории болезни на цифровые. Такие системы помогут значительно улучшить качество медицинского обслуживания: на 30-50% снизится количество врачебных ошибок, врачам станет проще разбираться в назначениях друг друга, а пациентам не придется тратить много времени в очередях в регистратуру и на прием.

И ни слова о безопасности. Характерно, что истории болезни не относятся у нас к врачебной тайне как таковой, да и последняя формально не подлежит обязательной защите как приватная, сугубо личная информация.

Лет пятнадцать назад я некоторое время жил в одном маленьком российском городке, где в то время местные компьютерные умельцы перевели медицинский архив главной горбольницы в электронный вид. Только о каком-либо контроле доступа подумать забыли, и все медицинские записи были доступны любому человеку с удалённым доступом к больничной интрасети (включая тамошних админов и членов их семей). Время было давнее, дикое. Теперь-то всё будет по-другому, ага.

Шифрование дисковых разделов действующей Linux-системы

16.07.2008
линукс

Предпочтительный подход к шифрованию дисковых разделов Linux-систем заключается в их подготовке на этапе инсталляции дистрибутива, что реализовано во многих из них или может быть выполнено вручную с помощью большого разнообразия руководств (например, исчерпывающая инструкция для Генты). Так минимизируется риск утечки открытого текста при последующем переходе на шифрование системы. Однако, зачастую пользователь приходит к необходимости шифрования диска уже в процессе работы с системой, в связи с чем возникает закономерная проблема: как произвести операцию за минимальный срок и с минимальным ущербом для системы в её текущей конфигурации.

Простейшее решение, наиболее пригодное для обычных дистрибутивов, а не custom-систем собственной сборки, -- сделать на внешнем носителе зашифрованную копию /etc и /home, затем многократно перезаписать разделы с ценными данными (простым dd или wipe/shred) и, наконец, переустановить систему, но уже с шифрованием диска. После чего можно восстановить пользовательские данные и системную конфигурацию из резервной копии.

Такое решение, однако, менее пригодно для той же оптимизированной Генты, где перекомпиляция свежеустановленной системы может занять до нескольких десятков часов машинного времени. Как одно из решений для такой ситуации можно предложить изготовление Stage4. Если есть, куда положить готовый стейдж на время работы с диском. Также в этом случае понадобится альтернативная система (скажем, LiveCD), из которой будет выполняться работа. В остальном порядок операции тот же, как описанный в предыдущем абзаце.

Третье решение, которое лично мне нравится больше, требует наличия на жёстком диске (на основном или подключаемом) некоторого свободного места. Сколько? Столько, сколько занято на самом заполненном из ваших разделов (в абсолютных величинах, а не в процентном соотношении); вы ведь не пихали всю систему на один раздел, не так ли? Помимо сравнительно небольшого количества свободного места этот вариант требует некоторых телодвижений, зато позволяет производить операцию в несколько присестов, т.е. совершенно без простоя работы. Итак:

0. С помощью fdisk/cfdisk создайте дисковый раздел (предположим, что это /dev/sda10, будем называть его временным) такого объёма, чтобы туда поместилось содержимое из самого заполненного раздела. Зашифруйте раздел с помощью cryptsetup, отформатируйте под ext2 и монтируйте в произвольную точку (пусть это будет /dev/mapper/tmp, а монтировать его будем в /mnt/tmp). (Пытливый читатель может самостоятельно прибегнуть к Reiser4 со сжатием, чтобы ещё более снизить требования к объёму раздела.)

1. Выберите любой из дисковых разделов, исключая содержащий корневую ФС (допустим, /usr), скопируйте его содержимое в /mnt/tmp.

2. Отредактируйте /etc/fstab, указав для точки монтирования /usr устройство /dev/mapper/tmp, и перемонтируйте файловую систему.

3. Дисковый раздел, где /usr находилась изначально, многократно перезапишите (чтобы исключить восстановление открытого текста, хотя для таких разделов, как /usr, это может быть и не критичным), зашифруйте, отформатируйте, подмонтируйте (теперь это будет криптоустройство /dev/mapper/usr, смонтировать можно в ту же /mnt/tmp) и перенесите обратно файлы из временного раздела (который сейчас смонтирован как /usr).

4. Повторно измените настройки fstab: теперь для точки монтирования /usr нужно указать устройство /dev/mapper/usr (или как вы его назвали). Перемонтируйте файловую систему.

5. Укажите в настройках dmcrypt (/etc/conf.d/dmcrypt или в ином месте, в зависимости от вашего дистрибутива) нечто подобное:
target=usr
source='/dev/sda5'

Теперь раздел /usr полностью зашифрован. Повторите шаги 1-5 для остальных файловых систем, кроме корневой. После завершения работы над каждым разделом можно свободно перезапускать компьютер, если в том возникает потребность, но не делайте это до окончания шага 5.

Прежде чем зашифровать корневую ФС, необходимо создать initramfs. Описание этого процесса выходит далеко за рамки этого поста и подробно изложено, в частности, в отмеченном в начале руководстве. Более того, гентушная утилита genkernel автоматически создаёт подходящий образ initrd (в этом случае убедитесь, что cryptsetup собран статически, т.е. без use-флага dynamic). Имейте в виду, образ initrd от genkernel не поддерживает работу с ключами, зашифрованными GnuPG; если нужна такая функциональность, образ придётся допиливать вручную (это тема для отдельного поста, если кто-нибудь выкажет интерес в материале).

Когда initrd будет готов и работоспособен (обязательно проверьте, загружается ли с ним система), можно завершить зашифрование корневой ФС. На всякий случай запаситесь LiveCD (очень желательно, если с cryptsetup; Gentoo LiveCD 2008 его содержит), с которого в экстренном случае можно будет исправить настройки загрузчика и fstab. Затем:

1. Выполните шаги 1 и 2 (список выше), но без перемонтирования ФС.

2. Внимательно настройте загрузчик, используя опции initrd (их вы можете найти в руководстве, по которому создавали образ; если использовали genkernel, смотрите man, раздел INITRD OPTIONS). Зачастую, это что-то вроде
kernel /boot/kernel init=/init root=/dev/ram0 crypt_root=/dev/sda10
initrd /boot/initramfs
(Обратите внимание на /dev/sda10 -- это пока зашифрованная копия корневой ФС из временного раздела.)

3. Перезагрузите машину. Если всё пройдёт нормально, вам будет предложено ввести пароль к загрузочному разделу. Если нормально не пройдёт -- запускайте LiveCD, возвращайте назад настройки fstab (с незашифрованной копии корневой ФС) и загрузчика и ищите причину проблемы.

4. После успешной загрузки выполните шаги 3 и 4 (тоже по первому списку), опять же, без перемонтирования ФС.

5. Перенастройте загрузчик, чтобы теперь crypt_root указывал на постоянный раздел с корневой ФС (вероятно, это /dev/sda1, но очень может быть и иначе). Пункт 5 из первого списка для корневой ФС не нужен. Можете перезагружать машину.

Если загрузка пройдёт штатно, удалите временный раздел. Вот и всё, собственно. До новых встреч.

Ниже -- пара частых вопросов. Не столько по содержанию этой краткой инструкции, сколько по опыту общения с людьми на данную тему.

А какой смысл в том, чтобы шифровать систему целиком, если реально ценные данные лежат у меня только в /home?

Оставляя незашифрованными, скажем, /usr или /etc, пользователь оставляет и вектор атаки: противник с физическим доступом к системе может легко подменить любой исполняемый файл на затрояненную копию или иным образом компрометировать систему. Можно минимизировать такой риск тонкой настройкой AIDE (аналог Tripwire), но здесь велик шанс перетянуть гайки или, напротив, оставить где-то окно.

Хорошо, а зачем держать ядро и initramfs на отторгаемом носителе?

По той же причине: имея физический доступ к ПК, можно подменить ядро копией, содержащей, например, модуль-кейлоггер, который запротоколирует и отправит по сети шифровальные ключи от разделов диска. И здесь уже не поможет никакая AIDE.

Как сделать, чтобы при загрузке системы не спрашивался пароль для каждого из зашифрованных разделов?

Можно зашифровать паролем только корневую ФС. Остальные разделы зашифровать случайными ключами. Сами ключи положить в /root/.keys (или иной каталог, находящийся на коневой ФС и доступный только для рута). Путь к этим ключевым файлам указать в настройках dmcrypt: key='/root/.keys/usr-keyfile' для каждого из крипторазделов.

Почему здесь не приведено пошаговое руководство?

Потому что это не пошаговое руководство (ссылку на таковое я привёл в самом начале). :-) А также ради экономии моего времени и дабы побудить интересующихся почитать маны. Иначе и с пошаговым можно наделать косяков и остаться с неработающим компом.

"Когда я работал в маленькой психиатрической больнице..."

18.06.2008

Отсюда:

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

Следующий пациент -- Швеция. Сегодня вечером приём у врача.

Казнить нельзя помиловать: о внимательном отношении к знакам препинания

12.06.2008
линукс

Товарищи-юниксоиды не дадут соврать, что rm -r ./* или rm -r /* из-под рута -- две большие разницы. :-) Вот из-за этой пропущенной точки позавчера вечером (после просмотра провального матча с испанцами... и, наверное, под влиянием впечатлений) едва не убил всю систему. Команда за секунду успела сожрать /boot, /bin, /dev и /etc, прежде чем я опомнился и нажал Ctrl+C.

Первая мысль, которая следом посетила мозг, была "Пиздеееец!". Потом -- оценка ситуации и понесённого ущерба:
1) данные не пострадали (и в любом случае есть бэкапы);
2) начисто уничтожен загрузчик и конфигурация;
3) система зашифрована, и, вкупе с предыдущим пунктом, перезагрузить её теперь удастся только один раз; :-))
4) уничтожены все консольные утилиты, bash и пр.;
5) уничтожены все файлы устройств, так что даже в отсутствие предыдущего пункта подмонтировать LiveCD никак не получится;
6) луч надежды -- две оставшиеся открытыми консоли, в одной из которых залогинен тот самый злосчастный рут, и сохранившиеся в целости приложения.

Самый простой выход из сложившегося положения -- плюнуть на систему, перезагрузиться, отформатировать разделы и поставить всё с нуля. Тем более, что от системных настроек, нажитых непосильным трудом, так или иначе ничего не осталось. Нет, захотелось выяснить пределы прочности Gentoo и, как Мюнхгаузену, самому вытащить себя из болота.

Во-первых, в отсутствие /bin очень помог Midnight Commander с его собственной реализацией операций копирования. Во-вторых, в домашнем каталоге рута нашлась сборка busybox, оставленная от работ над initramfs. Благодаря этому удалось восстановить mount, cp и другие жизненно важные утилиты.

Затем был оживлён /dev:

mkdir /mnt/tmp
mount --bind / /mnt/tmp
cp -a /mnt/tmp/dev/* /dev/
umount /mnt/tmp

So far so good. Теперь можно пошариться в содержимом Gentoo LiveCD:

mount /dev/hda /mnt/cd
mount /mnt/cd/image.squashfs /mnt/tmp

И восстанавливаем убитые директории:

cp -f /mnt/tmp/bin/* /bin/
cp -f /mnt/tmp/etc/* /etc/

Некоторые утилиты отказывались работать, но это было исправлено копированием соответствующих библиотек из /mnt/tmp/lib, с которыми они были скомпонованы и на которые ссылались.

Неокученным остался только /boot. Образ ядра был взят, как и положено, из /usr/src/linux/..., а initramfs -- из домашнего каталога рута, где он лежал, как и busybox, со времён своей сборки. Однако, без загрузчика от всего этого добра мало проку, к тому же с LiveCD была взята не нативная конфигурация системы (хоть и близкая ей).

Дальше последовал долгий и нудный процесс восстановления настроек portege -- менеджера пакетов Gentoo. В первую очередь создаём ссылку /etc/make.profile на текущий профиль системы. Затем прописываем в /etc/make.conf основные параметры сборки (главную проблему здесь создавала нерабочая система документации -- man отказывался запускаться по какой-то мутной причине, спасало то, что значительная часть документации с сайта Gentoo лежит на диске). И, наконец, приводим конфигурацию portege к той, что была до атомной войны. Процесс выглядел так:

1) emerge -ep world, смотрим на изменения use-флагов (те, что отмечены звёздочкой), корректируем эти изменения через /etc/make.conf и /etc/portage/package.use.
2) Отлавливаем оставшиеся изменения с помощью emerge -ep world | grep '\*'.
3) Вносим изменения в /etc/portage/package.{mask,unmask,keywords}, отлавливая их через emerge -ep world | grep 'D', emerge -ep world | grep 'S', и предупреждения Портежа о недоступных пакетах.

Когда portege перестаёт ругаться на недоступные пакеты, количество простых пересборок становится равным числу установленных пакетов и никаких изменений в use-флагах установленных пакетов больше нет, заканчиваем упражнение.

Мне первым делом пришлось пересобрать третью версию gcc, поскольку конфигурация с LiveCD предполагала только четвёртую версию, которая с hardened-профилем бесполезна. Затем переустановил grub и настроил загрузочное меню. На всякий случай сделал надёжную резервную копию криптоключей от разделов диска. И, наконец, через emerge -e world запустил полную пересборку... которая, добравшись до сборки boost'а из C++, сожрала всю оперативку и своп и повесила компьютер с ненастроенным /etc/fstab и device-mapper'ом. :-))

Восстановительные работы ещё не закончены, но оставшиеся шаги уже понятны. Хотя Линукс сейчас не запустить, резервные копии криптоключей позволят подключить разделы с LiveCD и завершить конфигурацию разделов. Затем последует запуск самой ОС, досборка мира и долгий и нудный процесс по восстановлению системных настроек, их приведению в изначальный вид.

Какой опыт я из этого вынес? К резервным копиям данных следует добавить и резервирование настроек системы: их подгонка под свои нужды -- слишком длительный и затратный процесс, чтобы подвергать их такому риску. И надо, наконец, побороть лень и настроить grsecurity!

Синдром одиночки

27.01.2008
мнение

Меня тут недавно упрекали в отсутствии в этом блоге "человеческих" публикаций. Дескать, даже у Шнайера есть "рыбные дни", когда он об осьминогах пишет... Правда, нечто подобное было и здесь, а учитывая крайне низкий трафик с моей стороны, найти эти старые записи совсем нетрудно. Что ж, вот ещё одна (постольку, поскольку).

Читая журналисткие работы Киви Бёрда, неоднократно замечал, как экстраполируя современную ситуацию на недалёкое будущее, он приводит сюжет Minority Report, весьма хорошего фильма Спилберга (особенно если закрыть глаза на некоторые косяки, которых, впрочем, в любом голливудском кине навалом), в качестве своеобразного "ориентира" высокотехнологичной политики и политики безопасности. Возможно, будет небезынтересен ещё один такой "ориентир", к которому движемся (или нас стараются двигать) в ногу ровным маршем. Тем, кто не имеет предубеждений против японского анимэ, советую взглянуть на сериал (именно сериал, поскольку есть ещё несколько одноимённых полнометражных анимационных фильмов) Ghost In The Shell Standalone Complex, "Призрак в доспехе. Синдром одиночки". (Ещё встречался перевод "автономный комплекс", но это дословный перевод с английского, контекстуально неверный.) Сериал состоит из двух сезонов по 26 связанных эпизодов, продолжительность каждого эпизода 25 минут.

Действие происходит в 30-е годы XXI века, в основном на территории Японии. Несмотря на несколько минувших мировых войн (а во многом и благодаря им) информационные и кибернетические технологии развились до такой степени, что значительная часть мирового населения с ранних лет оснащается т.н. кибермозгом, включающим вычислительные и запоминающие устройства, машинно-мозговой интерфейс, средства беспроводной связи, короче, вполне себе полноценным компьютером. Нередки и другие кибернетические расширения типа усиленных искусственных конечностей.

Но, как несложно догадаться, этот "дивный новый мир" в плане инфобезопасности мало чем отличается от положения сегодняшних дней (иное было бы по меньшей мере неубедительно :-). Более того, человек, не владеющий "чёрной магией" ИТ, не отделается уже одним лишь затрояненным ПК, присоединённым к бот-сети для рассылки спама, или обчищенным электронным счётом: теперь взломают его собственный мозг или, того хуже, его "призрак", саму душу. А последствия -- от использования вычислительных ресурсов кибермозга в личных целях взломщика, до слежки за человеком с помощью его собственных глаз или убеждения говорить и делать навязанные ему вещи. Ну, и, конечно, все прочие атрибуты современного общества тоже на местах: коррупция, ксенофобия, экономический спад, слияние бизнеса, организованной преступности и властных структур, монополии на рынке СМИ, тотальная слежка, видимая свобода демократического общества, прикрывающая цензуру и бесследные исчезновения людей.

Главные персонажи -- сотрудники 9 отдела Полиции общественной безопасности Японии, особого элитарного военизированного подразделения, расследующего высокотехнологичные преступления, случаи терроризма и выполняющего разную "скользкую" работёнку типа политических убийств. Как зачастую бывает в анимэ и в жизни, мир не делится чётко на чёрное и белое, на хороших и плохих, героев и антигероев. И хотя главные персонажи обычно действуют во имя высоких целей и собственных идеалов, методы порой бывают чудовищны. Из разряда "Добро обязательно победит зло!.. поставит его на колени... и зверски убьёт".

Этой краткой рецензией даю свою рекомендацию. Если не воспринимаете просмотр анимэ за признак инфантилизма и ещё не смотрели этот фильм, обязательно сделайте это -- о затраченном времени не пожалеете.

Да, что любопытно: во вселенной сериала нынешние США больше не являются Соединёнными Штатами Америки, а стали Американской Империей (АНБ, правда, никуда не делось). Вполне в духе текущих тенденций. :-)

Продление действия PGP-подключей несовместимо с серверами ключей

14.01.2008
pgp

Если помните, год назад я заменил свой старый открытый ключ новым ключом с нетипичной структурой: его базовый ключ подписи имеет неограниченный срок службы, а подключи шифрования и подписи с ограниченным сроком предполагают периодическую замену. Так вот, в конце минувшего года срок действия подключей истёк.

Учитывая их крупный размер и бережное обращение с ними, я решил их не заменять, а переподписать с новой датой окончания действия. Продлить, в общем. Что и было сделано. Обновлённую копию загрузил на серверы ключей. А пару дней назад выясняется, что на всех серверах ключей лежат неработоспособные копии моего ключа -- корреспондент, желавший мне написать, не смог зашифровать сообщение.

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

Короче, если ключ, взятый вами с сервера, отказывается работать, обновите копию из "официального источника".