Mailing List Archive

Proposal: Inhibit "console down"
Hello,

how about adding an conditional statement around ^Ecd ? I do not want
users to down a console at all. Something like

OLD:

group.c Line 3620:
case 'd': /* down a console */
CommandDown(pGE, pCLServing, pCEServing,
tyme);
break;

NEW:

case 'd': /* down a console */
if (pCEServing->allowUserDown) {
CommandDown(pGE, pCLServing, pCEServing,
tyme);
break;
}

and an option "options [!]allowuserdown" in conserver.cf

I am no C programmer, just to be discussed.

cu, Steffen



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: Proposal: Inhibit "console down" [ In reply to ]
Yep...I certainly like it. It goes along with the other recent post
about preventing folks from turning off logging. Both should be doable.

Bryan

On Thu, Aug 02, 2007 at 11:30:35AM +0200, Steffen Rheinhold wrote:
> Hello,
>
> how about adding an conditional statement around ^Ecd ? I do not want
> users to down a console at all. Something like
>
> OLD:
>
> group.c Line 3620:
> case 'd': /* down a console */
> CommandDown(pGE, pCLServing, pCEServing,
> tyme);
> break;
>
> NEW:
>
> case 'd': /* down a console */
> if (pCEServing->allowUserDown) {
> CommandDown(pGE, pCLServing, pCEServing,
> tyme);
> break;
> }
>
> and an option "options [!]allowuserdown" in conserver.cf
>
> I am no C programmer, just to be discussed.
>
> cu, Steffen
>
>
>
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: Proposal: Inhibit "console down" [ In reply to ]
At Fri, 10 Aug 2007 11:04:20 -0700, Bryan Stansell wrote:
Subject: Re: Proposal: Inhibit "console down"
>
> Yep...I certainly like it. It goes along with the other recent post
> about preventing folks from turning off logging. Both should be doable.

It seems to me that run-time logging control through the client user
interface is way far out of the design goals of any good console server.
In fact I would say it would be antithetical to the design of a good
console server. It should _always_ be _impossible_ for any user of any
compatible client program user to affect the logging configuration.

It also seems to me that if any client user wants an extra copy of the
log of what they've done then I'm sure they can just learn to use the
common tools that already exist for such purposes, such as the
aforementioned "script" utility.

Creeping featurism for such obviously bad and/or unnecessary ideas is
never a good thing, especially when some forms of decent security
policies become impossible to implement as a result. The best way to
make security easy from the get go is to follow the KISS principle
foremost.

The original subject of this thread, the proposed ability to inhibit
"console down" is also an indication of a design flaw. Turning down a
console port is not really something that should be controllable from
the client protocol in the first place. (However the converse,
triggering an attempt to bring the console up again is a very useful
feature to have in any console client.)

--
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>
RE: Proposal: Inhibit "console down" [ In reply to ]
First, my hat is off to Greg, for many years of support, discussion,
and code contributions to Conserver.

I understand Greg's security perspective, but I feel moved to discuss
cases where turning off logging, or being able to 'down' a console have
been useful and necessary. My intent is only to present the cases,
without trying to lobby for the preservation of the features, and then
see what discussion may evolve from the group. :-)

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.

* In this case, I think the integrity of the log file is preserved, in
that it was not, itself, physically modified, and notation was made
where an operator invoked a "gap in the tape"...;

* 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.

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.

* We later moved the logs to a larger partition, and lowered the log
rotation size from 20 MB to 10 MB.

* From time to time, "Down Happens". I'm pretty sure that the
discussion hasn't approached whether or not client users should be able
to "up" a port. But what if the port is something that spews, such as
the firewall debug port? If a client 'up's the port, sees that it's
spewing, but cannot 'down' the port again...what then? You don't know
what is on the 'other side of the door' until you open it. (In real
life, you feel the door before you open it to see if there is fire on
the other side, but you can't tell if the other side 'only' has a toxic
smoke... ;-)

In summary, I like KISS, but I also like flexibility. I see that
Conserver can evolve into a very secure tool, or it can become a bit
more complex in order to allow the administrator to configure
very-secure, or looser levels of control.

David 'Zonker' Harris
Silicon Valley Service Delivery Center, Network Operations

