Насчёт открытых программ интересно, если такие бы попадали в открытые Unix-подобные ОС прямо в официальные репозитории дистрибутивов.

Наблюдения очень интересные, но тот топик не совсем то (как, получается и этот — раз есть более интересный подход к заданной теме). Если вас интересует не Live-(CD/USB), которые всё-таки отдельное решение для временной периодической работы, а нужна регулярная система (пусть противник ломает голову при анализе трафика над тем, что вся ваша работа в интернете анонимна всегда, по принципу "буду скрывать, что мне нечего скрывать, вдруг в будущем пригодиться что-то скрыть"), то лучше создать отдельную тему. Там можно подредактировать коменты для большей ясности.

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

Нет. Это ведь не защищает от подмены пакетов на самом сервере репозитория, а Debian рассчитывает на множество зеркал, которые не обязаны быть доверяемыми.

Вам, надеюсь, в игры играть не нужно? Ставьте простые иксы, современных процов хватит даже на вытягивание нагрузки при просмотре HD-video без аппаратной помощи видяхи.

Единственное, что шифрованный LVM ставится крайне неудобно, согласен.

В /etc/inittab см. п. default runlevel. Если иксы запускаете не вручную, то скорее всего он не второй, а пятый. Если другими уровнями не пользуетесь, то в них можно не трогать.

Не помню как, но CUPS УМВР из консоли через стандартную заглушку lpr только при запущенном демоне.

alsamixer должен показывать всё [F5]. Переключайтесь между несколькими звуковухами [F6], сейчас они бывают виртуальными, даже внутри видях или внешних мультимедиа устройств. Хотя в Убунте могло быть новее и фичастее ядро и alsa.

P.S. По теме есть устаревший материал: Uwe Hermann: Towards a moderately paranoid Debian laptop setup^[link8].

1. Они там fw в rc.boot прописывают, а у меня нет такой директории. Писать правила iptables в /etc/rc.local — это слишком поздно с точки зрения старта системы?
2. Описанный там мануал по SeLinux ещё сколь-нибудь актуален? SeLinux можно включить как волешебную кнопку в default on policy и всё станет хорошо? Разве так можно, оно на что-то влияет?
3. Наконец, разве можно жить без Flash? Youtube без него много чего показывать не будет.
4. Acrobat Reader тоже бывает нужен (pdf — проприетарный формат, поэтому только acroread даёт более-менее точное представление о том, как он выглядит, да и печать из acroread на принтер даёт меньше артефактов). Конечно, никто не заставляет запускать такие программы от основного пользователя, можно под них создать отдельных.
5. Ещё автор пишет

   Do not install any tasks (no "desktop", no "base system").

   Кажется, base system — это самый minimal и есть, если его не выбрать, то ничего не будет установлено вообще. Будет только разбивка разделов, ядро, grub и всё, а сами разделы будут пусты.

pdf — проприетарный формат

1. Монтировалось какое-то устройство/файл или логический том.
2. С конфигами этого тома запускалась программа (например, там хранится БД почты, которую использует mutt).
3. Давая определённую команду, я закрыаваю mutt и отмонтирую том.

ryptsetup не может работать в userland — я правильно понимаю? И какой тогда выход? Каждый раз логиниться под рута, чтобы подмонтировать нужный том? Или надеяться, что sudo безопасно? Нужно, чтобы sudo давало выполнить определённый набор команд определённому пользователю и ничего другого (никому и никогда и ни при каких обстоятельствах) — это реально? Т.е. никаких sudo bash.

Хочу отключить IPv6 тотально

Disable ipv6 in kernel: echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf will disable ipv6 at next reboot

Извините, на многие вопросы подробно не ответить, просто лень. Когда-то ставил давно, на тот момент как-то сообразил как настроить до нужного состояния. Если лично мне понадобится — придёться вспоминать или ломать голову снова, или надеяться, что само заработает. Потом апгрейдил системы до wheezy. Времени на полный аудит всех систем нет, на попытку чистовой установки и пошагового воспроизведения тоже. Когда давно пользуешься системой остаются бэкапы старых конфигов, разные текущие конфиги, куда при новой установке можно глянуть.

На ходу приходиться каждый раз разбираться. Без конца что-то меняется. Чего стоят всякие изменения в /proc, udev и пр. Вот пропихнут и навяжут всем систему инициализации от Л.Поттеринга с кучей фич, наподобие бинарных фрагментов в логах и поимеем ещё кучу геморроя с багами, утечками, сложностью нестандартных настроек.

В Debian был (есть?) какой-то стандартный способ складывания конфигов iptables. Не помню насколько плохой, но дико бесящий своими попытками облегчить жизнь неопытным пользователям. Закинуть свой скрипт в /etc/network/if-pre-up.d/ пока остаётся самым надёжным. Только после каждого нового релиза — как ходьба по минному полю со старыми знаниями по настройке.

Описанный там мануал по SeLinux ещё сколь-нибудь актуален? SeLinux можно включить как волешебную кнопку в default on policy и всё станет хорошо? Разве так можно, оно на что-то влияет?

У меня сложные отношения с SELinux. У команды Debian похоже тоже. Они не осилили новую сборку правил и пихнули в wheezy то, что кое как работало с предыдущего релиза. Из-за кучи непофикшенных правил, теперь стало ещё больше глюков. Соответственно, больше штук приходиться отключать или допиливать, чтобы работало.

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

По сложности настройки — это не волшебная кнопка. Или придёться копаться немного (но даже это очень головоломно) внутри, или отключить (почти) всё.

В wheezy сделали выбор из SELinux и AppArmor, из-за плачевного опыта внедрения и поддержки первого. Но как-то жалко переходить на альтернативы потому что теоретически подход SELinux более правильный.

Наконец, разве можно жить без Flash? Youtube без него много чего показывать не будет.

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

Ни в коем случае! Evince, Okular, Acroread, что-угодно, только не Adobe!

Для этого предназначен pmount с суидным битом. Имел критические баги, также как и sudo. Это не в смысле, что надо отказываться, а что или полное неудобство, или безбажных утилит практически не бывает.

Всякие автораны — плохая штука. Хотя, в /etc/cryptab можно прописывать и свои скрипты, но оно не предназначалось для этой цели.

Просто идея, что ключи с доступом к критическим даным постоянно висят в памяти, мне не нравится. Хотелось бы подключать их по простому 128-битному паролю с юзерофильным скриптом, а потом так же легко отмонтировать.

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

Передача опции ядру через grub — второй по эффективности метод.

В /etc/default/grub строка CRUB_CMDLINE_LINUX= должна содержать ipv6.disable=1. Затем сделаете grub-update и после ребута не должны видеть никаких ipv6, например по ifconfig. Некоторые программы могут ругаться (локальная почта), но у них в конфигах запросы к ipv6 тоже при необходимости отключаются.

В меню grub2 есть опция linux ... root=/dev/mapper/NAME, которая сливает название всей volume group и logical volume для root, находящееся внутри LUKS, в незашифрованный /boot раздел. Скажите, зачем так в Linux делают? UUID'ы для всего и вся, там прописанные, тоже не радуют.

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

Edit /etc/passwd: give all users except for root, sync, uucp and your user account /usr/sbin/nologin as login shell. None of these accounts really needs a valid login shell (nologin will log any login attempts for those accounts).

Now that we have a small, hardened system, it should be reasonably safe to enable networking. Add this to /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

pre-up /etc/rc.boot/fw_laptop

Run /etc/init.d/networking restart. The firewall script will run every time the network is started.

1. Выходим из джаббера (ключ, надеюсь, при этом сносится из памяти) и блокируем экран.
2. Идём в консоль, логинимся под root.
3. umount лог. тома
4. luksClose на девайс

Если в какой-то момент сетевого интерфейса ещё нет, а правило есть, ни один сетевой пакет под правило не подпадает и всё ОК.

Хотелось бы каждый раз перед блокированием экрана выключить джаббер и отмонтировать раздел с конфигами/логами, которые он пишет/читает, это было бы самым надёжным, но тут получается много шагов

поимеем невозможность войти в систему, особенно если там всё пошифровано?

А /boot раздел на винчестере оставить, пусть на нём апдейтится.

/boot никогда не шифруется,

Совершенно верно. Можно ещё копию /boot и/или загрузочной флэшки хранить и в зашифрованном корне, чтобы при необходимости вручную примонтироваться ещё с одной флэшки — на которой Live-USB система, чтобы можно было с корня вытащить бэкап, если /boot на винчестере недоверяем, а повседневная загрузочная флэшка повредилась.

Ну или ещё как-то придумать как подстелить соломку с бэкапами.

Является. Остаётся только если следить за своими флэшками и прятать запасные флэши в другом месте, чтобы было чем воспользоваться при опасении компрометации. Загрузчик всё равно будет как "кащеева смерть". В уме можно запомнить только пароль. А стартовые расшифровывающие программы (загрузчик, ядро, рамдиск и др.) всё равно будут где-то лежать в открытом виде.

Точнее, в grub2 вроде добавили опцию шифрования /boot, но большого смысла это обычно не имеет.

Service to track the remote servers to use. On every boot it pings uccs.landscape.canonical.com to make sure the service exists and is usable before prompting the user to interact with it.

Due to bug, it makes empty queries to videosearch.ubuntu.com every few minutes, even when "Include Online Search Results" set to "Off" in Privacy panel of System Settings. To disable these connections, you can remove unity-scope-video-remote package

Connection being made when you type something in Dash search bar with applications lens selected, ignoring "Include Online Search Results" switch set to "Off" in Privacy panel of System Settings. To disable this connection

