Tell the kinds of change apart, instead of counting them together #22

2026-08-29T15:14:01-07:00

dejima-agent commented

2026-08-29 15:14:01 -07:00

Summary generated by LLM agent

The other half of a detection pass; the collection side is dejima-devbox-hardener v6. No new command, no new permission, no new data path. This is entirely about reading what already arrives.

Every finding was one alert at one priority

A checksum that moved because logrotate ran, a port that was not open yesterday, and the audit binary itself being replaced all arrived as "unexplained changes" at high.

A change under a watched path is its own alert now, at max. The audit's own binary is the sharp one: if /usr/local/sbin/dejima-devbox-audit changed, everything this guard has been told since is suspect, including the report saying so. It used to arrive as "1 file(s) changed". The forced command, the sudoers rule and authorized_keys are the same argument one layer out, since they are what makes this access read-only, so a change to them changes what a stolen key is worth. critical_paths is configurable and defaults to those five.

A newly present PORT or UNIT is max too. Both are the shape of something arranging to run again or to be reached, which is not a config edit. A port that went away is not: removal is drift worth reporting and is not this shape, and there is a test for that distinction so the escalation does not become everything.

Still one alert per cycle, ordered by what the operator has to do about it, and still no path in an alert body. The devbox chose those strings; a count and a category are enough to say go and read the report.

LINK lines are counted, since the devbox collects symlinks now. Hashing cannot see one, so without this a substitution would be summarised as nothing at all.

Tested: 111 passing, up from 102. Seven of the nine new tests were run against the previous version and fail on it.

**Summary generated by LLM agent** The other half of a detection pass; the collection side is dejima-devbox-hardener v6. No new command, no new permission, no new data path. This is entirely about reading what already arrives. ## Every finding was one alert at one priority A checksum that moved because logrotate ran, a port that was not open yesterday, and the audit binary itself being replaced all arrived as "unexplained changes" at `high`. **A change under a watched path is its own alert now, at max.** The audit's own binary is the sharp one: if `/usr/local/sbin/dejima-devbox-audit` changed, everything this guard has been told since is suspect, including the report saying so. It used to arrive as "1 file(s) changed". The forced command, the sudoers rule and `authorized_keys` are the same argument one layer out, since they are what makes this access read-only, so a change to them changes what a stolen key is worth. `critical_paths` is configurable and defaults to those five. **A newly present `PORT` or `UNIT` is max too.** Both are the shape of something arranging to run again or to be reached, which is not a config edit. A port that went *away* is not: removal is drift worth reporting and is not this shape, and there is a test for that distinction so the escalation does not become everything. Still one alert per cycle, ordered by what the operator has to do about it, and still no path in an alert body. The devbox chose those strings; a count and a category are enough to say go and read the report. `LINK` lines are counted, since the devbox collects symlinks now. Hashing cannot see one, so without this a substitution would be summarised as nothing at all. Tested: 111 passing, up from 102. Seven of the nine new tests were run against the previous version and fail on it.

dejima-agent added 1 commit 2026-08-29 15:14:02 -07:00

Tell the kinds of change apart, instead of counting them together e41cc06ecc

Every finding arrived as one "unexplained changes" at high: a checksum that
moved because logrotate ran, a port that was not open yesterday, and the audit
binary itself being replaced were the same push.

A change under a watched path is its own alert now, at max. The audit's own
binary is the sharp one - if it changed, everything this guard has been told
since is suspect, including the report saying so, and it used to be
indistinguishable from a config edit among a hundred others. The forced command,
the sudoers rule and authorized_keys are the same argument one layer out: they
are what makes this access read-only, so a change to them changes what a stolen
key is worth. Configurable, with a default naming the machinery this design
rests on.

A newly present PORT or UNIT is max as well. Both are the shape of a thing
arranging to run again or to be reached, which is not a config edit. A port that
went away is not: removal is drift worth reporting and is not this shape.

Still one alert per cycle, ordered by what the operator has to do about it. And
still no path in an alert body: the devbox chose those strings, and a count plus
a category is enough to say go and read the report.

LINK lines are counted, since the devbox now collects symlinks - hashing cannot
see one, so a substitution would otherwise be reported as nothing at all.

branderson approved these changes 2026-08-29 15:29:49 -07:00

branderson merged commit aec0100ce6 into main

2026-08-29 15:29:53 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-guard#22