Suppose you could put time-windows on an entry in 
hosts.allow.  Do you think this would give any 
practical security benefit?

The idea is, an ALLOW or DENY rule could have a time-window attached
to it, as in BEGIN_TIME..END_TIME, where each of these
time-windows (or "timespecs") could look like a date(1) 
time specification. 

A hosts.allow file would have optional timespecs after the rules.
With both timespecs gone, it just means, "forever",
which is the current default behavior.  Timespecs
could come in two flavors, an absolute timespec CCYYMMDDHHMM
and a relative timespec, in which some of the most
significant digits are missing.  An open-ended timespec
would have to be an absolute one.  Ergo

	..199912291200

means, until 1999, Dec 29th, 12noon.  and

	199912232300..

means, after 1999, Dec 23rd, 2300 hrs.  and

	199912232300..199912291200

means, in that time frame (inclusive).  and

	1200..1400

is a relative timespec meaning, from noon to 2pm each day.

so you could put in rules like 

sendmail:  ALL: ALLOW: 1200..1400

saying, I accept sendmail connections from 12noon-2pm each day.
Perhaps you'd want to put a window on a DENY rule, as in

# when the army of darkness tries to break into my machine.
ALL: ALL: DENY: 2200..0800

If having time-windows on hosts.allow makes sense, I can already
do this by having a cron job rewrite the hosts.allow
as needed.  This has the advantage of not requiring any
changes to userland proper.  :-)

So.. question 1.  Do you think there is any practical security benefit
                  to be had from time-windowing the access to a host?

     question 2.  If there is, is it better to do this with cron,
                  or by changing libwrap to read new (optional)
		  timespecs from the hosts.allow file? 

-lou