Re: restricted shell
( I missed the start of this thread, but it looks like you are trying
to give users the ability to execute a few commands on your system,
without being able to do anything else ).
There are a variety of restricted shells out there. One big warning
though: unless you REALLY know what you're doing, it's damn near
impossible to make these things totally secure.
A much better approach is to give the user a normal shell, but deny
them access to any interesting commands.
The way you usually do this is arrange for them to be chrooted to a
partition that doesn't have any useful commands. Debian doesn't
provide any direct support for this, so it's a bit nasty, but it
can be made to work with some effort.
You put whatever you want to let them have in that chrooted partition,
and nothing more.
This STILL isn't totally safe, because they can almost always install
further commands--they could, for example, compile them elsewhere and
stick them on your disk.
So you might want to make this a bit harder and give them a restricted
shell AND a chrooted environment. Still, you'd be surprised how many
ways there are in Unix to execute commands.
For example, if they can echo things to a file they can stick commands
in their '.foward', and then send themselves mail; they can stick things
in their .profile and then log in; or they can play around with
environment variables and try and trick the commands you let them
run into doing more stuff.
One example is if you want to allow them to read mail--it's almost
impossible to arrange that the mail reader can't be fooled into
running something you didn't expect, or executing a less restrictive
shell, or saving a file somewhere that they weren't supposed to be
able to access, or whatever.
All in all, if you REALLY don't trust your users, don't let them
on the box. Let them have chrooted FTP and stick to that, and even
then, you have to watch out for '.forward' files and such.
As a general rule you should assume that if someone can get a
shell on your box, any kind of shell, then if they really try
hard they can probably get root as well. It's just a matter
of how hard they need to try.
- -
ANOTHER appraoch to this whole thing is to write a shell script,
and make that the users shell. If you really just want to let them
execute one or two commands, make them use ssh to log into your
box. Your shell script can look like this:
#! /bin/sh
# make sure nothing funny goes on
PATH="/bin:/usr/bin"
unset IFS
# make sure they rsh or ssh in with a command
if [ -z "$1" ] || [ "$1" != "-c" ]; then
echo You must use ssh -c to access this account
exit
else
# get rid of the -c
shift
fi
# only let them run specific commands
case "$1" in
command1) # run command1
;;
command2) # run command2
;;
default)
echo You are not authorized to do that.
;;
esac
Even then, if you don't trust them, this should all happen in a
chrooted area that has nothing of interest and no commands you
would want them to be able to run (see how paranoid I am ).
Also, if you're going to let untrusted users have any kind of
access to your system, you likely want to be running tripwire
and other intrusion detection software.
Justin
On Sat, Aug 21, 1999 at 11:21:41AM +0200, J Horacio MG wrote:
> >
> > On Fri, 20 Aug 1999, Stephen Pitts wrote:
> >
> > > On Fri, Aug 20, 1999 at 12:03:52PM +0200, J Horacio MG wrote:
> > > > Hi,
> > > >
> > > > I know of the existance of a restricted shell, though I'm not sure
> > > > whether this is what I'm after.
> > > Nope, correct me if I'm wrong, but you just want a way to remotely
> > > login to your computer.
>
> No, no, I meant a shell that restricts a user from almost everything,
> except login and a few simple chosen programs.
>
> > Actually, i believe some sort of restricted shell _is_ what is needed
> > here.
>
> Right!
>
> > bash has a -r option, this may bee what you want.
>
> Fine, I somehow thought there existed some sort of restrictive shell.
> How do you create such a user... ie. a user with a default bash -r
> shell?
>
> > > I'd say to use telnetd, because there are some nice telnet programs out
> > > there. But, telnet is insecure, and by default the only way to log in as
> > > root on telnet is to login as a normal use and 'su' to root.
> >
> > i definately would _not_ login as root over telnet, unless your su program
> > uses a one-time-password system of some sort.
>
> That's what I thought, that telnet is highly unsecure.
>
> > > If you can, do ssh and grab the unix version or the freeware windows
> > > program 'Tera Term Pro'.
>
> No, no need to use windoze at all... both machines will be running
> Linux...
>
> > ssh is definately the way you'll want to go. [...]
>
> That's what I was hoping for... I downloaded ssh2 (.tgz'ed and
> .deb'ed). Say, both machines are running under Linux with a
> dial-on-demand connection (one pc and the other laptop)... would I be
> able from machine2 to log into machine1 and do all sort of fiddling
> including upgrades?
>
> Thank You,
>
> --
> Horacio
> homega@ciberia.es
> Valencia - ESPAÑA
>
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>
Reply to: