[vox-tech] Providing access to SSH on Kiosk?

[Bill Kendrick]

On Mon, Jan 12, 2004 at 06:41:59PM -0800, ME wrote:
> Anyone with the lack of understanding of risk to use of a public station
> to ssh to another box is dancing with the devil. (Condemnation of users
> who would actually use ssh on untrusted machines.)

Good point.  I'm working on a sheet that will be placed on the wall next
to the computer.  I already make note that using the system mgiht not be
safe, due to cookies, cache, wireless sniffing, etc.  I think I'll put
a BIG disclaimer on the SSH pop-up, as well.


> #1 (as I have said many times) ssh does nothing to secure the box in which
> it is used. SSH is only useful in trying to create a "secure connection
> over an insecure network."

Of course.  I'm only providing it as a tool.  I want it to be as
benign to the security of the LOCAL system as possible, though, hence the
IceWM -> Perl script -> Xterm -> SSH trick I put together, with Ken Herron's
help.


Once I'm done toying with the system, I'll disable SSH connections into the
box, as a precaution.  (Right now, I can get to it from my laptop when I'm
in the cafe, which is useful for admin & testing while other people use it,
or the owner's kid plays games :^)  He's 8, so I doubt he'll figure out
any kind of local root exploits ;^) ... then again.  <:^o )


> #2 When you run a public box as a Kiosk, the box is likely to be available
> to many anonymous users. When a new users arrives to use a box for which
> many other users have has physical access (and worse yet, unsupervised
> physical access) to use as an authentication point, they must trust not
> only the creators of the source for the packages, but also the packagers,
> and the person who built the box and *all* of the people who have touched
> the box since the OS was installed.

Yeah.  Scary :^|  Maybe we should come up with a disclaimer, too.
"Use this computer at your own risk!  Chamonix and LUGOD are not
responsible, blah blah blah."  Might need to think about PacBell,
since I believe they provide the DSL here.  Hrmm...


> Consider the multi-tier process of
> security vs. comprimise: shell -> local exploit, no shell but physical
> access ->  boot single user mode, password  LILO, use external boot media,
> password BIOS -> short BIOS. With sufficient resources, physical access is
> a security risk. In the most basic sense, at least a DoS can be completed.

Yeah.  Right now, they'd have to guess/hack passwords, or wipe the CMOS
(remove battery or hit jumpers).  In either case, that involves popping the
case open, and I doubt that would go unnoticed. :^)

Might make sense to look into a lock for the case, though...


> #3 Keyboard wedges that record keystrokes can also be placed in-line
> between the keyboard and the CPU. They can be small enough to often go
> without being noticed.

Yikes.  Any recommendations?  While in my mind, I say "that'll never happen,"
there is such thing as egg on faces. :^)


> with so much reliance on ssh, there are many of exploits and trojan kits
> out there for ssh from trojans/wrappers, to local port
> redirection/piggyback, to conduction of exploits to remote targets.

Can you explain these a little?  Based on how we're launching SSH
(see Ken's Perl script), is there anything to be concerned about?


> Given a shell, it is also possible to create "time bombs" where the
> machine will follow directions long after the user who dropped the
> packageh has logged out-- potentially harming another user.

I've done my best to keep users from getting shell access.  The GUI provides
no way to run a terminal.  The guest account is password protected, so
noone should be able to get in via console or GDM (which comes up sometimes,
depending on whether X/icewm die appropriately; a bug I need to look into).


> Kiosks are great for demoing web surfing, and GUI but testing ssh to trust
> remote machines from untrusted local machines is risky. I consider
> encouraging people to ssh from untrusted machine to be *almost* as bad as
> using gpg from a shell on an untrusted machine (gpg with keys and ID that
> is used by others as part of the Web of Trust.)

Again, duly noted, and I'll put up a big disclaimer. :^)


<snip> 
> (Maybe, if someone can get me a ride out to LUGOD over the summer, I might
> be able to do a brief presentation on SquirrelMail with courier imap... or
> if there are other SM users who are up for it, combine with them and team
> up to offer a presentation on it.)

Pick a date.  We can find a ride for you, I'm sure.  Sterba, perhaps? >:^)
(It'd have to be on a Monday, in that case.)


> Again, the above having been said, Kiosks are *great* tools for showing
> people the excellent advantages of Linux. They are excellent tools for
> demonstration and giving people opportuinity to feel  something of the OS.

Really, the point was to provide a web browser so that people without
laptops could get on the 'net while in the cafe.

Linux was just the obivous choice (relatively secure, relatively easy to
lock down, free, relatively stable, runs well on old hardware).


> Counter measures including having Kiosks that are client-server based and
> netboot with the Kiosk unit mounting and NFS root that is read-only and a
> server that is physically secured.

Not a solution here, unfortunately.  However, it's an interesting idea.
I'd love to hear more about it. :^)


> The user must still trust the installer
> of the OS, and the packagers as well as coders. There is also risk for
> keyboard wedges,

Still interested in how to deal with this... :^)


> shoulder surfing and other similar attacks,

Hehe, a problem even for us laptop users. :^)


> but since the
> client netboots, the HD, CDROM, DVD, and floppy drive can be physically
> removed, custom kernels can further disable port access (firewire, usb,
> serial, parallel) and the BIOS can be down-graded to not support other
> booting hardware. Also, netboot permits many, many clients to all share
> one server.

Cool. :^)


Thanks, Mike.

-bill!
bill@newbreedsoftware.com                           Got kids?  Get Tux Paint! 
http://newbreedsoftware.com/bill/       http://newbreedsoftware.com/tuxpaint/