Due to bug, it makes DNS queries for daisy.ubuntu.com every few minutes. To disable them, you can remove whoopsie package

1. Домашняя страница → blank page.
2. Block reported attack sites, block reported web forgeries → off.

Кстати, кто такой getpersonas?

Список для firefox тоже впечатляет.

Новые мысли: Debian iceweasel.

будете проходить мимо Linux Mint – проходите

что уязвимость исправить нельзя

уязвимость исправить нельзя, поскольку соответствующая версия FF уже не поддерживается.

в которых бэкпортировать решение от уязвимости в старые версии всё сложнее и сложнее.

чем помешал opendns?

• Если мозги есть, опыт есть, желание учиться есть, и железо поддерживает, то NetBSD. Там нет никакого срача в системе, грёбаных UDEV'ов, DBUS'ов, сверхумного grub2 и пр., зачто есть полезные для анонимности и шифрования фичи, такие как LVM2 и Xen.
• Из Linux'ов, пожалуй, Debian — лучше в плане соотношения расходов на содержание ОС и отдачи от неё, но надо понимать, что со временем говнится всё, все системы обрастают фичами, комбайнами, несовместимыми с безопасностью и, уж тем более, анонимностью.
• FreeBSD ещё давно превратили в тот же Linux, вид сбоку.
• В OpenBSD всё прибито гвоздями, она очень неудобна для модификаций. Из неё сделали консольный, но чёрный ящик: включил, работает, и не смей ничего менять. И если OpenBSD-девы решили, что что-то не нужно, то это просто не нужно, и ты замучаешься городить костыли, чтобы это включить/выключить. Оно всё более и более пишется в идеологии just works, а мануалы по её использованию всё домохозяйнее и домохозяйнее (а как иначе завоёвывать рынок?).
• В DragonflyBSD, как ещё давно писали, выкинули кучу всего из системы, связанного с безопасностью, ради того, чтобы повысить производительность. Более подробно её не курил.

кто пробовал tor-browser-linux32-3.0-alpha-2? при первом запуске появляется окно с предупреждением о передаче инфы о системе. или я что-то неправильно понял?

вот еще, на вскидку посмотрел:
– нет vidalia
– в add-ons добавлен pdf viewer и torlauncher(что такое?)

Accidental local root, Debian Linux

$ last -F -a |grep 18:04
root     :1           XXX 18:04:47 2013 - down              (00:04) :1
root     tty1         XXX 18:04:47 2013 - down              (00:04)
reboot   system boot  XXX 18:04:33 2013 - XXX 18:09:36 2013 (00:05) X.X.X-X-ARCH

# cat /var/log/auth.log |grep 18:04
18:04:47 HOSTNAME login[2295]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
18:04:47 HOSTNAME login[2334]: ROOT LOGIN  on '/dev/tty1'
18:04:47 HOSTNAME xdm[2322]: pam_unix(xdm:session): session opened for user root by root(uid=0)

18:24:47 HOSTNAME xdm[2352]: pam_unix(xdm:session): session opened for user root by root(uid=0)
18:25:38 HOSTNAME xdm[2352]: pam_unix(xdm:session): session closed for user root
18:25:45 HOSTNAME xdm[2940]: pam_unix(xdm:session): session opened for user root by root(uid=0)

18:04:34 2013 xdm info (pid 2233): Starting
18:04:34 2013 xdm info (pid 2233): Starting X server on :3
 
X.Org X Server X.X.X
Release Date: XXXX-XX-XX
...
18:04:37 2013 xdm info (pid 2233): Starting X server on :2
 
X.Org X Server X.X.X
Release Date: XXXX-XX-XX
...
18:04:37 2013 xdm info (pid 2233): Starting X server on :1
 
X.Org X Server X.X.X
Release Date: XXXX-XX-XX
...
18:04:38 2013 xdm info (pid 2233): Starting X server on :0
 
X.Org X Server X.X.X
Release Date: XXXX-XX-XX
...
DRM_IOCTL_I915_GEM_APERTURE failed: Bad file descriptor
Assuming XXXXXXkB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [9]
param: 4, val: 32675
 
Fatal server error:
no screens found
 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.
 
Server terminated with error (1). Closing log file.
18:04:38 2013 xdm error (pid 2233): server unexpectedly died
18:04:39 2013 xdm info (pid 2304): sourcing /etc/X11/xdm/Xsetup
18:04:39 2013 xdm info (pid 2313): sourcing /etc/X11/xdm/Xsetup
18:04:39 2013 xdm info (pid 2322): sourcing /etc/X11/xdm/Xsetup
18:04:47 2013 xdm info (pid 2322): sourcing /etc/X11/xdm/Xstartup
18:04:47 2013 xdm info (pid 2336): executing session /etc/X11/xdm/Xsession
18:04:53 2013 xdm error (pid 2233): Server for display :0 can't be started, session disabled

[    47.361] (EE) intel(0): [drm] failed to set drm interface version.
[    47.361] (EE) intel(0): Failed to become DRM master.
[    47.361] (II) intel(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[    47.361] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[    47.361] (==) intel(0): RGB weight 888
[    47.361] (==) intel(0): Default visual is TrueColor
[    47.361] (II) intel(0): Integrated Graphics Chipset: Intel(R) XXX XXX XXX
[    47.361] (--) intel(0): Chipset: "XXX XXX XXX"
[    47.361] (II) UnloadModule: "intel"
[    47.361] (EE) Screen(s) found, but none have a usable configuration.
[    47.361] 
Fatal server error:
[    47.361] no screens found
[    47.361] 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help.

[ 0.000000] Booting paravirtualized kernel on bare hardware

[ 0.509140] mtrr: probably your BIOS does not setup all CPUs
[ 0.515562] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
[ 0.641895] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 2.318630] pci 0000:XX:XX.X: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[ 3.914534] pci 0000:XX:XX.X: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[34.107660] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0xXXXXXX)
[35.311183] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS

Никогда не видел ничего подобного в множественных xdm, правда и не логинился перед ними через консоль.

Все пользовательские логины (кроме одного резервного, который оставлен только для администрирования и в нём не запускается никаких обычных программ) закрыты SELinux'ом, так что там рут всё равно не получится.

Потом ещё будет Wayland^[link27] или Mir^[link28] с прицелами не на безопасность и конфигурируемость, а на большую совместимость со смартфонами и прочими гаджетами.

• glib-networking-services — это опасно? Куча всяких network-зависимостей идёт бонусом к gimp'у.
• Есть ли какие-то адекватные замены комбайну openoffice для просмотра и редактирования doc-файлов? А то полная Java в системе сильно смущает, она потом поди ещё и плагином к браузеру будет по умолчанию везде становиться. Была раньше масса других офисов, типа libre office и staroffice, но за офисами не слежу; не в курсе, в каком они состоянии.

$ echo 'set viminfo+=n/tmp/.$USER.viminfo' >> ~/.vimrc
$ echo 'export LESSHISTFILE=/tmp/.$USER.lesshist' >> ~/.zshrc
$ echo 'HISTFILE=/tmp/.$USER.zhistory' >> ~/.zshrc

experimental (rc-buggy) (utils): automatically generate crash reports for debugging

1. Abiword тянет за собой сетевые гномовские уитилиты с очень сомнительным функционалом. Он самый тощий из стандартных программ этого класса.
2. Бывший koffice, который теперь calligra, тянет за собой массу грязи, включая большой кусок kde, поэтому тоже плохой выбор.
3. Утилита docx2txt хороша, но она только для чтения, причём она полностью рушит форматирование текста.
4. Рекламируют вот этот проект^[link32], вроде он не завязан на интегрированные графические среды типа гнома и kde, но подробнее не разбирался.
5. Siag Office^[link33] нахваливают, как самый наилегковеснейший, но его установка в Debian проблематична^[link34]. Такое впечатление, что этот проект давно заброшен^[link35], в Debian сохранились только его археологические останки^[link36].

Есть ли какие-то адекватные замены комбайну openoffice для просмотра и редактирования doc-файлов? А то полная Java в системе сильно смущает, она потом поди ещё и плагином к браузеру будет по умолчанию везде становиться. Была раньше масса других офисов, типа libre office и staroffice, но за офисами не слежу; не в курсе, в каком они состоянии.

Debian netinstall — ну чем не игра? Чем не квест? Вы даже не представляете, насколько сложно пройти все уровни, сколько там пасхалок скрыто, сколько тонких никак не задокументированных тонкостей есть, которые можно только угадать. Если на каком-то уровне попал в тупик, то обратно уже не вернёшься, сохраниться в игре нельзя, остаётся только перезагружаться и снова начинать установку с нуля. Debian — он ведь очень умный, он позаботится о том, чтобы вы после совершения каких-то шагов не могли их совершить снова, не начав установку с нуля. Я где-то с 50-ой попытки только прошёл эту игру, потратил часов 12, и до конца не уверен был, что вообще игру можно пройти

Ынтырпрайз сделал из Linux'а то, что он хотел для себя видеть, насрав на всех остальных. Остальным остаётся только сидеть и жрать, что им приготовили.

Виртуалки вообще не предназначены для приватности/анонимности в понимании параноиков. Они для безопасности в применении/понимании энтерпрайза (у которого риски застрахованы финансово), всё правильно.

Subject: Re: About Xen: maybe a reiterative question but ..
Date: Oct 23, 6:14 pm 2007
Virtualization seems to have a lot of security benefits.

You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.

That's all x86 virtualization is.

© Theo de Raadt^[link38], Virtualization decreases security^[link39].

Вот чей-то интересный коммент^[link40].

