Worthy to add XCCDF rule to ensure regular system reboots?

Steve Grubb sgrubb at redhat.com
Tue Dec 17 17:33:01 UTC 2013


On Tuesday, December 17, 2013 05:47:39 AM Jan Lieskovsky wrote:
>   slightly related with my previous post, and with experience seen
> from customer systems (whole system not rebooted for many of days,
> possibly even for years to ensure its work / compatibility), wondering if
> the agencies focused on computer security have a recommendation /
> requirement underlying system reboots to be scheduled on regular
> basis (like once per month).
> 
> As already mentioned, on one hand there can be often seen scenarios
> when customer(s) don't reboot the system due the fear of breaking
> the functionality / compatibility. Such behaviour on the other hand
> obviously means, that for example fixes for selected security flaws
> (mainly in the kernel) can't be applied completely / correctly,
> leaving the system in question still vulnerable to particular attack.

This is a site specific issue and can't be generalized. For example, rebooting 
a machine hosting VM on QEMU could potentially take down 15 - 20 systems at 
once. They would need to migrate the VMs to other systems and then reboot. You 
can also have the same issues for DNS or database servers. Rebooting them can 
cause many unrelated systems to have failures during the time it takes to 
reboot.

Then, what it it doesn't come back up? I've seen systems that just needed a 
reboot and the server never comes back up...ever....needed new memory because 
memory problems corrupted the update on disk.


> Therefore was thinking if we would want to introduce XCCDF rule /
> recommendation requiring the system to be rebooted on regular basis
> (like once per month looks reasonable, but opened for proposals),
> to ensure this (kernel still being vulnerable) wouldn't happen.

I'd say it would be fine to detect files in use that are deleted because of an 
update just to call attention. But to _require_ a reboot on any kind of 
schedule is going to be tailored/disabled immediately.


> Besides that (I think) even when the reboot should result into
> system not being bootable, it's better to find it immediately,
> than after period like ~3 years (many of fixes applied at once =>
> harder to find out which concrete one actually caused the failure
> to boot).

I'd say a lot of people would rather have uptime and just restart critical 
services as long as possible.


> The corresponding OVAL check could see if there exists particular crontab
> entry scheduling reboot once per month (and fail if not). The fix then
> would be to add such crontab entry (possibly including "wall" notification
> with some delay prior actually performing the reboot).

I hope no one adds something in crontab to reboot. :-)

-Steve



More information about the scap-security-guide mailing list