>> that's very true, but you're only talking about a fraction of a
>> second.  that's not even long enough for you to log in locally via
>> 100base-t and do *anything*.
>
>Not long enough for me-the-human to.  Quite possibly long enough for a
>computer, acting on my behalf, to.  I'm certainly not about to bet the
>security of my system that it's too short to hit.

i don't even think it's long enough for that.  all you're running
against is the execution of date(1) on a machine that just rebooted
(so we can assume load is rather low).  let's even assume that since
we have to actually "hack" in to accomplish something during this
window of opportunity that we can't otherwise do, the sysadmin of the
machine in question has set SF_IMMUTABLE on a file we wich to affect,
and that we can't directly log in as root.  i'll even give you rsh,
just to make it easier for you.  so you have to have a machine (a) rsh
in, (b) hack root, and (c) remove the flag.  meanwhile, all date has
to do (we could even move inetd to after date) is get the time, format
it, and print it.  i just don't think so.

an analogy: my windows here at home are closed.  they're not airtight
or watertight, but there are no bugs in my house.  i'm cool.  :)

>Not that this is a reason not to move inetd's startup line.  Just that
>we shouldn't move it and proceed to consider the problem thereby
>eliminated - moving it is cheap and easy and shrinks the window, which
>is an improvement even though it isn't a cure.

i would be absolutely positively completely convinced that it was
closed so tight that you couldn't get in.  not convinced that it was
closed, but closed to the point that you (for arbitrary values of
"you") couldn't get in.

-- 
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."