Виртуалки вообще не предназначены для приватности/анонимности в понимании параноиков.

Мелко плаваете параноите.

Chroot тоже не имеет отношения к безопасности^[link41]. Майк Перри пишет^[link42], что мы все умрём от кибервойны ничего не спасёт, даже выполнение кода на разных машинах, Air Gap эксплойты уже заготовлены, похищение ключей разработчиков Tor'a и дистрибьютеров, компрометация всей его инфраструктуры (и затроянивание дистрибутивов Linux заодно) — вполне реальный сценарий, вопрос времени. Так что пока ждём разработки детерминированной компиляции и групп присмотра за сборками.

I don't believe it is possible to keep software signing keys secure any more, nor do I believe it is possible to keep even an offline build machine secure from malware injection any more, especially against the types of adversaries that Tor has to contend with.

Первым начнут укреплять Debian^[link43], на нём и обкатают сборку TBB^[link44].

Если дела и дальше будут идти так плохо, то разрешат отключать вообще всё:

In the meantime, we are investigating giving advanced users a way to enable text-mode only browsing and other usability-destructive tradeoffs via a security slider at startup:

https://trac.torproject.org/projects/tor/ticket/9387

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

Собственно, вот этот коммент^[link48] Майка, в котором он разъясняет некоторые политические вопросы, в т.ч. почему приходиться сидеть на глючных небезопасных браузерах и не сделать свой.

Не наблюдаю такой проблемы. Модуль лежит, если посмотреть find /lib/modules -name "rts*", но по lsmod | grep lts он вообще не загружен. При наличии картридера. Так что можно выгружать, проверите только, работает ли картридер после этого.

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

unknown:
Модуль лежит, если посмотреть find /lib/modules -name "rts*", но по lsmod | grep lts он вообще не загружен.

Ошибся. s/lts/rts//g

В любом случае, модуль не загружен.

И что мешает приложению воспользоваться уязвимостью в рутовом процессе? Или поднять себе привилегии, через проблему в одном из модулей ядра

Другой вопрос про delay/timeout. После ввода неправильного пароля он делает таймаут в несколько секунд, как его сократить? В man ничего не вижу на эту тему.

Он должен использовать глобальные параметры PAM, в том числе для таймаута; сделать таймаут меньше, чем задано в PAM, как я подозреваю, нельзя. Здесь^[link51] есть некоторая информация, какие он использует конфиги.

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

/etc/issue
man issue

Кто-то, наверно, думает, что пароль будут подбирать, сидя за клавиатурой руками, и для сверхслабых паролей эти таймауты от чего-то спасут. Стыд полный.

При установке системы, когда ещё не заведено куча пользователей с паролями в /etc/login.defs можно поставить ENCRYPT_METHOD SHA512 вместо DES и подобрать увеличение параметра SHA_CRYPT_MAX_ROUNDS. Это не спасёт от сверхслабых паролей, но усложнит подбор при чтении и похищении таблицы shadow-паролей.

passwdTimeout (class Time)

If the screen is locked, then this is how many seconds the password dialog box should be left on the screen before giving up (default 30 seconds.) This should not be too large: the X server is grabbed for the duration that the password dialog box is up (for security purposes) and leaving the server grabbed for too long can cause problems.

(и затроянивание дистрибутивов Linux заодно)

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

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

Как скоро кто-то заметит и предъявит два разных бинарника, подписанных одним ключом?

А каким концом там стоял DES? Это было шифрование, а не хэшифрование? Любой DES взламывается. Значит ли это, что имея shadow противник с нужными расурсами может восстановить все до одного пароля за ограниченное время независимо от их сложности?

/etc/issue

Спасибо. Это сменило первую строку в приглашении, но перед login всё ещё пишется HOSTNAME. Как его убрать?

А если уже заведено, то никак? Или оно будет влиять только на новосоздаваемых прользователей? А тогда старые пользователи в базе shadow не поотваливаются, гетерогенность в ней предусмотрена? В Wheezy ENCRYPT_METHOD SHA512 стоит по умолчанию.

лучше чистую Gentoo, с Hardened профилем

Помимо генты есть LFS — ещё более универсальная штука. :)

Кури портянку постов здешних по поводу сборки Libetre Linux, там как раз Hardened

In the course of a thread about the size of browser windows posing a fingerprinting threat^[link58], harmony discovered that users of Ubuntu’s Unity desktop should disable the “automaximize” behavior^[link59], as it can override one of Tor Browser’s anti-fingerprinting measures. ©^[link60]

tl;dr?

Using the Tor Browser Bundle is still proving to be tricky for many Ubuntu users who upgraded from Ubuntu 13.04 to 13.10. The commonly reported error is that users cannot enter text in any of the browser’s text fields, including the URL and search bars. So far this problem appears to be resolved by removing ibus with apt-get before running the Tor Browser. Users who need ibus can try running `export GTK_IM_MODULE=xim`, as documented in Trac ticket #9353.

Компания обратилась к администрации сайта fixubuntu.com с требованием об удалении любых упоминаний названия дистрибутива.
<...>
Примечательно, что портал, к которому обращены требования, изначально был создан для распространения инструкции по обеспечению приватности в дистрибутиве и является примером ресурсов, отстаивающих интересы пользователей Ubuntu.

Там история похожая на Tor против TorFone, нет?

PGP Corp ещё не предъявляла претензии pgpru.com? :)

шифрования с открытым ключом у нас нет как секса в СССР

Вот так Калласу и передайте.

В^[link68]прочем, чем Microsoft лучше? Windows error messages let NSA spy on people: Crash reports are a 'neat way' of gaining access to machines, claims report.^[link69]

# apt-get remove dbus

# dpkg-query -l |grep -i freedesktop

/comment67917^[link70]:

$ echo 'set viminfo+=n/tmp/.$USER.viminfo' >> ~/.vimrc

set viminfo="NONE"

Коммента выше и старого холивара вам недостаточно?

и вроде это ещё гвоздями прибивают к D-bus и чему-то там ещё

[холивар]
Затащат DBUS в ядро и прибьют к нему.
[/холивар]

выживут только конструкторы

некоторых файлов

В текущих стабильных релизах systemd пока ещё по умолчанию не ставится.

Приучайтесь ставить все дистры в режиме "expert-install" в минимальной инсталляции без иксов, с доустановкой всех нужных вам пакетов из системы далее вручную, чтобы не было неожиданных сюрпризов по поводу того, что что-то выбрали за вас по умолчанию. И перед выходом каждого релиза читайте мануал, где подробно описано, что внедрили нового и как ставить. Желательно читайте на английском, а не в переводе. Хотя переводы там вроде как нормальные.

Тема vim^[link82]'а, пост о п-сах.

T^[link84]here's no built-in way to prevent .netrwhist generation at the current time. However, you could delete the file immediately after it was generated, I suppose: (untested) with the following Voodoo cult:
au VimLeave * if filereadable("[path here]/.netrwhist")|call delete("[path here]/.netrwhist")|endif

n^[link85]etrw_dirhistmax indicates the maximum number of modified directories it stores in the history file

1. В конфиге шелла перед стартом шелла проверять, есть ли нужная директория в /tmp, и, если нет, то создавать её и директорию vim в ней, а домашюю ~/.vim сделать симлинком на неё.
2. Создать ~/.vim и снять у неё права на запись, в надежде, что vim не настолько наглый, чтобы писать в какое-то третье место.
3. Сделать алиас на vim с изменённым $HOME. В этом случае оно почему-то конфликтует с опцией^[link70] для viminfo:

   $ HOME=/tmp vim -u /home/USERNAME/.vimrc /path/to/FILE
   Error detected while processing /home/USERNAME/.vimrc:
   line   XX:
   E528: Must specify a ' value: viminfo+=n/tmp/.viminfo-$USER
   Press ENTER or type command to continue

4. Создавать динамически директорию в /tmp как в п.1, а опцию с viminfo убрать из конфига вообще, т.к. она должна будет сразу создаваться уже там, по новому адресу. Не тестировал.

NetRW provides g:netrw_dirhistmax as a way to prevent creating the .netrwhist and .netrwbook files. However, even when this variable is <=0 NetRW will create the home directory to store these files. The attached patch changes this to only create the home directory if the files are also going to be created.

1. Список процессов каждого юзера виден всем.
2. Права на создаваемые файлы и директории по умолчанию таковы, что дают доступ на чтение вообще всем.
3. Каждый пользователь имеет широкие права доступа к системным ресурсам: просмотру сетевых настроек, логов ядра, списку пользователей и групп, логам последних логинов пользователей и длительности их сессий... список можно продолжать бесконечно.
4. По умолчанию нет никаких квот на системные ресурсы: память, процессор, дисковое пространство, поэтому повесить намертво систему — нефиг делать^[link91]. Идут года, но ничего не меняется: каждое поколение вновь открывает для себя эти форк-бомбы^[link92]. И даже самые красноглазые, которые долго игрались с ulimit, прекрасно вырубаются специально написанными эффективными форк-бомбами^[link93].

R^[link97]eleases and packages are now cryptographically signed with the signify(1)^[link98] utility.

• The installer will verify all sets before installing.
• Installing without verification works, but is discouraged.
• Users are advised to verify the installer (bsd.rd, install55.iso, etc.) ahead of time using the signify(1)^[link98] tool if available.
• pkg_add(1)^[link99] now trusts signed packages only by default.

Security improvements:

• The arc4random(3)^[link100] functions now use the ChaCha20 cipher.
• The kernel random number system is initially seeded by the bootloader, providing better random very early.

New/changed features:

