HN user

yrro

2,589 karma
Posts1
Comments1,328
View on HN
Copy Fail 3 months ago

FYI RHEL's SELinux policy blocks AF_ALG socket creation for confined services out of the box. But disabling via RestrictAddressFamilies= unit option, or initcall_blacklist= kernel parameter, seems to be a good mitigation for unconfined services, users and containers.

Copy Fail 3 months ago

They've bumped the severity and 8/9/10 are now 'affected'. Hope a patch comes soon!

Copy Fail 3 months ago

Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket:

    $ sesearch -A -c alg_socket -p createallow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write };
    allow container_device_plugin_init_t container_device_plugin_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_plugin_t container_device_plugin_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_device_t container_device_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_engine_t container_engine_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_init_t container_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_kvm_t container_kvm_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logreader_t container_logreader_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_logwriter_t container_logwriter_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_t container_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow container_userns_t container_userns_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
    allow openshift_app_t openshift_app_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow openshift_t openshift_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow spc_t unlabeled_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
    allow staff_t staff_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
    allow sysadm_t sysadm_t:alg_socket { accept append bind connect create getopt ioctl listen lock read setattr setopt shutdown write };
    allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
    allow user_t user_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
... that's a lot of domains, including container_t and user_t; and obviously anything unconfined_t can't be expected to be restricted.

(Maybe you & others are specifically thinking of Android's policy?)

Take it from someone who saw it when it first aired on standard definition analogue TV: it doesn't really matter all that much. The performance of the actors and the story is what's important!

A _real_ web site!

When I first returned to it rewatching B5 a couple of years ago, I actaully found it difficult to navigate. It took me a while to realise that my brain was parsing the block of navigation buttons at the centre top of the screen as a banner ad and filtering it out!

That won't overwrite pages not allocated to a namespace (which can happen due to wear levelling/underprovisioning, or because the controller has decided to stop using that page because it's unhealthy).

Flash looks like a simple array of blocks, but under the hood there is a controller that allocates writes to different pages. You need to tell the controller to erase all pages if you want to guarantee data destruction.

What's the difference between this and sanitize? Should we be doing both?

[edit] sanitize runs on the controller level while format works on the namespace level. So I suppose formatting won't touch any pages not allocated to a namespace.

I wish there was _any_ way to find out which NVME controllers supported which operation before you buy them!

I suppose arguably the kernel, or at least some component of the OS, should be freezing/locking drives as they come online. The firmware doing so as one-off operation during boot is a workaround for the lack of this being done by the OS.

I've lost faith that Linux distros will ever fix the problem where some PCR changes and the TPM refuses to unseal the key... the user is left with a recovery passphrase prompt & no way to verify whether they have been attacked by the 'evil maid', or whether it was just because of a kernel or kernel command line or initrd or initrd module change, etc.

So I connected it to the computer with the USB to NVME M.2 converter

blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported

I've got a USB-to-NVME adapter that exposes the NVME namespaces as SCSI disks. `blkdiscard` did not work with these by default, however it worked fine after I changed the `provisioning_mode` attribute of the disk.

This can be done by identifying the SCSI device ID of the disk (lsscsi) and then changing it with:

    # echo unmap > /sys/class/scsi_disk/a:b:c:d/provisioning_mode
`lsblk -D` will show which block devices support the discard operation; run it before and after changing provisioning_mode to see the difference.

This is absolutely not to be used as an alternative to a real 'sanitize' operation directly sent to the NVME controller. If you actually need to securely erase your data, and the drive dosesn't support the sanitize operation, then you should physically shred the drive and demand a refund from the retailed (goods as sold are not fit for purpose).

Overall, I've found dealing with nvme a frustrating experience. In theory it's nice to have NVME controller firmware be responsible for executing commands from the host (sanitize! change LBA size! underprovision by 30%!) but in practice, it's complete hit or miss whether controllers support a command or will reject it, or maybe they claim to support it but it doesn't work because the controller firmware is buggy shit.

I would like to have raw NAND devices and have the kernel be in charge of everything, but sadly that wouldn't work for Windows so we're stuck in proprietary firmware hell.

It seems like no government wants to kick the hornet's nest & solve this issue, nor the issue of pavement parking. At least this government is finally working on the problem of doctored number plates that are invisible to enforcement cameras. Land a few drivers with a 15 year sentence for perverting the cause of justice & things should right themselves.

Of course it impedes observability. With IPv6, I can see the IP addresses of the containers that connect to a service. With IPv4, I get (at best) the IP address of the container host, thanks to NAT.

Are you also afraid of port forwarding? Have you considered that your ISP could choose to send your router packets destined for RFC1918 addresses?