 |
||||||
 |
 |
|||||
 |
|
 |
|
 |
 |
 |
|
|||
 |
|||
 |
|||
 |
|||
 |
|||
Увы, в печатную версию ссылка на pgpru.com не попала, но на сайте они это исправили, а накануне опубликовали всё интервью целиком (ну, почти) вместо пары фраз, добравшихся до текста статьи в исходном виде. :) |
|
В остальном программа понравилась (да, я гламурное блондинко!), приятно удивил календарь Lightning, полностью отвечающий моим задачам, хотя пока немного шероховатый по углам. |
 This video is best viewed with mplayer -loop 0. |
|
|
|
 Alparo-кун, ты про животину спрашивал? :) |
 Очередное баловство на конкурс по одноимённой теме. Спасибо NASA за наше счастливое детство (на самые детализированные текстуры даже оперативки не хватило). Можно щёлкнуть по превьюшке для полноформатной картинки. |
|
|
Если оно кому нужно, то архив вот (правой кнопкой > сохранить как), подпись здесь. Скрипт пригоден для автоматической работы по крону. Помимо прочего добавил в него дополнительный логгинг: все неудачные сверки подписей будут выводиться в authpriv с приоритетом warning. Разумеется, если подпись по той или иной причине не сверяется, скрипт немедленно прерывает исполнение ещё до синхронизации снапшота с рабочим деревом портежа в /usr/portage. Для установки скопируйте сам emerge-delta-webrsync и небольшой скрипт-хэлпер gpg-check-file.py в /usr/bin или иной каталог, прописанный в PATH. Затем добавьте в /etc/make.conf следующие переменные: SNAPSHOT_GPG_KEY="отпечаток ключа Gentoo Portage Snapshot Signing Key", которым заверяются снапшоты. (Если что, отпечаток текущего ключа, действующего до конца года, -- AE54 54F9 67B5 6AB0 9AE1 6064 0838 C26E 239C 75C4. Скопировать можно в таком виде, с пробелами или без, в любом регистре.) Эта переменная обязательна, без неё скрипт откажется работать. PORTAGE_GPG_DIR="путь к домашнему каталогу GnuPG, где находится связка с указанным выше ключом". Отсутствие этой переменной (в отличие от предыдущей) некритично, по умолчанию принимается путь /root/.gnupg, но тогда убедитесь, что открытый ключ Portage Snapshot Signing Key действительно находится на связке ключей у рута. DELTASYNC_MIRRORS="разделённый запятыми список зеркал для скачивания дельт и снапшотов". Поскольку я использую разные зеркала для получения дельт и исходников, посчитал такое расширение для себя удобным. Но если не хочется держать два списка, то при отсутствии этой переменной используются зеркала из основного списка GENTOO_MIRRORS. Залогиньтесь рутом, скачайте ключ, заверяющий снапшоты, и заверьте его неэкспортируемой подписью (или что там предусматривает ваша политика сертификации): gpg --keyserver subkeys.gpg.net --recv-key 0x239C75C4 gpg --lsign 0x239C75C4 В случае проблем сообщайте. ДОБАВЛЕНО (30.05): Отредактировал постинг в соответствии с изменениями в скрипте. Спасибо Mellon'у за дельные советы. ДОБАВЛЕНО (04.01): Бэкпорт багфикса #299443 из официальной версии emerge-delta-webrsync-3.5.1-r3 (случилась локальная Проблема-2010): sed 's/portage-200\*/portage-2[[:digit:]][[:digit:]][[:digit:]][[:digit:]][[:digit:]][[:digit:]][[:digit:]]/g'
|
|
Но я человек нехитрый, тупо переключил профиль на multilib и стал надеяться, что оно полетит. Разумеется, пересборка тулчейна (и, персонально, glibc) никуда не полетела, а вывалилась с жалобами на /lib/cpp, не прошедший sanity check. А на что я надеялся, если в системе нет инструментария для сборки x86-кода? Полез в гугл, где быстро наткнулся на неутешительный ответ: Warning: Currently you cannot switch from a no-multilib to a multilib-enabled profile, so think over your decision twice before you use the no-multilib profile. Несправедливо! Из дальнейшего гугленья выяснилось, как всяческие проблемы с /lib/cpp решают в иных дистрибутивах: просто ставят подходящий бинарный пакет. Ну а мы чем хуже? Итак, ниже представлен действенный процесс перевода Gentoo Linux с чистого профиля amd64 на amd64-multilib (наличие hardened-патчей не играет роли), не прибегая к кросс-компиляции. (Прежде, чем продолжить, настоятельно советую сделать резервную копию тулчейна: quickpkg binutils gcc glibc. Если у вас несколько версий gcc в слотах, укажите нужную атомом, особенно если это hardened-версия компилятора. Затем скопируйте файлы бинарных пакетов из /usr/portage/packages/All (или где там у вас PKGDIR) в какой-нибудь надёжный каталог.) Для дальнейших манипуляций необходимо наличие Gentoo LiveCD (хотя, в принципе, подойдёт и InstallCD), который по сути -- универсальная multilib-система с нужным для наших целей тулчейном. У меня как раз на жёстком диске лежала исошка. Монтируем её и образ системы (если у вас это добро записано на CD, то первым mount'ом просто примонтируйте этот CD): mkdir /mnt/{iso,squash} mount -o loop ~/livecd-amd64-installer-2008.0-r1.iso /mnt/iso mount -o loop /mnt/iso/image.squashfs /mnt/squash Скопируем содержимое squashfs в нормальную файловую систему, в которой можно работать: dd if=/dev/zero of=~/livecd_fs bs=1M count=2500 mkfs.ext3 -b1024 -I128 -m0 -O sparse_super -Fv ~/livecd_fs mkdir /mnt/gentoo mount -o loop,exec ~/livecd_fs /mnt/gentoo cp -vrpP /mnt/squash/* /mnt/gentoo/ (Как и у большинства задач в линуксе, у этой тоже есть несколько решений. Так, если у вас InstallCD, то создавать образ на 2.5 гигабайта совершенно не требуется. Объём можно сократить и в случае LiveCD, если не копировать всё содержимое squashfs. Я здесь пошёл по простейшему пути.) Всё почти готово. Подключаем служебные {псевдо}-файловые системы и актуальное дерево портежа: mount -t proc none /mnt/gentoo/proc mount -o bind /dev /mnt/gentoo/dev mount -o bind /usr/portage /mnt/gentoo/usr/portage/ Если каталоги с дистрибутивами и бинарными пакетами лежат у вас не в /usr/portage/{distfiles,packages}, а за пределами директории portage, не забудьте примонтировать аналогичным образом и их. Теперь завершаем приготовления и чрутимся в созданную среду: cp -vPf /etc/make.* /mnt/gentoo/etc/ chroot /mnt/gentoo /bin/bash С помощью ls -l /etc/make.profile убедитесь, что символьная ссылка ведёт к нужному вам multilib-профилю. (Тут стоит оговориться, что если ваша основная, не-chroot-система использует hardened-профиль, не указывайте его, если только не перенесли в chroot и hardened gcc. Иными словами, достаточно выбрать обычный десктопный профиль amd64, который по умолчанию multilib.) Затем отредактируйте /etc/make.conf, добавив в список USE-флагов multilib. Также, если в переменной FEATURES прописывали всяческие ограничения привилегий для работы портежа (типа usersandbox, userpriv и т.п.) и при этом сидите на hardened-ядре с укреплённым chroot'ом, уберите их, иначе не сможете выполнить сборку. Наконец, обновляем среду и компилируем мультилибнутый glibc, создавая бинарный пакет. Имейте в виду, необходимо собрать ту же самую версию glibc, что и в основной системе, так что указывайте пакет атомом. env-update ; source /etc/profile emerge --metadata emerge --buildpkgonly =sys-libs/glibc-2.6.1 Если на этапе конфигурации не возникнет проблем, то и сборка наверняка пройдёт успешно. Итак, если нам повезло, и glibc с USE-флагом multilib собран, возвращаемся из чрута на свет божий: logout. Убедитесь, что у вас установлен флаг multilib (emerge --info | grep multilib) и, если нет, добавьте его в make.conf. Всё готово к установке glibc и пересборке тулчейна (не забудьте указать gcc атомом, если у вас hardened-профиль): FEATURES="-collision-protect" emerge -K sys-libs/glibc emerge =sys-devel/gcc-3.4.6-r2 emerge binutils glibc =sys-devel/gcc-3.4.6-r2 Осталось прибраться и пересобрать мир: umount -v /mnt/gentoo/proc umount -v /mnt/gentoo/dev umount -v /mnt/gentoo/usr/portage/ # отмонтируйте остальные использованные вами файловые системы # <...> umount -v /mnt/gentoo umount -v /mnt/squash umount -v /mnt/iso rm -vi ~/livecd_fs rmdir /mnt/{iso,squash,gentoo} emerge -e world Миссия выполнена. |
  Что-то я круто 3d увлёкся. Пора меру знать. |
|
      
|
Компьютерные гиганты идут в направлении тех же граблей с сервисами Google Health и Microsoft HealthVault. Разумеется, их privacy policy чёрным по белому утверждает, что только пользователь будет определять круг лиц с доступом к своим медицинским данным. Что ж, здесь хотя бы имеют место взятые на себя обязательства. А что же у нас? А у нас с полей победно рапортуют об электронизации страны: В скором времени в российских медучреждениях будут внедрены компьютерные медицинские системы, позволяющие заменить "бумажные" истории болезни на цифровые. Такие системы помогут значительно улучшить качество медицинского обслуживания: на 30-50% снизится количество врачебных ошибок, врачам станет проще разбираться в назначениях друг друга, а пациентам не придется тратить много времени в очередях в регистратуру и на прием. И ни слова о безопасности. Характерно, что истории болезни не относятся у нас к врачебной тайне как таковой, да и последняя формально не подлежит обязательной защите как приватная, сугубо личная информация. Лет пятнадцать назад я некоторое время жил в одном маленьком российском городке, где в то время местные компьютерные умельцы перевели медицинский архив главной горбольницы в электронный вид. Только о каком-либо контроле доступа подумать забыли, и все медицинские записи были доступны любому человеку с удалённым доступом к больничной интрасети (включая тамошних админов и членов их семей). Время было давнее, дикое. Теперь-то всё будет по-другому, ага. |
Простейшее решение, наиболее пригодное для обычных дистрибутивов, а не 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 (Обратите внимание на /dev/sda10 -- это пока зашифрованная копия корневой ФС из временного раздела.)initrd /boot/initramfs 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' для каждого из крипторазделов. Почему здесь не приведено пошаговое руководство? Потому что это не пошаговое руководство (ссылку на таковое я привёл в самом начале). :-) А также ради экономии моего времени и дабы побудить интересующихся почитать маны. Иначе и с пошаговым можно наделать косяков и остаться с неработающим компом. |
 |