• ssh(1)^[link101], sshd(8)^[link102]: Add support for key exchange using elliptic-curve Diffie Hellman in Daniel Bernstein's Curve25519. This key exchange method is the default when both the client and server support it.
• ssh(1)^[link101], sshd(8)^[link102]: Add support for ED25519 as a public key type. ED25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.
• Add a new private key format that uses a bcrypt KDF to better protect keys at rest. This format is used unconditionally for ED25519 keys, but may be requested when generating or saving existing keys of other types via the -o ssh-keygen(1)^[link103] option. We intend to make the new format the default in the near future. Details of the new format are in the PROTOCOL.key file.
• ssh(1)^[link101], sshd(8)^[link102]: Add a new transport cipher "chacha20-poly1305@openssh.com" that combines Daniel Bernstein's ChaCha20 stream cipher and Poly1305 MAC to build an authenticated encryption mode. Details are in the PROTOCOL.chacha20poly1305 file.
• ssh(1)^[link101], sshd(8)^[link102]: Refuse RSA keys from old proprietary clients and servers that use the obsolete RSA+MD5 signature scheme. It will still be possible to connect with these clients/servers but only DSA keys will be accepted, and OpenSSH will refuse connection entirely in a future release.
• ssh(1)^[link101], sshd(8)^[link102]: Refuse old proprietary clients and servers that use a weaker key exchange hash calculation.
• ssh(1)^[link101]: Increase the size of the Diffie-Hellman groups requested for each symmetric key size. New values from NIST Special Publication 800-57 with the upper limit specified by RFC 4419.
• ssh(1)^[link101], ssh-agent(1)^[link104]: Support PKCS#11 tokens that only provide X.509 certs instead of raw public keys. (requested as bz#1908)

Шифры Бернштейна становятся всё популярнее.

Вообще было бы здорово систематизировать и вышесказанное, и сказанное в других местах про Debian. Факт, что здесь есть кому и чем дополнить хорошие тексты по теме (1^[link110] и 2^[link111]). Имело бы большую практическую ценность.

Ничего серьёзного сходу не нагугливается (хотя серьёзное научное описание и глубокие причины этого состояния описаны, забыл ключевые слова, кроме "success avoidance syndrome" есть ещё что-то), но Avoiding Success^[link121] — распространённое явление. Одна из причин — "fear of unknown".

Одна из причин — "fear of unknown".

[off]
Ну да,

The unknown: we are talking about the fears surrounding the unknown.

Дело не в навязывании психологизации. Можно посмотреть, что таких людей не так мало как кажется и какие могут быть мотивы в их поведении. Они могут быть вполне рациональны и оправданы. А психологию лучше смотреть в оригинале в научных публикациях, а не в популярных книжках. Вот, не вполне серьёзный пример^[link122], больше на примере успеваемости студентов, но рассмотрены несколько причин, которые характерны и для взрослых.

Increased competition, The promise of a "career" vs. a "job", " More money and/or higher status", "Power, or perceived power", "Increased stress", "Becoming more visible", "Being viewed as better than average", "The envy of others", "Less time for other things" — для многих это серьёзные факторы отказа от успеха или выбора его, как неприемлемой формы существования для себя лично.

THESIS: Incorporated into identity is a level of success above which
people do not imagine themselves. Rather than threaten that identity,
individuals may choose to maintain the internal consistency, i.e. their
basis for security, by limiting their success.

Здесь не обязательно психология, вполне может быть генетика и нейрофизиология, т.е. для некоторых людей то, что в обществе считается успехом — изначально обусловленное некомфортное состояние. В отличие от психологов, которые говорят «всё в твоих руках, всё можно решить», если смотреть с других позиций, то проще м.б. смириться, уклониться, найти обходной путь, чем тратить массу усилий на переделывание себя в угоду другим и/или текущим представлениям общества.
[/off]

Ну я больше из жизни примеры привожу и выводы для себя делаю. Но да, видел массу людей, которых деньги делают несчастными. А в итоге не деньги делают, а то, что люди сами по себе пустые. Я вот тоже думал как-то (только, господа тролли – не надо меня в политоте снова марать). Так вот, развал СССР, неимоверное количество активов осталось безхозными. Что делать? Нужно в первую очередь по максимуму их сохранить, а потом уже думать о качестве управления. И "раздача" велась успешно пройденным "кастинг" личностям, у которых активно развита лишь программа "детского мышления". Ну т.е. получив в руки такой актив, у людей хватает мозгов лишь покупать дома, футбольные команды, трахать блядей на яхтах в Куршевель и тд. Это не так дорого стоит, и уж тем более – траты с копеечные по сравнению с активом в целом. Задача – чтобы этот актив и фин.потоки не использовались в политических целях, для свержения строя и тд. Так и не используются – мозгов то только на блядей и траты хватает. Я ни в коем случае не осуждаю, люди зарабатывают деньги. Просто к тому, что счастьем и самореализацией – там даже и не пахнет. Другой вопрос – да, страдает то народ. Останкинский мясокомбинат в Москве закупил обородувание во Франции на 35млн долларов, на новый колбасный цех. И через две недели после ввода в эксплуатацию – был продан весь(!) комбинат за 3,5млн долларов. Фвкт. Ну или когда с заводов и рудников продукция продавалась по ценам, до 40% ниже себестоимости добычи\производства. Да, руководители наваривались, но производство истощалось, зарплаты не выплачивались и, как итог – упадок промышленности, безработица, и тд. Поэтому успех все-таки понятие очень абстрактное. Я лично не принял бы для себя такой ход событий в принципе, мне не нужны деньги, когда кто-то из за этого страдает по моей прямой либо косвенной причастности. И в тоже время, да, я не готов зарабатывать копейки из за какой-то "стабильности", безрисковой жизни и тд. Но тем не менее для кого-то успех – это самореализация, для кого-то деньги, для кого-то слава и признание. Я даже сам затрудняюсь сформулировать, что это для меня. Видимо просто даже не думаю об этом. Мечтать не люблю, а мерить что-либо лишь по результатам, а результаты всегда должны быть положительными – соответственно, результат – тоже не успех. ХЗ в общем. Кесарю – кесарево. Но тем не менее, нужно понимать, что мы все-таки часть живого организма и по возможности всегда нужно помогать тем, кто этого достоин, кто не виноват в сложившийся ситуации. Я к тому, что дармоедов, бухарей и тд – тоже кормить нечего, ни физ.лицам, ни государству.

«будь как все, иди по накатанной дороге как все вокруг, не прыгай выше головы, у тебя почти всё предрешено».

Всегда раздражало это. "Каждый сверчок – знай свой шесток" и тд. Только живая рыба против течения плыть может. Что за стадные инстинкты. Представляется сразу ребенок в простой советской семье в одном из промышленных моногородков. Угадал? Ну в СССР – да, мол головой своей не думай, государство все подумало и решило. Как Есенин с сарказмом о грустном "Раз власти – на то они власти, а мы лишь простой народ".

Это ситуационный стресс, хотя бывает и стабильно повторяющийся в похожих ситуациях. Мне просто не найти качественных ссылок по теме. Хочется донести какие-то более глубокие причины, раз уж разговор пошёл в эту сторону. Такое состояние м.б. почти сознательным и спокойным выбором, а не каким-то сбоем. Я не психолог, сначала скептически относился, что Шнайер притягивает как бы наивную психологизацию к тематике безопасности. А мне кажется, это не так просто.

Вспоминается, что Эйнштейн считал себя счастливым человеком, когда работал малоизвестным клерком в патентном бюро, а не когда стал всемирно известным учёным. И это не ложная скромность, он мог быть искренним. Людям шизоидного, параноидного или аутистического (не в клиническом, а в условно-нормальном понятии этого термина) спектра склада личности не всегда комфортно вписываться в ведущие роли в обществе. Человек, который считает приватность своей ценностью, будет считать общественный успех угрозой своей безопасности. Не в физическом плане, а скорее в моральном. Вспомните успешных людей, даже политиков и даже преступников (не мелких, а пролезших наверх общества): насколько они все беспечны в техническом плане, в отличии от грамотного использования связей-отношений с нужными людьми; насколько им неинтересно разбираться, как устроено, чем они пользуются; насколько им «нечего скрывать», что они знают, что компрометирующие их письма и разговоры могут быть обнаружены, но им плевать. И наоборот: не обладающей никакой ценной информацией и особо ничего не потеряющей от её раскрытия человек будет изучать способы максимального её сокрытия, на грани одержимости. Мне неясны рациональные причины такой мотивации, но разительно видны её отличия у общепризнанно «успешных» и «неуспешных» людей. Есть надежда и проглядывается тенденция, что по мере технократизации общества, людей с изменёнными типами мотивации в поведении будет всё больше, но будет и масса негатива и общественных кризисов на этой почве.

Вспомните успешных людей, даже политиков и даже преступников (не мелких, а пролезших наверх общества): насколько они все беспечны в техническом плане, в отличии от грамотного использования связей-отношений с нужными людьми; насколько им неинтересно разбираться, как устроено, чем они пользуются; насколько им «нечего скрывать», что они знают, что компрометирующие их письма и разговоры могут быть обнаружены, но им плевать.

Могу только подтвердить, что вклад Гостя (хотя какой он там Гость, если все мы его прекрасно знаем в лицо) в проект огромен, благодарность за систематизацию материалов, раскрытие многих вопросов, научный инсайд невозможно переоценить. Будет чрезвычайно жаль, если он из него выпадет, но жизнь есть жизнь, все причины понятны.

1. Grub (/boot) был поставлен на обычный дисковый раздел типа /dev/sdaX. Потом я его перенёс на другой раздел и перепрошил mbr. Вроде проблем не возникло, всё работает.

