Notices by Graham Sutherland / Polynomial (gsuberland@chaos.social)

@vncresolver the quiet u r the more u can here

it took just 15 days for one of my silly 2025 infosec predictions to come true:

http://soatok.blog/2025/01/14/dont-use-session-signal-fork/

@mcc i was recently pondering this too and didn't find a good solution (or really any solution that didn't read like shallow value-add marketing from security vendors)

@mcc "use a VPN" solves no actual threat model here, it's just an incantation made up by VPN company marketing

"use a second device" is cumbersome, costly, and in most cases probably doesn't fit with the reason you wanted to install the app in the first place

"use grapheneOS" and similar are pretty high effort and mostly recommended by people who have never actually done this, or the kinds of people who run an ancient ThinkPad with CoreBoot to ward away Intel CSME

@mcc annoyingly stock android still doesn't let you say no to most of the permissions that apps demand on install, barring a few exceptions, and because they're not designed to assume that a permission can be denied the apps will usually just crash if you do somehow manually tweak stuff to turn the permissions off.

@GossiTheDog lmao, that's an embarrassingly poor photoshop job

@GossiTheDog I think I could genuinely do a better job in mspaint

anandtech implies the existence of nandnandtech, notnotech, nornortech, orortech, and xorxortech

anyone got recommendations for books that go into technical detail about the physical security design elements and defeat processes relating to modern strongrooms (bank vaults) and other high security safes?

I recently read Safecracker by Dave McOmie, which covered the general features at a high level, but I'd like something a bit more detailed and technically focused. I have High Security Mechanical Locks by Pulford too, but that's focused on locks specifically rather than strongroom phys-sec.

@dalias *shrug* I guess it's to catch mistakes by plugin devs?

I do have a Grafana alert set up for "the CPU has been slammed solid for more than an hour", but it turns out the logic for it was broken so the alert never got sent.

going through my metrics, I can see that my average power consumption on the server rack was elevated by roughly 2kWh/day for the past two days, so this bug probably cost me about £1 in electricity.

from what I can tell, the middleware bug is something to do with the contents of /dev changing during the execution of a cleanup script that runs periodically, which would explain why it's a rare edge-case.

looking through the logs it might've been a HBA hiccup because it did complain about something on /dev/da1, but it's hard to line up the timing because I don't exactly know when the script started.

I just found the actual answer to this. /etc/periodic/security/ has two periodic scripts that by default run daily: 100.chksetuid and 110.neggrpperm

by default (/etc/defaults/periodic.conf) these are enabled and configured to run daily. these scripts scan your system for files that have insecure setuid and negative group permissions, using `find`.

the problem is that this gets run *per jail* and if the jails mount large datasets it eats a ton of CPU time for several hours at a time.

the biggest problem is if one of these operations ever takes over 24h you'll end up with multiple scans overlapping and sharing CPU/IO load, slowing them down, spiralling into resource exhaustion.

these can be turned off system-wide by setting the security_status_chksetuid_enable and security_status_neggrpperm_enable rc.conf vars to NO in the Tunables tab, or you can manually add those overrides to /etc/periodic.conf on a per-jail basis if you just want to turn this off for specific jails.

had some mild panic last night when I thought my NAS had been popped by a cryptominer. it was acting strange, so I SSH'd in and found a bunch of Python processes slamming the CPU, all running as root, no jail associated. they were running code passed on the command line rather than a file, and the imports were threading related. killing them led them to come back.

in the end it turned out to be a middleware bug in TrueNAS. the code was getting stuck in a loop doing nothing.

"I haven't heard of one of these" is a really good option to put in polls when you're trying to judge people's informed preferences, since it helps to decouple popularity (swayed by marketing and notoriety) from preference (individual choice)

@ryanc @soatok after this you need to run a series of 32 polls where everyone decides each individual bit in an IEEE754 single precision float

oh I reverse engineered the file format for Ansys LightTools *.ray files earlier, used for providing info on directional emissions for LEDs (most big vendors publish these files now).

they format is pretty trivial, and this post is to remind me to write it up properly tomorrow when I wake up, but the TL;DR is there's a header with a 4-byte magic number followed by some uint32 values, then a series of rays described by 7 floats (pos x,y,z then ray vector x,y,z then flux magnitude)

@soatok I know what number it's going to be but I'm still voting the other way to try to get my actual favourite number.

@f4grx @soatok I'd publish a proof hash but y'all would just crack it 'cos the data space is too small lol