From af608a5447a8f6e9cf74e5623eec4d534a2b5ec8 Mon Sep 17 00:00:00 2001 From: rivassec Date: Sun, 25 Oct 2026 18:12:11 -0700 Subject: [PATCH] content: revise internal link structure - bluetooth-tethering: link its sequel (Bandit hardening) instead of the IAM library - tls-three-jobs: drop the IAM detour; frees a slot for the eMudhra post's companion patch - testing-an-iam-analyzer: link secure-iam-lint v1.2.0 (had no inbound post links) - hub: list the four posts reachable only through other posts (Bluetooth tethering, Kubernetes hardening, leap second, Teensy); move ES snapshot verification to Identity and Access --- ...uetooth-tethering-multi-phone-fallback-for-pwnagotchi.md | 2 +- content/devsecops-guide.md | 6 +++++- content/testing-an-iam-analyzer-against-its-own-claims.md | 2 +- content/tls-three-jobs.md | 2 +- 4 files changed, 8 insertions(+), 4 deletions(-) diff --git a/content/bluetooth-tethering-multi-phone-fallback-for-pwnagotchi.md b/content/bluetooth-tethering-multi-phone-fallback-for-pwnagotchi.md index 24757a0a..36bd0eb0 100644 --- a/content/bluetooth-tethering-multi-phone-fallback-for-pwnagotchi.md +++ b/content/bluetooth-tethering-multi-phone-fallback-for-pwnagotchi.md @@ -72,7 +72,7 @@ The scan reported "Low Severity" warnings primarily related to the use of the `s * **Strict Input Validation:** All dynamic inputs (like `MAC addresses`, `phone names`, and `IP addresses`) coming from your `config.toml` are subjected to strict regular expression and `ipaddress` module validation *before* being passed to `subprocess` commands. This ensures that only well-formed and safe values are used. * **Controlled Environment:** Pwnagotchi runs in a specific, often isolated, environment. While caution is always advised, the risk surface is contained compared to a general-purpose server. -The "Low Severity" warnings are primarily general advisories about the *potential* for misuse of `subprocess`, rather than indicative of a direct, exploitable vulnerability in this specific implementation, given the defensive measures taken. The same "refuse the dangerous default unless the caller is explicit" pattern shows up at the cloud-IAM layer in [IAM Roles That Fail Loud]({filename}iam-safe-defaults-fail-loud.md): different domain, same instinct. +The "Low Severity" warnings are primarily general advisories about the *potential* for misuse of `subprocess`, rather than indicative of a direct, exploitable vulnerability in this specific implementation, given the defensive measures taken. I later took the plugin through a full hardening pass until it scanned clean, in [Bandit-Clean Pwnagotchi Plugins]({filename}pwnagotchi-plugin-bandit-hardening.md). ## Final Thoughts diff --git a/content/devsecops-guide.md b/content/devsecops-guide.md index 2537ec2b..cb51c71a 100644 --- a/content/devsecops-guide.md +++ b/content/devsecops-guide.md @@ -24,11 +24,11 @@ fires against your own tooling, or the 208th day of uptime. - [IAM Roles That Fail Loud: Small Defaults, Big Difference](iam-safe-defaults-fail-loud.html) - Interactive: [IAM Blast Radius analyzer](/tools/iam-blast-radius/) - paste an IAM policy, see its potential blast radius in your browser - [Testing an IAM Analyzer Against Its Own Claims](testing-an-iam-analyzer-against-its-own-claims.html) +- [Elasticsearch Snapshot Verification, Minimal Privileges](elasticsearch-secure-snapshot-verification.html) ## Cryptography and Transport - [TLS Has Three Jobs. Forget the Rest.](tls-three-jobs.html) -- [Elasticsearch Snapshot Verification, Minimal Privileges](elasticsearch-secure-snapshot-verification.html) ## Operating Under Pressure @@ -37,6 +37,10 @@ fires against your own tooling, or the 208th day of uptime. - [The 208.5-Day Kernel Bug: Uptime, Overflow, and Risk](208-day-kernel-bug-lessons.html) - [Taming the OOM Killer: Process Priorities on Linux](oom-killer-process-prioritization.html) - [Bandit-Clean Pwnagotchi Plugins: How subprocess Goes From Risk to Routine](pwnagotchi-plugin-bandit-hardening.html) +- [Never Lose Connection: Multi-Phone Bluetooth Tethering for Pwnagotchi](pwnagotchi-bluetooth-tethering.html) +- [Hardening Kubernetes Deployments](hardening-k8s.html) +- [The 2012 Leap Second: When Time Broke Java and the Cloud](leap-second-chaos-2012.html) +- [The Teensy That Failed in Public: An EFI Brute Force, Hours Late](teensy-efi-bruteforce-hours-late.html) ## Program and Adoption diff --git a/content/testing-an-iam-analyzer-against-its-own-claims.md b/content/testing-an-iam-analyzer-against-its-own-claims.md index 32489ce7..6b28c52a 100644 --- a/content/testing-an-iam-analyzer-against-its-own-claims.md +++ b/content/testing-an-iam-analyzer-against-its-own-claims.md @@ -77,4 +77,4 @@ Unknown, unavailable, malformed, timed-out, and failed are explicit states. An e That one rule runs through the whole tool. It returns a machine-readable "unsupported" code on policy families it does not fully model instead of guessing as though the input were an identity policy, because unsupported is not the same as safe. It refuses to expand a `Deny` with `NotPrincipal` into an ordinary "deny everyone except X" exclusion: NotPrincipal in a Deny is matched by exact ARN, so a naive reading can deny far more or far fewer principals than intended, and principals with permissions boundaries add a further wrinkle. It treats an SCP or RCP as a ceiling, never a grant. And the review workflow refuses to accept a change a critic never actually reviewed. -A security tool earns trust through how it behaves when it cannot be sure. The green build is table stakes. What the tool does when the honest answer is "I do not know" is the part worth reading. That rule is also the design brief for the CI gate built on this analyzer: [a pipeline check that blocks on "I do not know"]({filename}iam-blast-radius-github-action.md) instead of waving it through. +A security tool earns trust through how it behaves when it cannot be sure. The green build is table stakes. What the tool does when the honest answer is "I do not know" is the part worth reading. That rule is also the design brief for the CI gate built on this analyzer: [a pipeline check that blocks on "I do not know"]({filename}iam-blast-radius-github-action.md) instead of waving it through. The bypasses this harness keeps finding became regression tests in [secure-iam-lint v1.2.0]({filename}secure-iam-lint-v1-2-0.md). diff --git a/content/tls-three-jobs.md b/content/tls-three-jobs.md index 9abd8f0f..c007ea27 100644 --- a/content/tls-three-jobs.md +++ b/content/tls-three-jobs.md @@ -86,7 +86,7 @@ If the answer is "expired", you are done. If the answer is "no issuer found", an Mutual TLS just adds a second authentication step: the server requires the client to present a certificate, and the server validates that certificate against an internal CA. Same primitives, same chain logic, same revocation question, just now the client is also proving who it is. -It matters because in a serverless or microservices fabric, mTLS is the cleanest replacement for "shared secrets in environment variables." Service identity becomes a certificate issued by an internal CA, rotated automatically by something like cert-manager or AWS Private CA. The handshake is doing the same three jobs; you just stopped trusting the network and started trusting the certificate. The "refuse the dangerous default unless the caller asks for it explicitly" pattern that makes that workable on the IAM side is the subject of [IAM Roles That Fail Loud]({filename}iam-safe-defaults-fail-loud.md). +It matters because in a serverless or microservices fabric, mTLS is the cleanest replacement for "shared secrets in environment variables." Service identity becomes a certificate issued by an internal CA, rotated automatically by something like cert-manager or AWS Private CA. The handshake is doing the same three jobs; you just stopped trusting the network and started trusting the certificate. ## Where the operational work actually lives