I've been receiving loads of spam from google MX servers lately until blocking all mails with X-Google-Group-Id headers. I don't know how it's possible, the contents were 100% spammer controlled, no Google template
That also often shoots you as when json_encoding it only becomes an array when ordered "correctly" (numeric 0-based keys without gaps), otherwise an object. So to be safe you generally need to array_values after filtering.
If in your testdata you only remove elements from the end you don't catch that before production data hits.
It's especially problematic when encoding an empty object to json. By default an empty array is serialized as [], to get {} you either need to pass a flag to force object serialization (which can mess up serializing actual arrays), or cast the array as an object. Neither of which are great when the object is deeply nested in the serialized object.
Ubuntu also released TPM based FDE a few versions ago. I had these thoughts then and decided against using it. Typing my passphrase on boot is muscle memory and gives me simple security I can trust.
Also can recover data without my mainboard.
Maybe a hybrid (secureboot-TPM+phrase) slot for day to day to also prevent against evil maid attacks, and another slot with a backup passphrase would be acceptable.
>Typing my passphrase on boot is muscle memory and gives me simple security I can trust.
It's not an either-or. You can combine TPM with passwords which makes it far more secure than password alone. A TPM can enforce password guessing limits, otherwise a password needs to be absurdly long to be secure against GPU bruteforcing attacks. It also prevents someone from swapping out the bootloader with a backdoored version that steals your passwords.
>Also can recover data without my mainboard.
You're supposed to keep a backup of the encryption key when using TPM, in case it fails.
Sounds good - which software supports this? Specifically I'd prefer if it would do a composite key derivation in-time rather than "just a pw prompt but TPM has the full key"
No remotely reachable vuln should be taken lightly.
At the moment though, the preconditions look odd. I've been using nginx in various constellations for 10 years and never once combined rewrite and set.
There can be situations where you set some variables on top level and then override those in the location block with rewrite. These variables could be then used e.g. in log lines or in other "global" contexts.
It says coordinated distro release today, and I've received a notice earlier today but that does not include the CVE number. That's confusing / does not seem very coordinated to release 2 separate security update notices in a day.
That mentions 4.98.2-1+deb13u2, and its changelog has:
exim4 (4.98.2-1+deb13u2) trixie-security; urgency=high
* Backport fix for Use-After-Free in GnuTLS BDAT/CHUNKING code path.
This is Exim-Security-2026-05-01.1, fixed upstream in 4.99.3.
-- Andreas Metzler <ametzler@debian.org> Mon, 11 May 2026 19:14:46 +0200
Next easy attack vector is (non-rootless) docker run with rootfs mount, many are in docker group even when sudo is protected.
Also, most sensitive data is in the user scope anyways (on a PC).
You should always run dev stuff in containers to start with.
And when your system is compromised, reprovision from a higher scope, too many places to hide backdoors
VPN usage increased, but how to they draw the conclusion that this is children. I think it's more likely that adults are using VPNs to not have to deal with the ID process. I would do that.
As VPNs usually cost some money, which is already a barrier for minors.
It is a minimal improvement due to the introduction of user namespaces and the fallout from local team convenience for Docker and thus OCI.
It is very important that you realize that any capability is a slice of superuser privileges, and there are no implicit protections, only explicit additional constraints that restrict it in reference to root.
Look at the bounding set for a normal user on a fresh install of rhel/debian based systems:
The capabilities(7)[0] man page will help you with all of those.
But capabilities are just a thread local segmentation, which grants superuser or root rights in a vertical segmented fashion.
True, if a mechanism chooses to do additional tests based on credentials(7)[1], you can run with those elevated privileges in a lower bound, but that requires implicit coding.
Add in that LSMs are suffering from both resources and upstream teams that won't provide guidance or are challenging to work with, and there are literally a hundred commands to either abuse or just ld_preload to get unrestricted userns, allowing you to get around basic controls on clone()/unshare() that may be implemented.
$ grep -ir "userns," /etc/apparmor.d/ | wc -l
100
With apparmor every single browser (firefox,chrome,msedge,etc...) as well as busybox, slack, steam, visual studio, ... all have the unrestricted user namespaces and the ability to gain the FULL set of capabilities in the bounding set.
If you run `busybox` on a debian system, note how it has nsenter and unshare, so you can't mask those and yet busybox itself is unconstrained with elevated privlages.
The TL;DR point being, don't assume that any capability() is in itself a gate, as there are so many ways even for the user nobody to gain them.
1. The privilege check in question here is capable(CAP_NET_ADMIN), so it doesn't work in user namespaces.
2. Most sandboxes (including Docker and Podman) disable creating unprivileged user namespaces inside them via seccomp. In this mode, you end up with a more secure setup than requiring a privileged process to spawn containers (for one, it massively reduces the risk of confused deputy attacks against container runtimes). You can also restrict it with ucounts (as rough of a system as that is).
3. The kernel provides this facility and the feature was added back in early 2013 (before Docker existed and long before they added user namespace support, let alone rooless containers), so I don't understand why you think this is somehow the fault of OCI? We're just making something useful out of existing kernel infrastructure. Folks have asked the kernel to provide a knob to disable unprivileged user namespaces but the maintainer has refused to do so for years (the best you get is ucounts and seccomp). I would also prefer to have such a knob (or even adding a separate ucount with configurable per-user limits) but it's not up to me.
(Disclaimer: I implemented rootless containers for runc back in the day and work on OCI, so I do have some bias here.)
1) the various projects refused even simple requests like allowing the admin to disable the —privileged flag, in the rootfull days.
2) The choice to break out CRI will zero authorization or mutations at the CRI level, while understandable to the containerd teams needs, exposed every other runtime to an unprotected alternative communication path.
3) The OCI groups refusal to provide guidance to LSM maintainers as to minimal configurations, while also handling the responsibilities of seccomp profiles to end users means only actively attacked vectors are protected and it becomes impossible for normal users to operate safely.
4) under the UNIX model it is the caller to clone/fork/unshare that must drop privileges.
5) This model was set in concrete by the OCI standards and now suffers from the frozen caveman pattern.
The capable()[0] syscall operates as one would expect for granting superior capabilities, and while the work to expand the isolation is something I am sure you are familiar with, you probably also realize that the number of entries in a default user also expanded just to support user namespaces.
But to be clear, the choices that docker/oci made are understandable from a local greedy choice perspective, it complicates the entire user space.
K8s mutating inlet controllers are a symptom of those choices.
Had a CRI contained a bounding set, enforced at a system level, especially with guidance and tools for users to use a minimal set, which they could expand on easily we would be in a better spot.
But as other projects cannot provide meaningful protections that cannot be simply bypassed by calling privileged CRIs it is also a barrier to convincing them to do the same.
Really there is a larger problem that OCI could be the leader on, but they are the ‘killer app’ and refuse to do so.
The bounding set for user capabilities is driven by containers, and while namespaces are not and never have been a security feature, this blocks their ability to have a strong security posture.
To be clear, expecting every end user to write minimal seccomp profiles is unrealistic, especially when docker prevents devs from accessing the local machine to discover what is happening. I think podman is the only machine that allows that by default.
Basically while simplifying moby/containerd/CRI is an understandable choice, the refusal to address the costs of that local optim has fallout