2. Я в курсе. Какую-то мелочь я исправлял в конфиге grub напрямую, да, но, как мне показалось, это не так страшно. Как я понял, максимум, при очередном обновлении я потеряю это изменение, но не более того.

3. Скрипты не правил. Отключал, как рекомендуется (как вы сказали).

4. Понял. Вроде не особо надеялся, но какие-то изменения оставил со старых времён. Сейчас дополнительные опции монтирования убрал.
   
   

   Очевидно, /tmp смонтирован с noexec.

   
   Да. Теперь исправил.

5. Своё ядро не ставил, всё по умолчанию было.

6. С ramdisk'ом никогда не работал, внутрь не лез. По большому счёту, про него вообще впервые слышу сейчас.

есть ещё и Slackware

Я тоже думаю о смене дистрибутива. Правда пока не знаю, в сторону чего смотреть. Понятное дело – Gentoo, но у меня нет времени на него, да и знаний тоже. Попробую Slackware поставить на днях.
unknown, а ты же на Debian сидишь вроде, какие мысли на этот счет? Ну т.е. если бы пришлось мигрировать, чтобы ты выбрал для себя? Спасибо.

HOSTNAME login [XXXXX]: pam_unix(login:auth): auth could not identify password for PASSWORD

А раз соответствующие «толстые» пакеты у вас уже установлены, значит, практически всё базовое у вас уже есть и установлено не из исходников.

К слову, в суперминималистичной NetBSD и то и другое входит в часть базовой системы, т.е. штатно оттуда не удаляется.

--no-install-recommends

Do not consider recommended packages as a dependency for installing. Configuration Item: APT::Install-Recommends.

Now that the code is well tested, don't ask the firmware question anymore. Saves 141 precious bytes on the inside of the media.

1. Бинарные драйвера (т.е. код ядра).
2. Фирмварь, на которую у них прав распространения нет.
3. Открытые драйверы, написанные для линукса под NDA, в которых хрен что поймешь.

TdR: The firmware is an integral part of the device, but unfortunately due to cost savings not stored on the device itself. Operating systems must supply the firmware, and then an open source driver can communicate with the combination of device+firmware. Every device these vendors make has a totally custom operating environment, different registers here, different bugs there, and no public documentation at all. It would be a herculean effort to write a free firmware for any of these devices, since a developer would be utterly blindly trying to talk to registers. The Intel wireless devices use a processor we do not even know the instruction set for. For an example of such an effort, see http://prism54.org/freemac.html where some people have been trying to write a completely free replacement firmware for a chip that shipped during the period 1999-2002. Read the history too. Note that the prism54 is a simpler-than-the-average 802.11 firmware-driven chip. The Broadcom and Intel chips are way more complicated (and buggy) internally.

But firmware replacement is precisely the kind of effort we may eventually get into if the vendors do not give us permission. We may have to reverse engineer their firmwares to write replacements. Those replacements will be of very poor quality for a very long time, due to the incredibly difficult programming environment. These vendor programmers used simulators and jtag to write the the firmware for these chips, and they knew all the registers and had the hardware designers next door. In our efforts, we might even melt some devices, and cause all sorts of spectrum damage. It is in everyone’s best interest if the vendors would simply, through copyright law, grant re-distribution rights of the firmware binaries by other operating systems in the same way they allow Microsoft to distribute these binaries.

Some people (mostly just RMS) insist on firmware source code. We do not feel that we need or even want firmware source code — just the missing binary component that allows the device to operate. Our #1 goal is that our users be able to use the devices they purchased. We feel that when RMS insists on things which vendors will never give, he confuses the vendors, and the vendors back off and end up giving us nothing at all. As a result, everyone loses — RMS, the vendors, the operating system suppliers, and the users. This is not (yet) the time or place to make such strict statements.

В Linux есть хотя бы выбор: или открытые, но неполностью функциональные драйвера, или блобы с кучей недостатков (отсутствие доверия к разработчикам и потенциальные трояны — не единственные из них). Пример выбора: поддержка 3D или HD-video в видеокартах бывает не нужна, тогда можно выбрать открытые.

Понятно, почему в (Open)BSD этого нет: открытые драйвера создаются тупо за счёт человекочасов и перехода количества в качество, это нудная и неинтеллектуальная разработка. В BSD просто нет таких ресурсов.

Avoiding systemd isn't hard

The former contents of this blog post have been removed.
Systemd-haters pissed me off so much, that I'm no longer willing to provide information helpful for avoiding systemd.
Here is my message to all the anti-systemd-trolls: Go jump in a lake, we do not need haters in the open source community.
Hint: if you want people to care about you, stop insulting them. If you keep on pissing off people, you will not achieve anything!

Параноиков будет скоро останавливать то, что изучать надо слишком мало, а машины стали слишком умными и следят за владельцем через проприетарный бортовой компьютер. Я по этой причине стараюсь не приобретать «умную» закопирайченную-задээрэмленную электронику, особенно которая подключается к инету, имеет встроенный WiFi и т.д.

Смотря что вы там собиратесь хранить. Бывает профессиональное холодильное оборудование для лабораторий, к примеру. А иметь в быту профессиональную технику, к которой можно подоткнутсья с программатором или чем-то таким, тоже бывает забавно.

F^[link154]or some reason Firefox HTML 5 requires Card 0 of the snd_hda_intel no matter how you change it with asoundrc. You can make flash work using the asoundrc file, but HTML 5 audio is silent.

You must remap the PCM device in Linux as card 0 and remove the changes to asoundrc that were added to make flash work. This wiki page indicates that you should compile the snd_hda_intel driver into the kernel. Using this configuration you must remap the card 0 and card 1 devices using boot parameters instead of a /etc/modprobe.d/alsa.conf file.

The module is named snd_hda_intel, but the boot parameter name is snd-hda-intel.

это разработчики имеют право быть дартаньянами, а не я.^[link156]

# getcap /path/to/ping
/path/to/ping = cap_net_raw+ep
# getcap /path/to/ping6
/path/to/ping6 = cap_net_raw+ep

C^[link158]apabilities (POSIX 1003.1e) provide fine-grained control over superuser permissions, allowing use of the root user to be avoided. A setuid binary can be replaced with a more minimal set of capabilities. Many packages make use of capabilities, such as CAP_NET_RAW being used for the ping and ping6 binaries provided by iputils.

FAQ:

5. W^[link164]hen I'm logged in as root, xscreensaver won't lock my screen!
6. When I'm logged in as root, xscreensaver won't launch at all!

FAQ:

11. Programs sometimes pop up dialog boxes over the screen saver while my display is locked, and I wish they didn't.

FAQ:

17. Shouldn't xscreensaver disable Ctrl-Alt-Backspace while the screen is locked?

Yes, it should. Unfortunately, that's not possible with current versions of XFree86 or XOrg. It's as if the developers of X11 and the Linux kernel want to make it as hard as possible for you to lock your screen.

Backdoor #1: Ctrl-Alt-Backspace.

Backdoor #2: Ctrl-Alt-F1, Ctrl-Alt-F2, etc.

Backdoor #3: Alt-SysRq-F.

Backdoor #4: Ctrl-Alt-KP_Multiply.

This keystroke kills any X11 app that holds a lock, so typing this will kill xscreensaver and unlock the screen. This "feature" showed up in the X server in 2008, and as of 2011, some vendors are shipping it turned on by default. How nice. You can disable it by turning off AllowClosedownGrabs^[link165] in xorg.conf.

...

There's little that I can do to make the screen locker secure so long as the kernel and X11 developers are actively working against security. The strength of the lock on your front door doesn't matter much so long as someone else in the house insists on leaving a key under the welcome mat.

In an ideal world, there would be a single X11 request named something like XGrabMagicKeys() that would, analagously to XGrabKeyboard(), disable all of these magic keystrokes until the grab was released or the program exited. It should be an X11 call, not an ioctl(), and especially not a root-only ioctl(). Needless to say, no such interface exists.

Скриптомесево №2

1. Автофикс раскладки.
2. Поддержка блокировки всех X-дисплеев из-под любого из них.
3. Per user $TMP: пусть все временные файлы конкретного юзера хранятся в /tmp/$USER вместо /tmp, чтобы не давать посторонним юзерам на этой же машине видеть их список.

В $HOME каждого юзера (иксов) создаём файлы:

1. $HOME/bin/lock.sh:

   #!/bin/sh
    
   LOCK_DIR=/tmp/.lock_dir
   LOCK_FILE=$LOCK_DIR/lock_file
    
   if ! [ -d $LOCK_DIR ] ; then
       mkdir $LOCK_DIR
       chmod go+rwx $LOCK_DIR
   fi
    
   while true ; do
       if [ -f $LOCK_FILE ] ; then
           xscreensaver-command -lock
           # Wait while other X servers will catch the signal too:
           sleep 5
           rm $LOCK_FILE
       fi
       sleep 1
   done

2. $HOME/bin/xkbd.sh:

   #!/bin/sh
    
   process(){
       while read line; do 
           case "$line" in
               UNBLANK*)
                   setxkbmap -layout us,ru
               ;;
               LOCK*)
                   setxkbmap -layout us
               ;;
           esac
       done
   }
    
   # Ждём, пока запустится сам xscreensaver следующей 
   # команадой в ~/.xsession (exec xscreensaver):
   sleep 1.5
   /usr/bin/xscreensaver-command -watch | process