Siemens IT Solutions and Services, Inc.
Infrastructure Management Services
39600 Eureka Drive
Newark, CA 94560
Tel: 510 624-5524
Mob: 510 648-0701
Fax: 510 624-5508
mailto: david.k.harris@siemens.com
www.usa.siemens.com/it-solutions

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
RE: Proposal: Inhibit "console down" [ In reply to ]
Greetings,
As someone who doesn't often contribute to conserver, my opinion is worth as much as you are willing to pay for it. If it's more than 4 cents then you're paying too much (and given that I'm British and the exchange rate is lousy for you, you're probably already paying too much)...
STOP LOGGING: I can understand circumstances where you might not want to log some information, but I would suggest that if you can stop and start logging then the command should ideally prompt you for a reason, and then log a note saying something like "John stopped logging on 7th November 2006 at 12:00:03. Stated reason 'I hate being snooped on'". (Feel free to mangle the format to your own desires...) Basically you want to know who, when and what reason they gave. You can then chase them down later if you have questions. Sure this doesn't provide ideal auditing, but at least it records what happened and why. It would also be good if this was a per session setting. i.e. you disconnect without remembering to turn logging back on, it gets turned back on automatically.
DOWN PORT: Again I can see why you might want to down a port. It would again be nice if the same information was logged though. Who, When, What and Why. If you look at the log file and see "Jasmine downed port 17 as it was spewing data" then you don't need to up it to find out why it was downed.
It would also be good if these commands could be limited to sets of users. i.e. You let the administrators up/down ports and stop logging, but you don't let end users do it. While this adds some complexity it does so in order to provide for flexibility. The security conscious administrator might not want anyone to be able to run those commands, while in an open environment they might be allowed for anybody.
Just my 2p.
Adam



DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message.
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: Proposal: Inhibit "console down" [ In reply to ]
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>
Re: Proposal: Inhibit "console down" [ In reply to ]
On Sep 21, 2007, at 14:29, Greg A. Woods wrote:
> 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.

It's very common for routers to require you to enter a new
password in
into the CLI, which will be echo'd. The password prompts don't
typically
echo passwords, but passwords are sometimes used in other ways. This
is the first example I have thought of, but I'm sure there are others.

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

I think this would be something that conserver should have, for
just this
above reason. I think it should be a fairly restricted ability, to
prevent both
abuse and accidental use, but I think it has clear value, in an
admittedly
small number of situations.

Just from someone who does console-monitor a variety of routers and
switches, in addition to UNIX host consoles.

- Chris

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: Proposal: Inhibit "console down" [ In reply to ]
On Fri, Sep 21, 2007 at 02:29:02PM -0400, Greg A. Woods wrote:
> 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 once came across a device, I think it was a Sun storage controller (6120?)
which actually echoed back the password, character by character, but
immediately backspaced and replaced it with a '*' ;-)

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: Proposal: Inhibit "console down" [ In reply to ]
On Fri, 2007-09-21 at 22:27 +0200, Fabien Wernli wrote:
> I once came across a device, I think it was a Sun storage controller (6120?)
> which actually echoed back the password, character by character, but
> immediately backspaced and replaced it with a '*' ;-)

are you sure it was the 6120? I'll file the bug if you can be a little
more specific. firmware revision and a log demonstrating the bug (not
with the real password!) would be great.

- Bill



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: Proposal: Inhibit "console down" [ In reply to ]
At Fri, 21 Sep 2007 15:02:40 -0400, Chris Ross wrote:
Subject: Re: Proposal: Inhibit "console down"
>
>
> On Sep 21, 2007, at 14:29, Greg A. Woods wrote:
> > 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.
>
> It's very common for routers to require you to enter a new
> password in
> into the CLI, which will be echo'd. The password prompts don't
> typically
> echo passwords, but passwords are sometimes used in other ways. This
> is the first example I have thought of, but I'm sure there are others.

That's still an _extremely_ poor excuse.

Even with such a feature conserver cannot save you from accidentally
recording such a password in your console logs.

If the goal is to protect such passwords from casual observers then
having a manual hook in conserver allowing the operator to disable
logging temporarily is most definitely NOT any kind of valid solution.

A correct and secure solution will probably involve never logging any
session to any such poorly designed device, or else always protecting
all logs from such poorly designed devices from being viewed by
unauthorized persons.

--
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>