SoylentNews is people
SoylentNews
"Today, June 29th 2017, WikiLeaks publishes documents from the OutlawCountry project of the CIA that targets computers running the Linux operating system. OutlawCountry allows for the redirection of all outbound network traffic on the target computer to CIA controlled machines for ex- and infiltration purposes. The malware consists of a kernel module that creates a hidden netfilter table on a Linux target; with knowledge of the table name, an operator can create rules that take precedence over existing netfilter/iptables rules and are concealed from an user or even system administrator.
The installation and persistence method of the malware is not described in detail in the document; an operator will have to rely on the available CIA exploits and backdoors to inject the kernel module into a target operating system. OutlawCountry v1.0 contains one kernel module for 64-bit CentOS/RHEL 6.x; this module will only work with default kernels. Also, OutlawCountry v1.0 only supports adding covert DNAT rules to the PREROUTING chain."
https://www.wikileaks.org/vault7/#OutlawCountry
-- Leaked Documents :
= OutlawCountry v1.0 User Manual
https://www.wikileaks.org/vault7/document/OutlawCountry_v1_0_User_Manual/
(PDF) https://www.wikileaks.org/vault7/document/OutlawCountry_v1_0_User_Manual/OutlawCountry_v1_0_User_Manual.pdf
= OutlawCountry v1.0 Test Plan
https://www.wikileaks.org/vault7/document/OutlawCountry_v1_0_Test_Plan/
(PDF) https://www.wikileaks.org/vault7/document/OutlawCountry_v1_0_Test_Plan/OutlawCountry_v1_0_Test_Plan.pdf
(Score: 2) by NewNic on Friday June 30 2017, @09:32PM (3 children)
But RHEL does not guarantee binary compatibility of kernel modules. In fact, you are pretty much guaranteed that kernel modules will not be compatible between updates. That's what tools like DKMS are for.
lib·er·tar·i·an·ism ˌlibərˈterēənizəm/ noun: Magical thinking that useful idiots mistake for serious political theory
(Score: 2) by jmorris on Saturday July 01 2017, @06:12AM (2 children)
You must not have any experience with RHEL / CentOS. They do not rev the kernel version, period. When RHEL N.0 ships the N.[1-9] periodic releases all report the same major and minor kernel version numbers, only the numbers way over in the package name tick upward. They backport in new hardware support and bug fixes but no new functionality and none of the changes that would break a typical binary kernel driver for a device.
This is a version string from a currently patched up CentOS 6:
2.6.32-696.3.2.el6.centos.plus.x86_64
And note that is a centos plus kernel on that machine, the RHEL / stock CentOS kernel gets fewer device drivers. But don't think that just because it says it is a 2.6 kernel that it won't boot on modern post 2009 hardware, like I said, RedHat expends quite a bit of effort backporting device drivers. But the basic internal structure, the sort of changes that would break binary kernel modules between a 2.6 kernel and 4.x aren't there, it is still essentially a 2.6 kernel. They do this to ensure stability, if you initially install on a machine you can be damned certain a random kernel update won't suddenly break something. Unlike Fedora that recently broke hibernation on my machine for several kernel versions and now it works again. They also very explicitly and publicly do it to facilitate binary modules for RHEL servers and workstations. Again, the Fedora peeps with NVidia cards learn quick to stay up on when it is safe to update since they are again very explicit and public about not giving even 0.1 f*cks about breaking ANY closed software during the madcap ride to the Glorious SystemD Future that Fedora is on. Complaining about unimportant problems like having a blank screen on reboot on the fedora mailing lists will only get you abuse and ridicule, including from @redhat.com addresses.
Pro Tip: Buy a Radeon if you want to run Fedora and NVidia for RHEL / CentOS. (But the free Radeon drivers are getting good and are also supported so very soon we should all be able to just buy Radeon and tell NVidia to f*ck themselves with a pineapple.)
(Score: 2) by NewNic on Saturday July 01 2017, @06:58PM (1 child)
Interesting, your post made me look into kernel module compatibility a bit more.
A naive attempt appears to shows that the version must match exactly:
# insmod /lib/modules/2.6.32-696.1.1.el6.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko
insmod: error inserting '/lib/modules/2.6.32-696.1.1.el6.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko': -1 Required key not available
However, it appears that this error message is related to module signing:
# grep MODULE_SIG /boot/config-2.6.32-642.13.1.el6.x86_64
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
lib·er·tar·i·an·ism ˌlibərˈterēənizəm/ noun: Magical thinking that useful idiots mistake for serious political theory
(Score: 2) by jmorris on Monday July 03 2017, @03:00AM
Yea, it is annoying. But it can be worked around. Check this CentOS wiki page [centos.org] discussing the issue of making third party repo modules. ElRepo is the example given and it is noted their modules aren't signed. (The packages are though, which is easier since adding the repo can add a new key to rpm.)