3. $HOME/bin/mktmp.sh:

   #!/bin/sh
    
   USERTMPDIR=/tmp/$USER
    
   FLAG=false
   if ! [ -d $USERTMPDIR ] ; then
       mkdir -p $USERTMPDIR
       chmod go-rwx $USERTMPDIR
       FLAG=true
   elif [ -O $USERTMPDIR ] ; then
       FLAG=true
   fi
    
   if $FLAG ; then
       TMPDIR=$USERTMPDIR
       TMP=$TMPDIR
       TEMP=$TMPDIR
       export TMPDIR TMP TEMP
   fi

Редактируем файлы (под каждым юзером, работающим с иксами):

1. ~/.xsession:

. $HOME/bin/mktmp.sh
sh -c "setxkbmap -layout 'us,ru(winkeys)' -option 'grp:caps_toggle,grp_led:scroll'"
xrdb $HOME/.Xresources
xset b off
YOUR_WIDOW_MAKER &
$HOME/bin/lock.sh &
$HOME/bin/xkbd.sh &
exec xscreensaver

2. В оконном менеджере YOUR_WIDOW_MAKER хоткей локальной блокировки (только текущих иксов) вешаем на команду xscreensaver-command -lock, а хоткей глобальной блокировки — на команду touch /tmp/.lock_dir/lock_file.

3. Редактируем ~/.zshrc, чтобы в его начале было

   . ~/bin/mktmp.sh

   а также добавляем (место неважно) строки

   export LESSHISTFILE=$TMP/.lesshist.$USER
   HISTFILE=$TMP/.zhistory.$USER

4. Редактируем ~/.vimrc, добавляя туда строку

   set viminfo+=n$TMP/.viminfo.$USER

5. (Опционально) Убираем всю ненужную информацию из окна приглашения xscreensaver'а, добавляя в ~/.Xresources:

xscreensaver.cycle:                 0
xscreensaver.lock:                  True
xscreensaver.lockTimeout:           0
xscreensaver.pointerPollTime:       1
xscreensaver.splash:                False
xscreensaver.splashDuration:        0
xscreensaver.overlayTextBackground: #ffffff
xscreensaver.fade:                  True
xscreensaver.fadeSeconds:           0
xscreensaver.timeout:               20
xscreensaver.timestamp:             False
xscreensaver*dateFormat:            
xscreensaver*Dialog.headingFont:            YOUR_FONT
xscreensaver*Dialog.bodyFont:               YOUR_FONT
xscreensaver*Dialog.labelFont:              YOUR_FONT
xscreensaver*Dialog.buttonFont:             YOUR_FONT
xscreensaver*Dialog.dateFont:               YOUR_FONT
xscreensaver*passwd.passwdFont:             YOUR_FONT
xscreensaver*passwd.body.label:             
xscreensaver*passwd.user.label:             
xscreensaver*passwd.uname:                  False
xscreensaver*newLoginCommand:               cat > /dev/null
xscreensaver*passwd.heading.label:          
xscreensaver*passwd.login.label:            
xscreensaver*passwd.passwd.label:           test
xscreensaver*passwd.asterisks:              False
xscreensaver*Dialog.foreground:             #010101
xscreensaver*Dialog.background:             #000000
xscreensaver*Dialog.Button.foreground:      #000000
xscreensaver*Dialog.Button.background:      #000000
xscreensaver*Dialog.Button.pointBackground: #000000
xscreensaver*Dialog.Button.clickBackground: #000000
xscreensaver*Dialog.text.foreground:        YOUR_COLOR
xscreensaver*Dialog.text.background:        #000000
xscreensaver*passwd.thermometer.foreground: #000000
xscreensaver*passwd.thermometer.background: #000000
xscreensaver*Dialog.topShadowColor:         #000000
xscreensaver*Dialog.bottomShadowColor:      #000000
xscreensaver*Dialog.logo.width:             200
xscreensaver*Dialog.logo.height:            300
xscreensaver*Dialog.internalBorderWidth:    0
xscreensaver*Dialog.borderWidth:            0
xscreensaver*Dialog.shadowThickness:        0
xscreensaver*programs: \
    feh -F /path/to/file/wallpaper.jpg \n

6. (Опционально) С xdm'ов тоже зачищаем всю ненужную информацию:

   xlogin*greeting:
   xlogin*passwdPrompt:
   xlogin*namePrompt:
   xlogin*promptColor: black
   xlogin*fail:
    
   #ifdef COLOR
   xlogin*geometry: WIDTHxHEIGHT+0+0
   xlogin*borderWidth: 0
   xlogin*frameWidth: 0
   xlogin*innerFramesWidth: 0
   xlogin*shdColor: black
   xlogin*hiColor: black
   xlogin*background: black
   xlogin*greetColor: YOUR_COLOR
   xlogin*failColor: YOUR_COLOR
   *Foreground: YOUR_COLOR
   *Background: black
   #else
   ...
   #endif

Как это работает

1. Переопределение /tmp:
   
   При старте из ~/.xsession выполняется скрипт mktmp.sh, который проверяет наличие ранее созданной директории /tmp/$USER и её принадлежность юзеру. Если её нет, директория создаётся, переменные среды экспортируются. Потом эти же переменные для гарантии экспортируются ещё и в конфиге шелла. Уязвимость: посторонний юзер может создать в /tmp директорию с чужим $USER, тогда файлы туда поидее писаться будут не должны, но это может привести к глюкам [можно пофиксить, выбирая рандомное имя для директории (кстати, man mktemp), но тогда в конфиге шелла придётся дополнительно выяснять, есть ли ранее созданная директория, и кому она принадлежит, чтобы в случае уже имеющейся не создавать новую].

2. Блокировка всех дисплеев:
   
   При старте иксов запускается демон lock.sh, который отслеживает появление файла /tmp/.lock_dir/lock_file, сигнализирующего о блокировке кем-то под другими иксами (посольку файлы в /tmp создаются со sticky-битом, в самом /tmp такой файл было бы не создать — посторонние не смогли бы его удалить никак, поэтому пришлось создавать промежуточную директорию .lock_dir). Если сигнал получен, демону xscreensaver передаётся команда на блокировку, а перед удалением файла-сигнала делается 5-секундный таймаут (этого должно хватить, чтобы демоны под остальными иксами успели узнать, что файл появился, и успели заблокировать свои иксы). Теоретически, если слишком часто и быстро блокировать и разблокировать разные иксы, могут быть глюки, но пока их замечено не было. Блокировка происходит практически мгновенно, а пока пароль наберёшь, 5 секунд уже проходит, так что файл успевает удалиться до разблокировки, даже если делать разблокировку сразу же после блокировки. Понятно, что злонамеренный юзер может блокировать экран дргих юзеров. Может быть, могут быть ещё какие-то шелл-специфические уязвимости (возможность у одного юзера принудить другого к выполнению каких-то команд со своими правами), но я их так сходу не вижу. Если что, «глобальная блокировка» абсолютно эквивалентна следующим действиям: вручную поочерёдно переключиться в каждые из иксов и локально выполнить xscreensaver-command -lock, никаких сайд-эффектов нет. Чтобы это давало ожидаемую безопасность, никто не должен быть залогинен в текстовых консолях (рута можно получать по SSH из-под специально выделенного пользователя, тоже логинящегося через иксы).

3. Пофикс раскладки:
   
   С раскладкой всё аналогично: при старте иксов запускается демон xkbd.sh, который отслеживает состояние демона xscreensaver'а. Если зафиксировано блокирование экрана, раскладка меняется на английскую, если разблокирование — то делается возврат к русско-английской (переключатель раскладки уже задан в ~/.xsession, поэтому его менять не требуется). Демон xscreensaver'а генерирует строку об изменении состояния, только когда оно реально произошло, поэтому висящий в памяти в бесконечном цикле процесс ничего лишнего не ест и реагирует только тогда, когда надо.

