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

[ME]

Bill Kendrick said:
> On Mon, Jan 12, 2004 at 06:41:59PM -0800, ME wrote:
> 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 )

It is not wise to underestimate people because they are young. ]:>

When dealing with children on systems like this where you have them using
it and you wish to enforce policies to prevent them to access certain
resources, you have the same problem as a prison with inmates:

You have a finite time to create a policy. They have a nearly infinite
time to think about breaking the systems, and may collaborate with each
other in an organized attack. (Nearly infinite when you compare the time
to build that you spend to the number of users who might attack it
multiplied the amount of time they are willing and able to spend upon it.
All they need to do is succeed once and they win. If you fail just once
then you lose. (And they wont go out of their way to notify you of this.
;-)

The children/inmates outnumber you, and are more interested in doing what
you do not want them to do than you are  to stop them. You have other
things to do while they may wake up thinking about how to defeat you (your
policies) and go to sleep with the same thought.

>> 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. :^)

What about LILO/grub? can the user pass args to the kernel to be booted?
You know, the old "init=/bin/bash" arg/trick for local root on boot
without restrictions...

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

They help. Of course there is the MIT guide to lock picking.... Though,
how many people actually learn how to pick locks? ]:>

>> #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. :^)

A well known "TLA" has issued notices about this as a problem at
government institutions, public libraries and places run by state and
federal government/tax money which offer kiosk-like internet access to the
public.

>> with so much reliance on ssh, there are many 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?

These require one of two things:
1 access to build their own ssh clients with modified source code and
force the user to call their ssh client instead of the one you installed.
(Usually this means root access.)
or
2 access to alter the flags passed to the ssh client. Examine the lags.
You can do some really clever port redirection from local service ports to
your remote machine. This can permit piggy-backed session access through a
firewall or other network filter for one user to scan or conduct network
attacks through the connection of another. Also examine the support for
SOCKS 4/5 support in openssh clients. Verry, *very* useful and powerful
things! Like any powerful and useful tool, a risk if the user who is
calling the ssh app does not know these flags are being called by a
Trojan/wrapper.

A presentation on the useful features of ssh would also be good.
(Tunneling, proxy, redirection, etc.)

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

Consider the other post where I discuss use of the browser to call a
specified application and make that application a shell (with proper
flags/args, an interactive shell.)

OT:
However, with Linux things are not as bad as windows. Consider Windows NT
4 (pre SP3 I think-- very old btw) if the user could change screen saver,
they could make the screensaver call command.com or a batch script and the
screensaver run as SYSTEM. :-o

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

We'll have to see what happens.I'll have a better idea in April. If the UC
Davis CS dept  wants to have me in their grad program on cs security,
maybe I'll move to Davis in 2005 and attend LUGOD a little more often than
I do now. :-D

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

OK. Consider another drive to image the system and rebuild every morning.
A local disk with rsync would be pretty fast.

>> 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... :^)

Not many. Jeff brings up some of the solutions that seem  good to me.

>> shoulder surfing and other similar attacks,
>
> Hehe, a problem even for us laptop users. :^)

Yep. I did not even mention tempest machines. I figured that they are well
beyond what most any normal person might use while other attacks are so
much easier.

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

No problem. Hey Bill. Have I ever told you that the work you do is very
cool, and most excellent? Ok. The work you do is cool and most excellent.
:-)