|
Home > Archive > Unix Shell > February 2005 > Giving a menu, but restricting shell access ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Giving a menu, but restricting shell access ?
|
|
|
| This is in bash 2.04. I've got the menus all working fine, but I want to
insure that nobody can 'break' out to get a bash prompt.
Right now, I'm just using stty -isig
Is that sufficient enough or am I leaving myself open?
| |
| wmreinemer@tns.net 2005-02-20, 6:19 pm |
| **
Do a search for trap within man bash. IE:
$ man bash
/trap
Walt R.
**
| |
|
| On Wed, 16 Feb 2005 13:56:03 -0700, Kevin Rodgers <ihs_4664@yahoo.com> wrote:
>Mark wrote:
>
>Check your MANPATH.
>
>
>Not necessarily.
I can man other stuff, just not bash.
| |
| Nunya Bizness 2005-02-22, 2:52 am |
| Mark wrote:
> On Thu, 17 Feb 2005 07:43:14 +0100, Roland Jacob <r_jacob@syscomp.de> wrote:
>
>
>
>
> I like that idea. That's basically bulletproof and there is no need to
> control it at the script/shell level. Thanks!
There is one problem that you may need to handle with this method. You
may need to add /usr/bin/menu to the list of valid shells. It's been a
while since I have had to do this but it's just a matter of adding
/usr/bin/menu to a file somewhere - maybe something as straightforward
as /etc/shells but I really don't remember for sure.
| |
| Icarus Sparry 2005-02-22, 2:52 am |
| On Mon, 21 Feb 2005 22:45:47 -0700, Nunya Bizness wrote:
> Mark wrote:
[vbcol=seagreen]
> There is one problem that you may need to handle with this method. You
> may need to add /usr/bin/menu to the list of valid shells. It's been a
> while since I have had to do this but it's just a matter of adding
> /usr/bin/menu to a file somewhere - maybe something as straightforward
> as /etc/shells but I really don't remember for sure.
You probably don't need (or even want) to add it to /etc/shells. This is
used by things like the ftp demon to decide if access should be allowed.
If /usr/bin/menu invokes via $PATH anything else, then an attacker may be
able to FTP in a replacement version, which in turn enables them to break
out of the restricted menu system.
| |
| Nunya Bizness 2005-02-22, 2:52 am |
| Icarus Sparry wrote:
> On Mon, 21 Feb 2005 22:45:47 -0700, Nunya Bizness wrote:
>
>
>
>
>
>
> You probably don't need (or even want) to add it to /etc/shells. This is
> used by things like the ftp demon to decide if access should be allowed.
> If /usr/bin/menu invokes via $PATH anything else, then an attacker may be
> able to FTP in a replacement version, which in turn enables them to break
> out of the restricted menu system.
>
>
I mispoke myself when I said that I had to do this. Our systems
administrators were the ones who had to authorize the shell but I do not
recall where it was they had to do so. What I do recall is that until
they authorized the shell, simply changing the login shell for the
account in question in /etc/passwd did not work. This was on an AIX
system (4.2 at the time, I believe)
Also, one thing I meant to point out in my last post but forgot to:
Be VERY cautious about what commands you place in your shell script as
many of them, such as 'more', have shell escapes built into them. It
doesn't do much good to lock the barn door if you leave all of the
windows open.
| |
| Icarus Sparry 2005-02-22, 5:52 pm |
| On Mon, 21 Feb 2005 23:55:09 -0700, Nunya Bizness wrote:
> Be VERY cautious about what commands you place in your shell script as
> many of them, such as 'more', have shell escapes built into them. It
> doesn't do much good to lock the barn door if you leave all of the
> windows open.
Indeed you do need to be careful. However unless you can change the
environment, all that invoking the shell escape will do is start a new
copy of 'menu'. It is probably a good idea to change SHELL to point to a
simple script which just echos 'disabled'.
Programs which can change the environment include 'vi'
(:set shell=/bin/bash). The restricted version of vi does not allow the
shell escape.
| |
| Martijn Lievaart 2005-02-22, 5:53 pm |
| On Mon, 21 Feb 2005 23:55:09 -0700, Nunya Bizness wrote:
> Be VERY cautious about what commands you place in your shell script as
> many of them, such as 'more', have shell escapes built into them. It
> doesn't do much good to lock the barn door if you leave all of the
> windows open.
Just make sure your shell is defined as /bin/false and this should be no
problem. There are multiple ways to achieve this.
The easiest is when all users use ssh. Just define their shell as
/bin/false in /etc/passwd en use ForceCommand in sshd.conf to start the
menu on connect.
M4
--
Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering
their time inventing and implementing new, exciting ways for software
to suck. -- Toni Lassila in the Monastry
| |
|
| On Mon, 21 Feb 2005 23:55:09 -0700, Nunya Bizness <nunyabizness36@hotmail.com>
wrote:
>Icarus Sparry wrote:
>
>I mispoke myself when I said that I had to do this. Our systems
>administrators were the ones who had to authorize the shell but I do not
>recall where it was they had to do so. What I do recall is that until
>they authorized the shell, simply changing the login shell for the
>account in question in /etc/passwd did not work. This was on an AIX
>system (4.2 at the time, I believe)
Well, I won't be the one actually implementing this either. Our system guys
will take care of it. I've already passed along some of these ideas here, and
they said they can take it from here and implement a secure environment.
Sometime next week we'll be all set.
Thanks again for all the tips.
>Also, one thing I meant to point out in my last post but forgot to:
>
>Be VERY cautious about what commands you place in your shell script as
>many of them, such as 'more', have shell escapes built into them. It
>doesn't do much good to lock the barn door if you leave all of the
>windows open.
| |
| Nunya Bizness 2005-02-24, 5:58 pm |
| Mark wrote:
> On Thu, 17 Feb 2005 07:43:14 +0100, Roland Jacob <r_jacob@syscomp.de> wrote:
>
>
>
>
> I like that idea. That's basically bulletproof and there is no need to
> control it at the script/shell level. Thanks!
There is one problem that you may need to handle with this method. You
may need to add /usr/bin/menu to the list of valid shells. It's been a
while since I have had to do this but it's just a matter of adding
/usr/bin/menu to a file somewhere - maybe something as straightforward
as /etc/shells but I really don't remember for sure.
|
|
|
|
|