Re: Proposal: Inhibit "console down"

At Fri, 7 Sep 2007 09:51:12 -0700, Harris, David (IT Solutions US) wrote:
Subject: RE: Proposal: Inhibit "console down"
> 
>   First, my hat is off to Greg, for many years of support, discussion,
> and code contributions to Conserver. 

Thanks!  Conserver is still the best thing going, bar none, for the job
it does!  And, particularly with respect to this kind of proposed
feature discussion, it is open source so anyone who truly wants any
given feature is "free" to implement it.

What we're really discussing here is how, and in what form, such
features should be accepted back into the common source base of a given
public release branch.


>   STOP LOGGING: I will suggest that, as an net admin, that it is far
> easier to disable logging temporarily is easier, and faster, than doing
> a task that exposes passwords in the clear into the log file, and then
> trying to go back after the fact and clear the entries from the log
> file.

I admit I'm not a common user of most types of non-computing devices
that many conserver users may have connected to their console servers
for one reason or another, but I must say I've never encountered any
kind of device in recent years that echoed a password back to the user.

I.e. I think stopping logging to hide passwords is a very poor excuse.  :-)

(and I don't think adding explanatory tags to the gap in the tape are
anywhere near being a solution of any kind either)

Now perhaps if conserver was to be logging input as well as output then
maybe the ability to turn off logging of keystrokes would be a fair
feature to consider....  (especially for authorised users who would be
the only ones likely to know the passwords that might risk being logged)


>   * I also suggest that it is a LOT more manual effort (and therefore
> introduces more risks of unintended consequences) if someone must modify
> the CF file, HUP the server, make their changes, then re-modify the
> config, and HUP Conserver again. 

Well the point there is that an authorised admin can do that, but
someone of lesser powers will be unable to do so thus truly preserving
the integrity of the log.  Security doesn't come for free!  :-)



>   DOWN A CONSOLE: In a recent case, a console started spewing ~120
> Mbytes of data per 24-hr period. (It was a debug port on a "standby
> firewall" that went 'active'. It was logging to the partition that
> contained the other system logging for the OS, and it was rapidly
> filling the disk. We couldn't disconnect the port, as we needed to use
> it to command the firewall...but we couldn't let the disk fill (as that
> would halt the Conserver machine). Our tasks included sequences of
> up'ing the port, typing commands at the firewall, and down'ing the port,
> and testing the results.

There are two separate issues there getting munged up without proper
consideration of the security implications of either one on its own and
the proposed solution, in its simplest form, is in my opinion the worst
possible compromise.

One can buy a "refurbished" 750GB drive for well under $200 these days.  :-)

Even a brand new pair, in a RAID-1 enclosure, all with warranty, are well
within reach of anyone with any serious need for large-capacity storage
with decent availability and reliability.


Also, if the port was debug output only, then why was it logging at all?
Isn't the scroll-back buffer in your xterm big enough to capture all the
possible temporary history you could ever desire?  If not, why not?


There are a number of possible solutions that would preserve the ability
for a system implementer to create a more strict security policy while
still providing for the kind of flexibility that could be required for
testing and debugging, etc.

Perhaps, especially w.r.t. allowing users to turn port monitoring off
from the client interface, on idea would be to add both some form of
"classification" of ports w.r.t. their security requirements, as well as
a similar form of classification of users.  That way some users could be
authorised to have full control, and some classes of ports could be
designated as debug or test ports where log integrity is less relevant.

That's still perhaps a bit more complicated than it should be, but
ultimately it's the most flexible framework to build upon -- e.g. the
same features can easily be expanded to manage authorisation of client
controls that could be used to enable and disable logging too.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

Attachment: pgp00001.pgp
Description: PGP signature