On Sat, Jul 29, 2017 at 05:25:51PM -0400, Joe Gidi wrote: > I did a couple of fresh installs the other day, which reminded me of a > minor irritation and prompted me to think about a possible solution. > > The first run of security(8) on a fresh install is not terribly helpful. > It produces a huge email report since it diffs all the /etc/changelist > files against /dev/null. If you're already familiar with OpenBSD and > understand this behavior, you probably disregard this email and drive on. > > If you're a new user, this is probably surprising and somewhat misleading. > After all, you've just installed an operating system that takes > justifiable pride in sane, secure defaults, and the next morning you > receive a multi-thousand-line insecurity report that calls out every > important configuration file on the system. > > I think the simplest way to prevent this would be for install.sub to add a > line to /etc/rc.firsttime that runs security(8) and discards the output, > or perhaps logs it to a file, rather than emailing it. This would "prime > the pump" by populating /var/backups with as-installed copies of the > changelist files, and then the first nightly run of security(8) would only > show files that have actually been changed post-install. > > Of course, this also means you have virgin copies of your config files > stashed away immediately, in case you need one before the nightly > security(8) run can back them up for you. > > This will make the first boot take longer, perhaps by several minutes on > slower platforms. Of course, the first boot is already slower due to key > generation, etc. > > Diff below was tested in an amd64 bsd.rd and seems to behave as expected. > I have *not* built a full release or tested every possible use case; I > know there are sometimes issues with space on some install media, and > hopefully this small addition would not cause an overflow. > > Does anyone see value in this? If not, I suppose it might end up living in > my install.site.
The "prime the pumb" aspect to have an initial state in /var/backups is the only thing I would see as a pro argument for such a change. But I guess there is bikeshedding potential as to what is considered the "initial state". Is it the state on first boot or how the system is configured afterwards? Think of solutions like cfengine, ansible, salt, etc that might run after system installation to apply changes. You can always execute security(8) at any point you consider the initial state if they care about this aspect. -- -=[rpe]=-
