Список следящего ПО (безопасная установка Debian)

Tor-enabled Debian mirrors

Richard Hartmann, Peter Palfrader, and Jonathan McDowell have set up the first official onion service mirrors 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 post by Richard includes guidance on using apt-transport-tor 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 не нужен.

RHEL 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

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

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, "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-кода. Пришёл на конференцию – заснял слайд с 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, то подписи вы не проверите никак, разве что будете сами компилить наш велосипед из исходников. Официальная инструкция в таких случаях рекомендует просто расслабиться и получать удовольствие. Проверьте только хэши – куда деваться:

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-ом – и всё. Ничего PGP-шного больше нет.

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

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.

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

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

---

Там всё намного сложнее. Ноги растут, как явствует из блога автора, отсюда и отсюда. PGP хоронится на основании этого и этого обзоров, также есть отсылка к оригиналу комментария. Обзоры хорошие, профессиональные, но выводы из них были сделаны неправильные: всё-таки между утверждениями "PGP – зло" и "PGP – зло, но ничего лучшего пока не придумали" большая разница, и эта разница не была разработчиком, как я понял, осознана. К тому же, они не отказываются от своего фирменного подхода к разработке софта – NIH-синдрома:

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.

"Давайте сделаем всё по-своему, а не как в GNU-тусовке. Теперь и в PGP". NetBSDшники когда начали пилить NetPGP, хотя бы не стали рушить OpenPGP стандарт, в отличие от этих.

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

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

С подписями вообще интересно. Из комментария Mike Perry был сделан вывод, что сеть доверия не работает. CA, понятно, тоже не работает. Значит, никакие механизмы установления доверия не лишены серьёзных недостатков. А раз так, давайте откажемся от всех механизмов доверия вообще, включая подписи одних ключей другими – всё равно ведь это полумеры. Типа, если так уж надо, можно отдельно файл с чужим ключом подписать, а тащить это в ядро нового криптостандарта незачем.

Отзыв ключей тоже не нужен, потому что:

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.

Без комментариев.

И всё в таком духе. Теперь на основе signify они пишут свой PGP с блэкджеком и BSDшницами. Назвали его reop – "reasonable expectation of privacy":

-----BEGIN REOP SIGNED MESSAGE----- "So, you're the UNIX guru." At the time, Randy was still stupid enough to be flattered by this attention, when he should have recognized them as bone-chilling words. -----BEGIN REOP SIGNATURE----- ident:tedu RWS1l0sm+eG0IZ7/JZ7V3Ct584XleF33BQkIiXmHNHjHKWTBZprpVPeiLsCpkRFL1m0y3z7xFBkx nzoNVbTELwB932C1rdllJwQ= -----END REOP SIGNED MESSAGE-----

Не без стёба сравнили его с GnuPG:

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.

Вот. И всё в таком духе, причём это не какая-нибудь фрикота с улицы – эти люди пишут OpenSSH, PF и LibreSSL. Мне интересно, а как OpenSSH попадает в линуксовские пакеты, если PGP-подписей на нём нет изначально? Всё-таки есть:

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.

Наверно, принудили. А для самой OpenBSD подписей, судя по этому заявлению разработчика, до signify не было:

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, столько раз её и сносил :))

/comment69526:

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.

Написать свой PGP – мало, почему бы не написать собственный гипервизор после всех заявлений о ненужности виртуализации?