Mitigating CVE-2021-4034 (policykit pkexec) vulnerability on CentOS 6

 Kernel and drivers, Legacy, Linux  Comments Off on Mitigating CVE-2021-4034 (policykit pkexec) vulnerability on CentOS 6
Jan 272022
 

CentOS 6 has been end of life since 30.11.2020 – do not use it.

Well, you’re still reading this, so you are using it.

Really really quick mitigation: remove SUID-bit from pkexec: chmod ug-s /usr/bin/pkexec

RedHat provides updates and mitigation steps for RHEL6 (extended support), RHEL7 and RHEL8 on their customer portal – https://access.redhat.com/security/cve/CVE-2021-4034

Based on their excellent documentation it is easy to build a mitigation for CentOS 6 also.

  • Make sure you can still install packages (f.ex use CentOS Vault)
  • Install systemtap & kernel-devel -packages
  • Create pkexec_block.stp with the following content
    probe process("/usr/bin/pkexec").function("main") {
        if (cmdline arg(1) == "")
                        raise(9);
}
  • Compile and install module: 
stap -g -F -m stap_pkexec_block pkexec_block.stp
  • Verify with lsmod that stap_pkexec_block -kernel module is loaded.
  • Make sure that module is loaded also after a reboot (copy to right place, run depmod -a & verify).

IPv6 RTNETLINK answers: Cannot allocate memory

 Linux, Network  1 Response »
Jun 222015
 

If you get hit with “RTNETLINK answers: Cannot allocate memory” when trying to add IPv6 default gateway back after losing all IPv6 -connectivity, raise net.ipv6.route.max_size.

The defaults (on my machines) were quite small compared to IPv4:

CentOS 7.0:
# sysctl net.ipv4.route.max_size
net.ipv4.route.max_size = 2147483647
# sysctl net.ipv6.route.max_size
net.ipv6.route.max_size = 4096

CentOS 7.1:
# sysctl net.ipv4.route.max_size
net.ipv4.route.max_size = 2147483647
# sysctl net.ipv6.route.max_size
net.ipv6.route.max_size = 16384

Debian 7.8/8.1:
# sysctl net.ipv4.route.max_size
net.ipv4.route.max_size = 2147483647
# sysctl net.ipv6.route.max_size
net.ipv6.route.max_size = 4096

RHEL 7.1 drops Q35 support from KVM

 Linux, Virtualization  No Responses »
Apr 012015
 

Beware, so you (too) won’t be bitten by this.

If you’re running vanilla KVM with default qemu-kvm -packages in RHEL (CentOS and probably others):

https://git.centos.org/blob/rpms!qemu-kvm!/958e1b8dccf9809600478f316ab641d490881fe7/SOURCES!kvm-rhel-Drop-machine-type-pc-q35-rhel7.0.0.patch;jsessionid=mc5igseasal0axkra6qhd4it

In short, q35 -support was a technical preview which is now dropped from qemu-kvm (qemu-kvm-rhev -only feature from now on), back to “pc”…

KVM virsh console

 Software, Virtualization  No Responses »
Nov 202014
 

As a reminder, how to enable serial console under KVM.

Hypervisor (CentOS 7):
– no changes required if required pty -devices are created automatically (-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 in guest command line)
–  if not found, you need the following bit in the devices section of virtual guests XML-file (modifying usually requires a full shutdown-start sequence for the virtual):

<serial type='pty'>
  <target port='0'/>
</serial>
<console type='pty'>
  <target type='serial' port='0'/>
</console>

Guest (Debian 7):
– modify /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"
#GRUB_TERMINAL=console

->

GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0 quiet"
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial"

Uncomment the following line from /etc/inittab:

T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

Run update-grub and reboot virtual machine – now you should be able to use virsh console at the hypervisor.

<edit-16.1.2015>
– Added XML-configuration for serial/console
– Dropped 9600bps speed configuration
</edit>

CentOS 7 & firewallD

 Linux, Network  No Responses »
Oct 142014
 

Usually one of the first things we want to do with a new server is to restrict access to SSH -service.

So far it seems that everyone advices “disable firewallD, install iptables service and use it like you’ve always used” but how about trying to get along with this new tech?

Restricting access to SSH isn’t as hard as it might seem at the first glance. First we check what services are allowed in public (usually the default) and internal -zones:

# firewall-cmd --zone=internal --list-services
dhcpv6-client ipp-client mdns samba-client ssh
# firewall-cmd --zone=public --list-services
dhcpv6-client ssh

Then we add our admin-IP to internal -zone:

# firewall-cmd --permanent --zone=internal --add-source=<admin-ip>

Remove access to SSH-service from public:

# firewall-cmd --permanent --zone=public --remove-service=ssh

And reload the changes into use:

# firewall-cmd --reload

–permanent makes changes which stay over reboot/reload, but they aren’t active immediately – without –permanent the changes are active immediately but are lost on reload/reboot

Service definitions can be found (in RHEL/CentOS 7) at /etc/firewalld/services/ – if you create a new one -> use –reload to make it active.

Using LVM with SSD cache

 Kernel and drivers, Linux  No Responses »
Oct 092014
 

Nowadays LVM has  a cache feature, where we can bolt an SSD as a cache-device to a logical volume.

Let’s imagine we have the following setup:

  •  4x 2TB SATA disks in RAID10 configuration, /dev/md0
  • 2x 120GB SSD disks in RAID1 configuration, /dev/md1

First we’ll create the logical volume which we’ll be working with:

# pvcreate /dev/md0
# vgcreate storage /dev/md0
# lvcreate -n volume -L 4TB storage /dev/md0

Next we’ll bolt the cache-device (which should be RAID1-mirrored in case of disk failure) to the volume, first we’ll extend the volume group to contain the SSD-device:

# vgextend storage /dev/md1

Then we’ll create a cache volume and a metadata volume (there’s 1GB free on purpose):

# lvcreate -n metadata -L 1GB storage /dev/md1
# lvcreate -n cache -L 118GB storage /dev/md1

Now we’ll convert these into a cache pool (this will fail if there isn’t at least the same amount free what’s used for metadata, 1GB, because it’s used for failure recovery):

# lvconvert --type cache-pool --poolmetadata storage/metadata storage/cache

Then all what’s left is attaching the cache to a logical volume:

# lvconvert --type cache --cachepool storage/cache storage/volume

It should say “storage/volume is now cached” and lvs output should look something like this:

# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
cache storage Cwi---C--- 118.00g
volume storage Cwi-a-C--- 4.0t cache [storage_corig]

Oh, and if you want the cache to survive a reboot, youll need a package which provides /usr/sbin/cache_check -binary. In Debian that’s “thin-provisioning-tools”, and in RHEL/CentOS/derivatives the package is device-mapper-persistent-data.
Tests were performed on Debian testing Jessie and CentOS 7.0.1406 Core in 10/2014. Official documentation can be found here.