4. XScreenSaver:
   
   Конфигом xscreensaver'а убирается всё лишнее, остаётся только логотип и имя пользователя, при наборе пароль не отображается. Логотип прибит гвоздями к коду и так просто (без перекомпиляции xsreensaver'а) его, возможно, ни заменить, ни убрать (автор сильно возражает против таких действий, считая его своего эквивалентом упомиании авторства и лицении продукта). Многие поля глючат и не удаляются, это решается стандартным хаком: делаем чёрный фон и на нём чёрные буквы (xscreensaver'у это иногда не нравится и он начинает умничать и глючить как консоль, включая принудительную инверсию цветов, но это обходится хаком «выставим цвет шрифта почти чёрным: #000001»). В принципе, имя пользователя этими хаками тоже можно убрать (помня, на каком дисплее какой юзер залогинен, это не составляет большой проблемы, а по незначительному перемещению логотипа по экрану можно различать режим ввода пароля и режим его проверки). Все свистелки и рюшечки отключены, по умолчанию рисуется картинка (wallpaper) и всё (никаких анимаций). В идеале можно сделать так, что постороннему будет вообще непонятно, что происходит на экране, и работает ли компьютер вообще.

5. XDM:
   
   С настройкой xdm всё сделано аналогично: есть возможность набрать имя пользователя и нажать Enter, ничего более на экране не пишется, даже слов login и password (как и в случае xscreensaver'а). В xdm достаточно легко сделать полностью чёрный экран без каких-либо опознавательных знаков. Правда, большого смысла это не имеет, если аналогичным образом не «пофиксить» приглашение в консоли. С учётом того, что цвет шрифтов в тип курсора по умолчанию (до логина пользователя) в консоли в Linux никак, похоже, штатно не меняется, проблема пофикса консоли нетривиальная.

Что не работает

-a bind_address

Bind the agent to the UNIX-domain socket bind_address. The default is $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>.

FILES

$TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>

UNIX-domain sockets used to contain the connection to the authentication agent. These sockets should only be readable by the owner. The sockets should get automatically removed when the agent exits.

$ echo $TMPDIR
/tmp/USER
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXXXXXXX/agent.XXXXX; export SSH_AUTH_SOCK;
SSH_AGENT_PID=XXXXX; export SSH_AGENT_PID;
echo Agent pid XXXXX;

$ ssh-agent -a ~/.ssh/agent.XXX
SSH_AUTH_SOCK=/home/USER/.ssh/agent.XXX; export SSH_AUTH_SOCK;
SSH_AGENT_PID=XXXXX; export SSH_AGENT_PID;
echo Agent pid XXXXX;

Вот этим мне и не нравятся скриптовые решения — каждый лепит по своему вкусу. Это допустимо и нормально, ведь скрипт — не минималистичная утилита. Тогда лучше набор команд с коментами, а каждый пусть сам из них соорудит скрипт под свои задачи. А авторский скрипт уже в конце повествования отдельным документом, как пример реализации идеи. Кто хочет, пусть изучает целиком.

И ресурс превращается … в аналог анонимной почтовой рассылки.

P^[link173].S. Источники вдохновения: первый^[link168] и второй^[link169].

In Debian, ssh-agent is installed with the set-group-id bit set, to prevent ptrace(2) attacks retrieving private key material. This has the side-effect of causing the run-time linker to remove certain environment variables which might have security implications for set-id programs, including LD_PRELOAD, LD_LIBRARY_PATH, and TMPDIR. If you need to set any of these environment variables, you will need to do so in the program executed by ssh-agent. © man ssh-agent

s^[link176]sh через такую соксификацию работает, только если вместо хоста указать IP-адрес.

/usr/bin/ssh-agent /home/USER/.xsession

use-ssh-agent

If the ssh-agent(1) program is available and no agent process appears to be running already, the X session will be invoked by exec'ing ssh-agent with the startup command, instead of the startup command directly. © man 5 Xsession.options

Всему виной то, что в /etc/X11/Xsession.options указано use-ssh-agent (там же заодно можно отключить и use-session-dbus, включенный по умолчанию).

Л^[link180]еннарт как-то сказал, что баги системд теперь должны исправлять мейнтейнеры тех дистров, в которых они были обнаружены. Лол. Апстрим системд, похоже, теперь только разрабатывает фичи...

Я^[link181] не могу отрицать, что мы, как команда разработчиков [широкоиспользуемого] апстрима, получили порядочную степень влияния. Тем не менее, не мы занимались интеграцией systemd в дистрибутивы; это делали их разработчики. Мы даём базовые рекомендации о том, как следует поставлять и использовать компоненты systemd, но вообще это не наше дело. Дистрибутивы регулярно многое переделывают или вносят изменения в код, и это абсолютно нормальная ситуация. В самом деле, даже Fedora и RHEL иногда делают некоторые вещи по-другому, при том что я сам участвую в сборке systemd для этих дистрибутивов! Мы предоставляем основу, а дистрибутивы затем адаптируют её к своим нуждам.

Мы стараемся обеспечить разнообразие в команде разработчиков systemd; сделать так, чтобы она отражала мнение сообщества в целом. Среди нас есть люди из Debian, Canonical, Mageia и Tizen (о Fedora/RHEL вы наверняка уже догадались). Вообще говоря, одна из наших задач — это плавно прекратить управлять происходящим.

п^[link182]оттеринг принципиально скидывает это на дистростроителей, он открыто говорит, что "мне пох, их возня"

А всё этим не гут и закончится. Другое дело, что systemd, похоже, неизбежен. Несмотря на то, что он — такой же кошмар как и OpenSSL. Его неподдержка, частичная поддержка, возможность выпиливания — чисто формальная.

И работоспособность официально не гарантируется. Пока мы оказываемся в положении выбора самого плохого из двух зол одновременно: что-то уже может не работать без systemd, а что-то — ещё быть не допиленным для работы с ним.

LFS, дистросрач. Сильно подозреваю, что много чего будет на него завязано почти намертво и Gentoo это не разрулит. Первый кандидат — SELinux. Затем, могут быть всякие штуки, связанные со звуком. В своё время все также шарахались от LVM или от GRUB. В принципе, можно до сих пор ими не пользоваться.

"With jessie, it will become /easier/ to choose the init system, because neither init system is essential now. Instead, there is an essential meta-package "init", which requires you to install one of systemd-sysv | sysvinit-core | upstart. In other words, you have more choice than ever before."

This statement is actually correct; until this change it was not possible to completely replace sysvinit with another init system without running dpkg-divert commands to divert the init away.

When, in fact, there IS no way to prevent systemd from being installed during installation (except for upgrades).

That preseeding doesn't do this is a bug, it's filed (#668001), and the patch for it was just written on Friday the 17th. Because Debian is going to freeze in less than three weeks, the maintainers are wary of applying this patch this close to release without extensive testing.

Furthermore, the effect of this patch is trivially obtained by using a late_command to remove systemd-sysv and install sysvinit-core.

If you actually want to see this patch applied to the version of the Debian installer that Jessie will release with, you should coordinate with the nice people in #debian-boot to see what type of testing they would want to see before they are willing to vet the patch.

У меня есть свои^[link185]:

Caution
Be advised that some packages may have degraded behavior or may be lacking features under a non-default init system.

Файл ~/.zcompdump, вроде как создаваемый командой compinit, можно отправить туда же, заменив в ~/.zshrc

compinit

compinit -d $TMP/.zcompdump.$USER

ANTIGEN_COMPDUMPFILE=$TMP/.zcompdump.$USER

К удивлению обнаружилось, что ~/.xsession-errors не так безобиден, как казалось раньше. Например, туда попадает выхлоп из управления музыкальным демоном mpd со списком проигрываемых композиций, чего явно не ожидалось. По всей видимости, это лечится только грязными хаками. Самое простое — заменить строчку

ERRFILE=$HOME/.xsession-errors

ERRFILE=/tmp/$USER/.xsession-errors
USERTMPDIR=/tmp/$USER
if ! [ -d $USERTMPDIR ] ; then
    mkdir -p $USERTMPDIR
    chmod go-rwx $USERTMPDIR
fi

T^[link187]or-enabled Debian mirrors

Richard Hartmann, Peter Palfrader, and Jonathan McDowell have set up the first official onion service mirrors^[link188] of the Debian operating system’s software package infrastructure. This means that it is now possible to update your Debian system without the update information or downloaded packages leaving the Tor network at all, preventing a network adversary from discovering information about your system. A follow-up^[link189] post by Richard includes guidance on using apt-transport-tor^[link190] with the new mirrors.

These services are only the first in what should hopefully become a fully Tor-enabled system mirroring “the complete package lifecycle, package information, and the website”. “This service is not redundant, it uses a key which is stored on the local drive, the .onion will change, and things are expected to break”, wrote Richard, but if you are interested in trying out the new infrastructure, see the write-ups for further information.

Вроде работает. Торовский реп и security.debian.org, наверно, должны остаться обычными ссылками, доступ к которым идёт через Tor.

man xscreensaver-command:

-exit

Causes the xscreensaver process to exit gracefully. This does nothing if the display is currently locked.

Warning: never use kill -9 with xscreensaver while the screensaver is active. If you are using a virtual root window manager, that can leave things in an inconsistent state, and you may need to restart your window manager to repair the damage.

xscreensaver-command -exit действительно работает нормально, kill не нужен.

R^[link193]HEL has a standardized way of manipulating Linux firewall. File ‘/etc/sysconfig/iptables’ has stored firewall in iptables-save format. Since I have to sometimes use Debian based distributions, I often wondered why there isn’t a similar (standardized) way of handing iptables. Somene suggests to use UFW or Shorewall, but that are just wrappers around iptables made to make users life easier. But if you are iptables expert, then using wrappers is only drawing attention to wrong things and bringing in another layer of unnecessary complexity. So after a little research I found a better way to handle iptables on Debian distros. It’s called “iptables-persistent“. All a user has to do is:

# apt-get install iptables-persistent

Не знаю, насколько этот способ надёжен и конвенционален в данный момент.

/comment78166^[link194]

Разработчик OpenBSD рассказывает, почему они решили вообще отказаться от PGP. Я было подумал, что дело, как всегда, в GPL-лицензии, а им BSD надо. Как же я был неправ... Всё намного хуже. Мазохистам следует одеть шлем перед прочтением бессмертного^[link195], чтобы не разбить лицо фейспалмами. Самая вкуснятина:

The first most likely option we might consider is PGP or GPG. I hear other operating systems do so. The concerns I had using an existing tool were complexity, quality, and complexity.

There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again. Even though the end user is actually shielded in most cases from ever directly interacting with signify, I felt it was important that users be able to quickly understand how everything worked.

We wanted to ensure all the code involved in signing met our quality standards. Without digressing too much, we have much more control over the quality of code that's developed in tree versus code developed elsewhere and imported.

The complexity of the code is also a factor. All those complex features require lots of complex code, which balloons the size of the import and makes auditing nearly impossible. Even if a perfect PGP codebase existed, how would we be able to identify it? Or as Prof. Green put it^[link196], "Can someone who built GnuPG 2.1.1 on Debian/Ubuntu give me a hint on which libgpg-error you used?" If he doesn't which libgpg-error to use, I doubt I'm going to pick the right one.

PGP/GnuPG – сложно, overengineered и непонятно. Кода в GnuPG много, а там, где много кода, там дыры, поэтому GnuPG они использовать не будут, а напишут свой велосипед, простой и понятный, с короткими ключами. Будут распространять его в виде QR-кода^[link197]. Пришёл на конференцию – заснял слайд с QR-кодом, вот тебе верификация:

Feel free to take a picture if you like. That's the public key for the current 5.7 release. Technically, a key will more likely and more conveniently exist in text form, but if you are concerned about how to authenticate that the key on the website hasn't been tampered with, and the CD in the mail wasn't interdicted, you can always come to a BSD conference and take a picture. Assuming you're foolish enough to trust your camera's image sensor firmware.

Inside the base64 data are the fun bits. Decoded, there are 2 bytes which say "Ed" in case we ever need to change algorithms, 8 random bytes used to detect accidental key signature mismatches and give friendlier error messages, and then the 32 bytes of actual key. A signature is exactly the same format, but 64 bytes long instead.

In the interest of promoting inter-BSD cooperation, I figured I'd also show you the FreeBSD security officer key in case you'd like to take a picture of that as well.
<...>
Hope you brought a zoom lens.

Очень смешно, и весь зал на этой минуте, наверно, ржёт. Расскажите им про то, что ключи идентифицируются по отпечаткам, а не по текстовому выводу, а также о том, что ключ такой длинный не просто так, а из-за навешанных подключей и чужих подписей.

Artifacts
Before we go into how signing and verifying work in progress, I'm going to digress to define the term artifact. Artifacts are what we ultimately wish to verify. This includes the built releases and packages. It also includes the errata, since they are like an addendum to the release. But it doesn't include miscellaneous communications or announcements or the web site. I introduce this term because in crypto speak we usually talk about signing and verifying messages, which is exactly what signify does, but that's not to say we use it for messages in general.

Наш велосипед прекрасен, но, право, мы сами догадываемся, что подписывать им важные текстовые сообщения было бы абсурдом, поэтому мы не будем его позиционировать как универсальный инструмент для создания подписей. Мы его используем для подписи так называемых "артефактов" – сообщений, которые код, а не просто сообщений. Просто сообщения мы не подписывали и подписывать не будем. Мне или кажется или впрямь было когда-то такое, что Тео попросил не спамить OpenBSD-рассылку заголовками PGP-подписанных сообщений?

pkg_add also uses signify behind the scenes to verify every package. Unless something goes wrong, this is even more transparent to the user. The signature scheme is similar. Packages already contained SHA256 checksums for integrity checking, so again, it's those checksums that are signed. However, the signature is not available separately. It's contained entirely within each package. The packages data contains too much data to atomically sign all the packages. Anybody attempting to update during an rsync would see too many failures.

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

Key Rotation

After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation. We don't directly sign keys with keys, however, but the next key is implicity signed by its inclusion in a signed release. Each key is tied to a release and only used for artifacts relating to that release.

We do this for a couple reasons. First, if you don't have a key rotation plan in place in case of emergency, your emergency will end poorly. Trying to actually recover from a compromised key is more or less impossible in my opinion. Revocation is probably a cure worse than the disease. Without any great effort, however, our key rotation schedule will automatically cycle out the bad key. Even if we do nothing, or never notice the compromised key, its utility to an adversary is limited. The tried and true solution to many problems: ignore it until it goes away.

Additionally, we have an automatic upgrade path established if we need to switch to a different algorithm.

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

Key Infrastructure

I've covered how signify helps get OpenBSD from us to you. But that's assuming you have a trusted signify public key. That's an egg. As also mentioned, if you are already running OpenBSD (i.e., the chicken), that includes the next key. If you have either the chicken or the egg, you're all set. But what about people with neither?

There are no key servers for signify. No web of trust. Just keys. The good news is the keys are pretty small. As demonstrated. We can stick them just about everywhere, and we do. They're on the web site, they're on twitter, they're on the top side of CD. 56 base64 characters. You can read it out loud over the phone in under a minute. Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.

Ключ маленький, его можно везде написать, на каждом заборе, поэтому не нужны ни сервера ключей, ни сеть доверия, ничего. Иметь один долгосрочный ключ подписи – видимо, плохая идея, поэтому каждый релиз будет выходить со своим публиным ключом + публичный ключ на следующий релиз. Подписывать новые ключи старыми мы тоже не будем. Мы будем подписывать только весь релиз, в котором, среди прочего, есть новые ключи. Если кому-то захочется проверить цепочку подписей, пусть выкачивает все релизы.

Есть одна беда, правда... наш велосипед есть только в OpenBSD и больше нигде. Мы не заморачивались тем, чтобы сделать порты под другие системы, поэтому если у вас ещё нет OpenBSD, то подписи вы не проверите никак, разве что будете сами компилить наш велосипед из исходников. Официальная инструкция^[link198] в таких случаях рекомендует просто расслабиться и получать удовольствие. Проверьте только хэши – куда деваться:

If you have an existing OpenBSD 5.5 or higher installation, you can run signify(1) to verify the signature and checksum. For example, run the following to verify that the cd60.iso file was distributed by the OpenBSD team:

signify -C -p /etc/signify/openbsd-60-base.pub -x SHA256.sig cd60.iso

If you are unable to run or compile signify(1), use sha256(1) with the SHA256 file to see if a file was corrupt during the transfer.

P.S. Они так видят? У них своя правда? Есть в этом элемент здравого смысла, хоть какой-то? Или они окончательно там все упоролись?

Что интересно, эти люди написали сверх-overengineered OpenSSH, но запрещают остальным ковыряться в носу. Из шифрования telnet-сессии сделали гигантский комбайнер, чем только не обвешанный, а понять, почему так же вышло с подписями и шифрованием сообщений, они почему-то не в состоянии. Сидят, радуются, что часть криптографии для их велосипедных подписей можно теперь из OpenSSH взять.

Это всё ещё пол беды. Казалось бы, сделайте PGP-подписи релизов для остальных, хуже-то не будет от PGP-подписанных хэшей. Но нет, не их путь. Подписывает Linux, подписывает FreeBSD, подписывает NetBSD, подписывает DragonFlyBSD. А OpenBSD не будет, оно пойдёт своим путём. Решил Тео забросить свой PGP-ключ, созданный в далёком 1997-ом^[link199] – и всё. Ничего PGP-шного больше нет.

А нормальных бинарных апдейтов как не было, так и нет^[link200]:

For the OpenBSD base system, there are three options:

• Upgrade your system to -current. As all fixes are applied to the -current code base, updating your system to the latest snapshot is a good way to get all the fixes at once. However, running -current is not for everyone.
• Update your system to -stable This is done by fetching or updating your source tree using the appropriate -stable branch, then recompiling the kernel and userland files. Overall, this is probably the easiest way, though it takes longer since the entire system gets rebuilt.
• Patch the affected files individually. While this typically requires less time than a CVS checkout/update and rebuild, there is no one universal set of instructions to follow. Sometimes you must patch and recompile one application, sometimes more. All patches posted to the errata web page are made directly against the indicated release's source tree. This method is explained in more detail below.

Гарантированный и рекомендуемый способ – всё тот же: нужно обновить один файл – скачайте апдейт к исходникам всей базовой системы и перекомпильте её всю с нуля.

If you are unable to run or compile signify(1), use sha256(1) with the SHA256 file to see if a file was corrupt during the transfer.

Other projects use a variety of tools for this, but unfortunately none of them were invented here. signify is a small tool I wrote to fill that gap. Here’s a few notes about it, working from the top down.

I wonder how many people have ever revoked their PGP keys to see how it works in practice. The reop trust model is very simple. You can probably even understand it.

Keys don’t expire. If we expand the scope of inquiry slightly to TLS certs, I’ve lost count of the problems I’ve seen caused by prematurely expiring certs. Number of times an expired cert has saved my ass? Zero. This is arguably shortsighted, I know.

You can’t embed a JPG selfie into reop keys. Not even a tiny one.

reop doesn’t include a Tempest resistant font for viewing top zecret messages.

The following files describe the development efforts of the OpenSSH portability development team. The release files are signed with the PGP public key contained in the file RELEASE_KEY.asc on the ftp site. This key is also available through the key server network.

One of the things OpenBSD has never done is sign releases, for whatever reasons. But 2014 is a new year, time to make a change. The first thing you need to start signing OS releases (besides the release itself) is a signing tool. Other projects use a variety of tools for this, but unfortunately none of them were invented here. signify is a small tool I wrote to fill that gap. Here’s a few notes about it, working from the top down.

Еще обращу внимание на вроде как безобидный с виду MC.
Но если лишить компьютер сети, то при запуске MC надолго подвисает,
ожидая сетевого соединения – зачем ему это??
Не иначе как хочет собщить, как минимум, что он установлен на этом компьютере.

Мда. Глядя, в какое дырявое решето, более того – в шпионскую сборку превратился Linux под чутким руководством некоего космонавта в сговоре с M$, поневоле задумываешься –
а может, ну их нафиг, эти сомнительные с точки безпасности Линуксы, и пока не поздно еще, свалить на какую-нибудь неиспорченную еще BSD?

Я люблю почитывать опусы, как хороши, например, FreeBSD своей продуманной политикой и продуманной, тщательно выверенной архитектурой, но сколько раз её ставил, начиная 3.x, столько раз её и сносил :))

For the last few months, I've been working on a hypervisor for OpenBSD.

One might ask – why not port one of the other hypervisors out there instead of rolling your own from scratch? Fair question. However, for various technical reasons, choosing to port an existing vmm just didn't make a whole lot of sense. For example, I've been baking in support for things that the other implementations don't care about (namely i386 support, shadow paging, nested virtualization, support for legacy peripherals, etc) and trying to backfit support for those things into another hypervisor would probably have been just as hard as building it from the ground up.