On 2016/04/12 02:30, Ingo Schwarze wrote:
> Hi Stuart,
>
> Stuart Henderson wrote on Sun, Apr 10, 2016 at 09:27:06PM +0100:
>
> > Between that, a few files where I have slightly wider read
> > permissions for operational reasons,
>
> Which are those?
>
> Would it maybe make sense to weaken these checks for everybody?
> If those permissions make sense for you, maybe they are not
> insanely dangerous in general?
I often have 640 root:wheel for things like ospf{,6}d.conf, bgpd.conf,
pf.conf, crontab so I can review configuration as a wheel user without
having to authenticate again.
> > and the check on the DNSSEC root key in /var/unbound/db/root.key
> > (where the timestamp in a comment is updated twice a day in normal
> > operations),
>
> Hum, neither unbound(8) nor unbound.conf(5) teach me anything about
> that file. Whatever program may be changing that file, is there
> no way to fix it such that it keeps the comment constant?
> Even if time information is interesting for some reason, isn't that
> already available from the file write access date?
This is the usual file used with "auto-trust-anchor-file", which is
used when DNSSEC validation is enabled. It is written by unbound itself
and also by unbound-anchor(8) which is called conditionally from the
rc.d script.
auto-trust-anchor-file: <filename>
File with trust anchor for one zone, which is tracked with
RFC5011 probes. The probes are several times per month, thus
the machine must be online frequently. The initial file can be
one with contents as described in trust-anchor-file. The file
is written to when the anchor is updated, so the unbound user
must have write permission.
$ cat /var/unbound/db/root.key
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1460418862 ;;Tue Apr 12 00:54:22 2016
;;last_success: 1460418862 ;;Tue Apr 12 00:54:22 2016
;;next_probe_time: 1460460850 ;;Tue Apr 12 12:34:10 2016
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
. 172800 IN DNSKEY 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0
;;lastchange=1396470602 ;;Wed Apr 2 21:30:02 2014
I'd sooner remove it from changelist, but some people wanted it (I could
modify it locally, I don't have that many machines running unbound, but I like
to avoid things that require manual sysmerge sdiff runs in files which are
updated fairly often in the OS.
> > I divert those mails from many systems to a rarely read folder..
>
> That seems unfortunate indeed. I spent some work to get daily(8)
> silent by default with VERBOSESTATUS=0 (which i would still like
> to make the default, but that's maybe a seperate matter).
I used to adjust files locally to achieve that, but mtree is hard to handle
that way after updates.
> > I'd be much more likely to read these if it only reported when there
> > are *differences* in the mtree output.
>
> I fear i don't understand that remark. The security(8) script is
> not producing any mtree(1) output. It runs mtree(1) in the
> default checking mode (with -el), not in -c mode.
>
> But tracking down and fixing whatever is spammy in sane configurations
> seems worthwhile to me.
I meant "changes in the output from mtree(1) as included in the security mails",
i.e. if there is any difference from the "mtree -el" output from the last run.
Edge-triggered vs. level-triggered. It's a trade-off though, it would reduce
unwanted mail, but makes it more important that a given message is delivered
and noticed.
