Re: override write protection?

[Jeff Licquia <jeff@luci.org>]

On Mon, Aug 14, 2000 at 08:16:23AM -0500, Charles Menzes wrote:
> > 
> > You realize, of course, that securing shell access to the box is
> > almost futile.  But, this is better.
> > 
> 
> 	this is probably the most common thing i hear, and yet
> 	i am constantly on boxen that are allowed as public access
> 	by providers to allow for traceroutes from within their 
> 	networks. why would they do this without a certain level of
> 	comfort in the machine's security? are all shells as insecure
> 	as bash?

Bash isn't actually too bad, as shells go.

The problem is that "restricted shell" systems violate a fundamental
security principle.  The right way to secure a box is to deny
everything and then find things to allow; restricted shells, OTOH,
start from the position of a shell (i.e. allow just about everything)
and restrict certain things that are considered unsafe.

As an example, if the system is Intel Linux, it would be trivial to
compile a small C program on a local Linux box that execs bash with a
sanitized environment, upload it, and run it.  Voila: unrestricted
shell access.  So how do you upload the file?  Assuming no rz/sz or
FTP access, you could always do something like this:

  (echo username; sleep 1; echo password; sleep 5; \
   echo 'cat > mytrojan') | cat - mytrojan | telnet shellhost

Many providers that provide shell access simply don't have a clue.
Those that do typically consider the shell box to be as untrusted as
the rest of the Internet, or even less trusted (since the box has LAN
access to the ISP network, with all the DoS attacks that implies).

(For the purpose of allowing traceroutes: why can't traceroute be
wrapped in a CGI of some kind and provided through the Web?  I've seen
it done before.)
-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.