FOSDEM 2020
Today I’m back from the FOSDEM 2020. Like usual, full of impressions, a lot of new ideas, new concepts (these will be transformed to the new git commits in the next few months). An mix of innovative ideas and new concepts together with unstoppable improving the Free Software as a platform for self-realization and self-expression vividly recreates the vision and understanding of new tendencies. It changes our priorities and directions. It changes what we are thinking about.
This time I spent a lot of time to the quite new topic for me – the microkernels. Last few months I became interested in the basic concept of the seL4 system. Fortunately, Gernot Heiser, who is head of the seL4 project, has started the microkernel DEV room on Sunday with its overview of seL4’s state in terms of functionality, verification, ecosystem, deployment and community. It’s highly recommended to watch all of these (microkernel) videos on the fosdem page 🙂
This year FOSDEM celebrates 20 years. By the way, my first visit this event was ten years ago, in 2010. So, I also celebrate some kind of jubilaeum there 😉
I’m going to continue visiting FOSDEM. But next year I’m going also to have a talk there. See you next year 😉
pam-python: local root escalation (CVE-2019-16729)
Last week the openSUSE Security Team spent some time to check and review the PAM module from the pam-python project. Main reason for that – to make sure that the source code of the project is secure enough and bug free of course. Badly implemented PAM modules may cause user authentication to always succeed or otherwise badly influence security.
The audit process was done by Malte Kraus. He found the local root exploit in version 1.0.6, which was the last stable one since August 2016. Reaction from the upstream comes immediately: Russell Stuart, who is author of pam-python, released the new official version – 1.0.7.
PAM module from version 1.0.7 is whitelisted by openSUSE Security Team. I rebuild the new packages of pam-python and made it available for all openSUSE users.
https://openbsd-ru.github.io/
Проект OpenBSD отказался от поддержки преводов своей страницы несколько лет назад. Безусловно, в этом есть свой резон. Я уважаю мнение Тео. Но я должен сказать, что я уважаю мнение и тех, кто просто хочет иметь документацию на родном языке. К тому же, если эту самую документацию они готовы создать, т.е. сделать перевод, сами. Не вижу тут абсолютно никакого конфликта. Лицензия это позволяет. Дух проекта OpenBSD как бы тоже постоянно говорит нам об открытости и свободе.
Не знаю почему именно сейчас. Возможно потому, что, помимо использования OpenBSD дома, я снова столкнулся с этой ОС и на работе, а во-вторых, один из моих знакомых просто заболел этой системой, и я, при встрече с ним, постоянно слышу от него о её достоинствах (именно о тех достоинствах, в которые влюбился еще в начале 2000х, когда впервые узнал об этой системе и опробовал её, учась на втором курсе университета). В общем, я решил поднять исходники, которые поддерживал когда-то на протяжении нескольких лет, и обновить их в новой, так сказать, оболочке – использовать для них github pages.
Цель проекта… хм… да все тот же just for fun 😉
Проекты локальных сообществ OpenBSD как правило живут не очень долго. У нас это openbsd.ru или obsd.ru. Были и другие. Все они сегодня, к сожаленью, оффлайн. Поэтому новый проект я решил размещать не в своем “домашнем” проекте на github (мало ли что со мной случится), а создать новую “организацию”, куда планируется принимать особо активных. Надеюсь, это придаст проекту живучести 🙂
Если вы заинтересованы в развитии этого проекта, вам это интересно и вы готовы помочь, я приглашаю всех и буду рад любой помощи! Все что вам для этого потребуется – аккаунт на github и немного времени. Просто отправьте pull request, добавив в README что именно вы хотите перевести и ссылку на свой аккаунт.
Загрузить исходники страниц можно так:
$ cvs -d anoncvs@mirror.osn.de:/cvs get -P www $ $ cd www $ cvs -q up -Pd
Две последние команды синхронизируют/обновляют локальный cvs-репозиторий. Можно, кстати, использовать и github-зеркало, как предлагает Сергей.
После этого перевести текст, оставляя html-код один в один, и добавить его в наш git-репозиторий.
Сейчас я мигрирую уже существующий перевод из этого репозитория. Перевод устарел, но все желающие могут использовать его для перевода новых, используемых сейчас, web-страниц. Кто-то захочет переводить FAQ, кому-то интересно что-то другое, кто-то поможет вычиткой, а кто-то, к примеру, и вовсе соберет статистику поломаных ссылок. Любая оказанная помощь поможет проекту.
OpenBSD – Full Disk Encryption
Пару лет назад я писал о подготовке флешки и последующем процессе установки с нее OpenBSD. Тема, которую я там не затрагиваю, и которой я хотел бы сейчас дополнить тот пост, – full disk encryption. Очень важная на мой взгляд. Я писал уже о шифровании дисков в openSUSE, теперь вот наконец-то настал черед и этой прекрасной Unix-like системы из семейства BSD.
Поддержка softraid crypto boot появилась в OpenBSD (для i386 and amd64) начиная с версии 5.3 в 2013 году. Именно тогда bioctl(8) – интерфейс для работы с RAID – стал поддерживать так называемую CRYPTO discipline, используемую для шифрования дисков. К слову, в Linux Kernel используется аналогичный метод – там эта функциональность встроенна в devmapper, первоночально используемая только для LVM.
В процессе инсталляции OpenBSD не предусмотренно вопроса о шифровании диска. Для этого нам потребуется сразу же после приглашения установщика, перейти в консоль и подготовить диск самим.
читать дальше …
Red Hat Forum | Munich
В этот вторник, 15.01, в Мюнхене прошел Red Hat Forum. Я не стал пропускать эту однодневную конференцию по нескольким причинам. Во-первых, интересно было узнать что-то новое по поводу покупки “красной шляпы” IBM. Во-вторых, тут предоставлялась возможность крупным клиентам RedHat поделиться своим опытом и рассказать об успешних проектах, реализованных на этой системе. В-третьих, конференция содержала несколько достаточно интересных технических докладов о OpenShift, Kubernetes, контейнерах и вообще cloud-технлогиях и экосистеме.
Я помню, что еще лет 10 назад, когда я работал в SUSE, cloud не был такой горячей темой. Бум cloud-технологий произошел уже после. С тех пор, естественно, многое изменилось на рынке труда и технологиях, используемых в самих GNU/Linux системах. Уже сейчас, спустя каких-то 10 лет, я чувствую, что бежать за технологиями, притом не просто учить новое, но именно переучиваться, надо уметь все быстрей и быстрей.
На конференции был стенд и Microsoft. После того как в 2014 году их генеральным директорм стал Сатья Наделла, политика этой компании стала кардинально меняться. В лучшую сторону. То, что открытая модель разработки победила, сегодня уже понятно абсолютно всем, и даже Microsoft не является тут исключением. В прошлом году мне, как Linux разработчику, предлагали remote работу в ирландском отделении этой компании. Я отказался. И не потому, что не хочу remote, когда у меня трое детей дома, и не потому, что Microsoft был нашим главным конкурентом в 90е и 2000е, но потому, что несмотря на изменение своей политики, основные продукты остаются закрытыми. Понятно, что такой крупной компании очень тяжело перевести все на новые рельсы, но это… это не моя проблема 🙂
Одним из клиентов RedHat является Landeshauptstadt München. Было приятно встретить бывших коллег из LiMux Team. Но LiMux, как всем известно, основан на Kubuntu, а вот RHEL используется как основная ОС для инфраструктуры гос.учреждений в столице Баварии. И если LiMux-проект закрывается в конце следующего года, то с RedHat-серверов никто слазить у нас тут в городе не собирается. Напротив, полным ходом идет повсеместное внедрение контейнеров и cloud-технологий.
Что я могу сказать на последок? По поводу IBM ничего конкретного узнать мне не удалось. Зато я узнал о новых интересных проектах, используемых в cloud-экосистеме и возможностях, предоставляемые ими. Познакомился с новыми людьми, получил приглашение на работу и кучу geek-футболок 🙂 Конференция дала заряд мотивации и интерес к дальнейшему изучению cloud-технологий. В общем, я классно провел день и остался под впечатлением 🙂
OpenBSD SNMPv3 check
Few weeks ago I spend some time to playing with SNMPv3 on OpenBSD. Now I rewrite my old SNMPv2c script. New script is implemented in Python3, uses easysnmp library and supports all three authentication methods of SNMPv3.
New version of script supports everything what supports old one. It’s standard monitoring stuff (common used by Icinga/Nagios/Centreon) like file system space usage, RAM or SWAP usage, CPU load average, number of running process. It also provides information about installed NICs, running processes and mounted file systems.
But here is still a lot to do. It’s still unstable and doesn’t support external OpenBSD MIBs like PF or CARP, it can’t read parameters from the config file (could be a nice feature, by the way), etc… I tested it on OpenBSD 6.4. But that would be great if someone who uses OpenBSD can help to test it on other/older versions. Source code could be found here (BSD license). Any issues, feedback or bugreports are welcome 😉
Keep reading…
QuckLisp: how to use my own local changes?
One of the first beginner’s questions regarding using QuickLisp is – how to build some Common Lisp project and to see the effect of the local changes if this project is already in the QL-repository? The problem is – each time, when you try to build such project, QL will try to download sources from its repository and that means that local changes will be ignored. First you will maybe try to change the build configuration asd-file, right? This is the wrong way.
In QuickLisp blog I found one post about The Quicklisp local-projects mechanism. One of the goals of this mechanism is to override libraries Quicklisp does provide. Namely, the solution is just a PATH of such projects, i.e. you just should to clone your git-repo into ~/quicklisp/local-projects directory. That location tells QuickLisp to use local source tree and doesn’t use some remote QL-repositories during the build process. You don’t need to change some asd-file or something like that. Good luck and don’t forget to have a lot of fun with Common Lisp 😉
Configuring SNMP v3 on OpenBSD 6.4
Today everyone who cares about its network infrastructure security choice commercial solutions and buys hardware appliances. Usually it’s an easy-to-use “boxes” with some number of network services. Vendors of this appliances provides support. This is one of the reason why many managers like it and choose it. But most important here – usually on those boxes runs OpenBSD. And it is the reason why we, engineers and developers, who are responsible for infrastructure security, love it too 😉
I think, it’s not needed to explain how it’s important to monitor your infrastructure. But it’s also very important to do it in secure way, right? Unfortunately, in its book Absolute OpenBSD Michael Lucas explains about second version of the Simple Network Management Protocol – SNMP v2c – but this is not what we want and should to use today! SNMPv3 – the latest version of SNMP – doesn’t solve all kind of problems, but its usage is more and more desirable today.
As of 2004 the IETF recognizes Simple Network Management Protocol version 3 as defined by RFC 3411–RFC 3418[18] (also known as STD0062) as the current standard version of SNMP. The IETF has designated SNMPv3 a full Internet standard,[19] the highest maturity level for an RFC. It considers earlier versions to be obsolete (designating them variously “Historic” or “Obsolete”).
I’m going to LinuxDay in Dornbirn, Austria
This weekend I am going to LinuxDay, the German-specking Free Software one-day event. It takes place in the higher technical school in Dornbirn, Austria.
Organized by Linux User Group Vorarlberg, it scheduled two timelines of presentations/talks and stands of the many Free Software projects including openSUSE, Debian, Devuan, etc. It looks a bit like a LinuxTag or FOSDEM. Here you can find photos from the last years.
This time it celebrates 20 years, so I think it is a good reason to visit this event now. And not just this. It is very beauty there in this time of the year. For sure I will take my family there and continue to enjoy the traveling on Sunday 🙂
Libre Linux (GNU Kernel) on openSUSE
As we known, openSUSE project doesn’t provide official packages for Linux Libre kernel. There is a simple reason for that: default openSUSE kernel doesn’t include some proprietary modules; it’s free. All proprietary parts of the kernel could be found in a separate package kernel-firmware. But anyway there are users who want to use exactly GNU version. So, why not? This short tutorial describes how to build and install Libre Linux on openSUSE Leap 15.1 (openSUSE TW needs the same instructions).
Right now in the Leap 15.1 repository the kernel version is 4.12.14.
> uname -r 4.12.14-lp151.16-default
Let’s check the latest available 4.x kernel on the FSF server. Right now the latest avaliable kernel there is version 4.18. Its size is less then 100 Mb. Download it:
> wget -c \ https://linux-libre.fsfla.org/pub/linux-libre/releases/LATEST-4.N/linux-libre-4.18-gnu.tar.xz
Before we continue, I will recommend to verify file integrity. The .sign files can be used to verify that the downloaded files were not corrupted or tampered with. The steps shown here are adapted from the Linux Kernel Archive, see the linked page for more details about the process.
wget -c \ https://linux-libre.fsfla.org/pub/linux-libre/releases/LATEST-4.N/linux-libre-4.18-gnu.tar.xz.sign
Having downloaded the keys, you can now verify the sources. You can use gpg2 to verify the .tar archives. Here is an example of a correct output:
> gpg2 --verify linux-libre-4.18-gnu.tar.xz.sign gpg: assuming signed data in 'linux-libre-4.18-gnu.tar.xz' gpg: Signature made Mon 13 Aug 2018 01:25:14 AM CEST gpg: using DSA key 474402C8C582DAFBE389C427BCB7CF877E7D47A7 gpg: Can't check signature: No public key > gpg2 --keyserver hkp://keys.gnupg.net --recv-keys \ 474402C8C582DAFBE389C427BCB7CF877E7D47A7 key BCB7CF877E7D47A7: 12 signatures not checked due to missing keys gpg: key BCB7CF877E7D47A7: \ public key "linux-libre (Alexandre Oliva) " imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 > gpg2 --verify linux-libre-4.18-gnu.tar.xz.sign gpg: assuming signed data in 'linux-libre-4.18-gnu.tar.xz' gpg: Signature made Mon 13 Aug 2018 01:25:14 AM CEST gpg: using DSA key 474402C8C582DAFBE389C427BCB7CF877E7D47A7 gpg: Good signature from "linux-libre (Alexandre Oliva) " [unknown] gpg: aka "[jpeg image of size 5511]" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 4744 02C8 C582 DAFB E389 C427 BCB7 CF87 7E7D 47A7
The primary key fingerprint looks good.
If everything goes well, untar downloaded kernel:
> tar xfv linux-libre-4.18-gnu.tar.xz > cd linux-4.18
Well… now comes the personal part of the installation process, i.e. you know better what’s you should to care about during creating the config file, what’s hardware do you have and your kernel should support, what kind of optimization do you want to have, etc. That’s the most important step of this entire tutorial. For example, good configured kernel could save few seconds of boot time, bad configured kernel will doesn’t boot at all 🙂
To prepare the configuration file, you will need a base kernel configuration, it’s a plain text file calling .config. The are many ways to create .config file. It’s the same like for official Linux Kernel.
Before we can configure our new kernel we will need to install all needed dependencies.
# zypper in gcc make ncurses-devel bison flex libelf-devel libopenssl-devel bc # make menuconfig # make -j4 # make modules_install # make install
If you newer built a linux kernel before and it makes you scary, you can just make make menuconfig and just close it without to change anything. It will scan your hardware and generate a default config. This configuration will include much more then you will really need, but it guarantees that the new kernel will boot.
After installing we can still find the native openSUSE default-kernel in the GRUB menu. I think, this is the default behavior today in the most GNU/Linux systems. Thus, if something goes wrong and, for example, your new self-configured kernel will not boot, don’t worry.
> uname -r 4.18.0-gnu-lp151.16-default
I think, if it’s your first experience with the kernel compilation process and you will get new kernel that will boot and it will be smaller then default openSUSE kernel, you can be proud of yourself.
Whatever you will get, don’t forget to have a lot of fun 🙂
More info about Linux kernel for beginners could be found on the https://kernelnewbies.org/. More info about GNU Libre Linux could be found on the https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html. And, finally, if you interested in the openSUSE Linux kernel development process, you are always welcome to visit openSUSE wiki portal 😉
virsh, tell me VM’s IP
Сколько же я в пусую потерял времени, не зная, что virsh, оказывается, может без всяких лишних телодвижений просто сказать IP VM. До этого приходилсь постоянно опрашивать arp-кеш. Теперь жизнь станет существенно легче. Если вы, как и я, разработчик, и вам не приходится ежедневно заниматься работой с инфраструктурой, то возможно вы об этом не знаете. В этом случае, думаю, эта инфомация вам пригодится.
К примеру, мне нужно посмотреть какой IP в процессе установки получила VM leap151. При помощи list -all как обычно virsh покажет список всех виртуальных машин, а при помощи domifaddr покажет и айпишник.
Когда-то давным-давно нашел команду domiflist и почему-то решил (не спрашивайте почему (может тогда этой фишки действительно еще не добаили, не знаю…)), что это все, что получится вытянуть через консоль. По этой причине приходилось переводить MAC в IP при помощи заглядывания в arp, для которого нужно, кстати сказать, доустанавливать клиент.
# virsh list --all Id Name State ---------------------------------------------------- 2 debian9 running 3 centos running 5 leap151 running - fedora28 shut off - kubuntu shut off - SunOS shut off - tumbleweed shut off # virsh domiflist leap151 Interface Type Source Model MAC ------------------------------------------------------- vnet2 network default virtio 52:54:00:d7:a6:ab # virsh domifaddr leap151 Name MAC address Protocol Address ------------------------------------------------------------------------------- vnet2 52:54:00:d7:a6:ab ipv4 192.168.122.142/24 #
Решил записать, дабы снова не тратить время на поисковик.
How to detect SSH or SCP is using?
That was interesting to spend some time and to try to detect what kind of service is use SSH. As you know, OpenSSH provides ssh(1) and scp(1) programs. Both use the same protocol and the same port number. In fact, both programs has been developed exactly with purpose to be secure enough to protect its users to network packet analysis. But there is nothing more interesting that to try to figure out how exactly all these things works together and try to find a way to detect what service is used on the server.
My first idea was to get this information from OpenSSH server itself, because I was pretty sure that packet analysis will not help me. There is an option in the config file calling LogLevel. The default value (tested on openSUSE) is set to INFO. Let’s change it to DEBUG3 and restart OpenSSH server. After that try to copy something to the server and check the syslog:
As you can see, server provide this information very easily. The problem is – I need to be root and I need to reconfigure and restart OpenSSH server… that is not intelligent and that’s why it’s a bit boring. How we can get the same information without root-right on the server? There is the second way to get it. You will not need root-right, you will not need to be on the server at all.
Welcome to the network packets analysis 🙂
Yeah, I was wrong to thinking that sniffer will not help. But please don’t misunderstand me, SSH connections is pretty secure! There is no way no recognize or find some differences in secure shell or secure copy connections. What kind of authentication is used – password or publickey authentication – is also terra incognita. Packets generated by OpenSSH looks same in all cases. At least by authentication phase… 🙂
As you know, SSH is a cryptographic network protocol and it operates on the Application layer. It’s great and amazing, but it does nothing with bottom layers. And this is exactly where our story begins.
As I said, authentication phase is secure, but after the new connection is established (open_session phase is done) the picture changes drastically and I would even say – dramatically. The culprit here becomes a DSCP/ToS or Differentiated services.
Differentiated services, as the name says, differentiates the ToS-bit depend on used service. In case of SSH, for secure shell ToS-bit will be sets to 0x10 and for secure copy it has value 0x08. Yes, it seems that the IP header (where ToS-bit is) “includes information” about upper layers content… Unbelievable. I know, it sounds like a craziness. I’m still think that I get something wrong, but let’s repeat it together.
The tcpdump’s expression for filtering content of IP header looks like this:
sudo tcpdump -n -i any -v 'ip[1] & 0xfc == 0x10' and port 22
This filter will parse IP packets, where ToS sets to 0x10 (for normal secure shell).
Change it to 0x08 to get a filter for SCP-connections.
You don’t need to be root on the machine where OpenSSH server is running, you don’t need to login on this machine at all. As we all know, to sniff the traffic (encrypted or not) can be easily happen by using the MITM-attack.
You can add port 22 at the end of tcpdum command to get “SSH packets”, but don’t trust it too much, because… to reconfigure OpenSSH server to use other port, say 2222, is not a big deal. Unfortunately, it seems like tcpdump doesn’t support filters for application protocols like SSH and we can just sets the port number (in the hope of the using of standard port). But there could be used a small trick – at the beginning of the connection establishing (exactly after TCP three-way-handshake), OpenSSH client and server exchange its application version and version of used SSH protocol. It’s not encrypted. This wireshark screenshot shows that system has no idea to what service/protocol belongs this data and it says just “Data”, but you can see in TCP header that port of server is 2222:
Should I say, that theoretically every server (implemented by bad guys) can send the similar “fake SSH-data” to deceive or just to confuse you? 🙂 So, be careful with filter for something like *OpenSSH_; check it carefully.
Russian KDE community
Наконец-то увидел свет новый движок портала https://kde.ru, посвященного русскоязычным пользователям KDE и проету KDE в частности. И хотя сам я уже давно KDE не пользуюсь, до сих пор многое связывает меня с этим проектом. Именно с разработки KDE начался мой путь в мир свободного ПО. Еще будучи студентом я познкомился с проетом GNU, Linux и Qt3, а уже после, в Германии – когда я начал работу в SUSE – занимался разработкой и портированием стека KDE4 на openSUSE (больше всего постов в этом блоге именно о KDE и openSUSE). Мы тогда еще сидели на svn, помните что это такое? 🙂
После SUSE я забросил проект KDE, опробовал и пересел на различные window managers. До тех пор, пока не устроился разработчиком LiMux (Kubuntu на основе собственной management-системы на основе LDAP) тут, в Мюнхене. И хотя занимался я в основном security-проектами, было приятно вспомнить и почти весь KDE стек, который мы создавался более чем 10 лет назад.
Это очень интересный проект. Да, он большой, очень большой, и не всегда это хорошо, тем не менее он обладает самой на мой взгляд продуманной архитектурой. Программировать KDE всегда было здорово не только из-за мощи Qt и самым новейшим инструментам, используемым в проекте, но и благодаря идеям, заложенным в основу структуры стека его компонентов. Очень важным в проекте KDE всегда было сообщество людей, его разрабатывающих. Его окружило много молодых инженеров, открытых для новых, а порой даже и для откровенно сумасшедших идей. Это так освежало. Это так вписывалось в природу свободного ПО. Я никогда не забуду эти хиппи-тусовок по всей Европе, куда мы добирались по ночам и самыми сумасшедшими способами, доклады, подготавливаемые и читаемые друг другу просто ради удовольствия.
Я рад, что и в России есть люди, продолжающие разработку и продвигающие этот проект. Хочу пожелать вам, ребята, удачи. Постарайтесь сохранить эту атмосферу, сводящую с ума и увлекающую за собой. Я думаю, это самый большой стимул для разработки ПО. Увлечение процессом, удовольствие от наконец-то найденного решения, восхищение его элегантностью и простотой. Все это KDE, все это – сообщество людей, его продвигающих.
PoC || GTFO
Давно хотел написать пару строк об этом журнале, но все руки не доходили довести пост до состояния, когда его наконец уже можно опубликовать. В прошлом месяце вышел очередной его выпуск, но из-за смены работы у меня снова не дошли руки. Среди security-инженеров так же бытует мнение, что это не то издание, о котором стоит рассказывать “широким массам”. Спорный момент. Так или иначе No Starch Press выпустила печатное издание всех номеров журнала.
Итак, для тех, кто слышыт об этом журнале впервые, International Journal of Proof-of-Concept or Get The Fuck Out или просто PoC || GTFO представляет из себя интернет-журнал для технарей, любителей поиграться с ЭВМ, чья осведомленность принципами работы последнего не должна вызывать никаких сомнений, ребят, в конец отбившихся от рук и, как правило, стоящих на учете в соответствующих огранах… одним словом – сетевых, тьфууу, хулиганов.
А теперь серьезно – этот материал будет немного покрепче 2600 или Phrack. Материал, публикуемый там, называют “научными публикациями” той же тематики. Там не учат ни С, ни ассемблеру, ни основам микроэлектронники, ни скользким моментам различных поведений программ на разных платформах, где работа типов процессоров отличается – все это надо иметь при себе.
Спектр тем включает в себя computer science, intellectual challenge, hacker culture, reverse engineering, микропроцессоры и микроэлектронику вообще (доходит до химии (да, надо сказать методы, к которым прибегают авторы для достижения описываемых целей, очень и очень креативны)), эксплойды… кстати, в отличие от многих других изданий, там не просто публикуются все новые и новые эксплойды с коротким описанием, словно в новостной ленте, но подробное описание принципов, нарушение которых и привели к ошибке и легли в основу эксплойда. Подробно описывается сам процесс анализа, да и вообще причин, из-за которых этот анализ проводили. Издание учит учиться. И мыслить шире. Порой складывается впечатление, что авторы специально выбирают нетипичные методы взлома, если процесс от этого станет интереснее. Объективности ради надо сказать, что не все темы связаны с security, но безусловно все – с красотой процесса и творческим подходом к решению задачи, оценить которые, как оно обычно и бывает в разных областях искусства, смогут далеко не все.
Leap 15.0 Beta testing: Fujitsu U757 Laptop
2 месяца назад нашел незначительный, но все же баг в ядре openSUSE Leap 15.0 (тогда еще это была Beta, build 174). Баг связан с лептопом Fujitsu U757 и воспроизводиться должен во всех дистрибутивах, т.к. проблема в upstream коде ядра.
Суть проблемы связана с поддержкой мультифункциональных клавиш, отвечающих за включение/выключение wifi.
Чтобы удостовериться, что kernel не обрабатывает нажатие клавиш, можно воспользоваться libinput. Это так называемый input device driver для X.org window system. С его помощью можно легко (в userland) отлавливать события, которые должны быть обработаны ядром. Так вот он показывал, что комбинация клавиш Fn+F5 при нажатии не давала никакого эффекта (F5 – это wifi-клавиша).
Тем не менее, при помощи rfkill wireless можно легко включить/отключить:
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
# rfkill block 0
# rfkill list
0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
Как оно обычно и бывавает, много времени уходит на то, чтобы собрать достаточно материала. Долгое время я не был уверен, что делаю все верно. С толку сбивало и то, что в других дистрибутивах проблема воспроизводилась один в один. Я отключил Bluetooth в BIOS, чтобы только одно устройство влияло на работу LED на корпусе лептопа. Таким образом, LED должен был загораться при включении wireless и наоборот – тухнуть при выключении. Этого не происходило…
Я решил опробовать другие ядра. Я ставил ядро из репозиториев Kernel:stable (на тот момент это было ядро 4.15.13) и Kernel:HEAD (4.16 rc7-1). Это не решило проблему.
Спустя какое-то время я нашел в сети описание этой проблемы и патч. Я отправил bugreport. Такаши, один из разработчиков в Kernel Team, сказал мне, что патч будет принят в upstream в 4.17-rc1. В стандартное Leap-ядро этот фикс сразу же не попал, т.к. баг не слишком критичен, НО Такаши пересобрал ядро с этим исправлением для SLE15 и Leap15. Leap пользователи могут установить его отсюда. Это исправление будет в Leap совсем скоро официально, в виде maintenance update.
После установки этого ядра libinput отлавливает events:
# libinput debug-events -event7 KEYBOARD_KEY +3.51s KEY_RFKILL (247) pressed event7 KEYBOARD_KEY +3.51s KEY_RFKILL (247) released
В качестве заключения я хочу сказать всем разработчикам: слушайте свою интуицию, не давайте никому сбить вас с толку. Полагайтесь в первую очередь на свой опыт. Не слушайте коллег, которые подгоняют логику под увиденный результат. К сожаленью, часто бывает, когда вы стоите в шаге от правильного решения, но все же решаете посоветоваться, коллеги начинают вас переубеждать. Защайтесь. Не ленитесь перепроверить все еще раз.
Удачи! Have a lot of fun =)
⌨ Labor omnia vincit ☮ 
leave a comment