[Could the list software add a Reply-to header? ]
A levelezőm azt hiszi, hogy Alfonso De Gregorio a következőeket írta:
> On Tue, 22 Aug 2000, Chris Calabrese wrote:
>
> Hi,
> thanks for your reply.
>
> > However, the U.S. Controlled Access Protection Profile and
> > Labeled Security Protection Profile (which replace the old
> > C2 and B1 designations of the Trusted System Evaluation
> > Criteria) require that mechanisms that are part of a
> > system's Trusted Computing Base shut down if they can't log,
[]
> Blocking if the output queue is full can give enough time to an attacker
> to complete his "work".
>
> Yes, is safer to shut-down, unlink from a network and unplug an host (I
> agree with this) but to have a service permanently available is useful :-)
[]
The priority between availability and other security requirements
(sensitivity, integrity, functionality) is a matter of local policy. CAPP
and LSPP gave sensitivity and integrity the higher priority. However, if
you cannot ensure the integrity of a system, you cannot ensure its
availability either (and the inability to send the logs does not
necessarily means that the integrity is endangered). I think we can
distinguish between "ability to log" and "ability to send the log". In a
networked environment you cannot be sure in delivery for a reasonable cost.
The details I am thinking about (and outside of the scope of the protocol):
-The system logger uses a ring buffer on disk, sizeable by the administrator.
-The system logger have a mechanism to detect extreme logging frequency (DoS),
and/or a mechanism to reduce it (from simple "last message repeated nnn
times" to ability to independently count repetition for different
messages, and/or shutting down log sources/subsystems, and/or ability to
stop administrator specified services). Oh, and notification on the
receiving end if some source ceases to log.
-The system logger sends from the ring buffer, if it can. If the ring buffer is
x% full, it generates an alert. If it is y% full, it shuts down. It
means that the administrator will notice if a DoS happens (or network
outage), and have a reasonable timeframe to enhance the situation. The
problem is that events of a breakin followed by a DoS might not
reconstruable. If that is needed with 100% probability, the logging
subsystem should shut down the TCB as soon as a DoS detected.
And even the LSPP does not say that every log event shall be delivered. It
only says that the possible causes of drops and the amount of dropped log
shall be documented.
--
GNU GPL: csak tiszta forrásból
