Securing locally w/ rsh - concerns/questions...

Securing locally w/ rsh - concerns/questions...

Post by Andrew P. Dinsda » Fri, 17 Mar 1995 00:24:27



I am in the process of setting up a restricted environment for a K12
site.  Each users .profile is a link to /usr/local/retc/.profile and
all of the executables users can perform are in /usr/local/rbin.  This
includes a menu script, lynx, gopher, ftp, telnet, pine, ls, rm, and rsh.
The  users PATH is limited to this directory, execution is limited to
choosing numbers from the menu.

I am running gopher with the -s flag to stop shell escapes here, I have
a version of telnet with no 'z' command.  But I can see a few problems
with a few of the clients and commands I will need them to be able to
execute - hence this message.

1.  Is there an ftp client available that does not allow for the '!' shell
escape command.  I'd prefer them to not even see their shell (btw, if they
do get 'out' they cannot change shells).

2.  Is there a shell escape for lynx?  And can it be stopped?

3.  I set up the pine.conf.fixed config file to set global parameters, one
option is enabling/disabling features such as 'enable-suspend' and 'enable-
unix-pipe-cmd' - both of these I want to disable entirely but it appears
such configs can be changed for a session - is there a work around for this?
Or am I missing something in the pine.conf.fixed that allows me to set these
to disabled??

4.  I was planning on having users change their passwords from within the
Pine config - however, due to the restricted shell and path they cannot
execute /bin/passwd.  I am now wanting to cp /bin/passwd /usr/local/rbin -
are there any issues associated with this.  A new menu addition will be
added allowing users to run /usr/local/rbin/passwd from this menu.

5.  Are there any other shell escapes I am missing?

Some may question why we want such a limited environment.  I tend to agree
but understand this K-12's need to at least plug the most obvious holes
that once one 14 year old knows the whole school knows..

thanks

Andrew Dinsdale
--

 
 
 

Securing locally w/ rsh - concerns/questions...

Post by Marcus J. Ran » Tue, 21 Mar 1995 07:07:49


Quote:>I am in the process of setting up a restricted environment for a K12
>site.  Each users .profile is a link to /usr/local/retc/.profile and
>all of the executables users can perform are in /usr/local/rbin.  This
>includes a menu script, lynx, gopher, ftp, telnet, pine, ls, rm, and rsh.
>The  users PATH is limited to this directory, execution is limited to
>choosing numbers from the menu.

        How about this for a crazy idea? This is an approach
I've often recommended to those folks who claim that UNIX is
inherently insecure. :) In fact, it has all the tools you need
to build incredibly strong access control.

        Write a simple program that does a chroot to an area on
your system, setuids to the user, and then invokes the shell.
Make that each user's login shell. Then, only populate that
sub-area with programs that you have vetted, and your menu
program. You might want to do something like assemble the
sub-area out of 2 mount points for 2 physical devices.

Let's imagine you build something like:

/users
[Mounted on /dev/sd1g -options nosuid, readonly]
        /users/bin
                put executables here

        /users/etc [versions of passwd and group with all the
                real password information stripped out. versions
                of termcap, etc, etc, etc]

        /users/dev [/dev/tty, /dev/zero, and that's about it]

[Mounted on /dev/sd1h -options quota, noexec, nosuid]
        /users/home
                /users/home/mjr
                /users/home/otherguy
                /users/home/...

        Make sure there are NO setuid executables at all in the
/users area. I guarantee you, your users will be locked down
as tightly as you can possibly want.

mjr.

 
 
 

Securing locally w/ rsh - concerns/questions...

Post by Jay Ashwor » Tue, 21 Mar 1995 12:28:15



) >I am in the process of setting up a restricted environment for a K12
) >site.  Each users .profile is a link to /usr/local/retc/.profile and
) >all of the executables users can perform are in /usr/local/rbin.  This
) >includes a menu script, lynx, gopher, ftp, telnet, pine, ls, rm, and rsh.
) >The  users PATH is limited to this directory, execution is limited to
) >choosing numbers from the menu.

)       How about this for a crazy idea? This is an approach
) I've often recommended to those folks who claim that UNIX is
) inherently insecure. :) In fact, it has all the tools you need
) to build incredibly strong access control.

)       Write a simple program that does a chroot to an area on
) your system, setuids to the user, and then invokes the shell.

Did that thing about a * in the passwd file doing a chroot and second
login fall out of /bin/login?

Cheers,
-- jra
--
Jay R. Ashworth       High Technology Systems Consulting              Ashworth
Designer             Linux: The Choice of a GNU Generation        & Associates
ka1fjx/4       "Civil Liberty Through Complex Mathematics"     +1 813 790 7592

 
 
 

1. grep -f fails when using rsh but wrks locally

Hi Y'all
This is a repost cause I changed emails

I have a script  ( called update) which cleans the passwd and shadow
files of old users and adds new users. Whe I run the script locally it
wrks fine . when I run it remotey ( rsh $host "scriptname"  ) the grep
-f option fails and gives no output
Any ideas

::::::::::::::
update
::::::::::::::
#!/bin/csh

if ( `uname -s` == "SunOS" ) then
        alias grep /usr/xpg4/bin/grep
endif

##############################################
#this has to be run on the local machine no rsh-- till I fugure out why
won't run
#remotly  Has to do with grep -f option????
###################################################

#awk -F: ' {print $1}' /etc/passwd.users > /etc/passwd.usernames
#grep  -v -f passwd.usernames  /etc/shadow > /etc/shadow.orig
#cat /etc/shadow.user >> /etc/shadow.orig
#cp /etc/shadow.orig /etc/shadow
#
#grep  -v -f passwd.usernames  /etc/passwd > /etc/passwd.orig
#cat /etc/passwd.users >> /etc/passwd.orig
#cp /etc/passwd.orig /etc/passwd
#

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

2. ANSI file functions don't work in shared object

3. prompted password when I rsh locally

4. Problem of shared object

5. Additional Questions Concerning Re: Questions from Linux newbieI

6. Sysadmin /Account broken 3.2.4

7. Secure Secure Secure

8. Rebuilding Mac mklinux DR3 kernel for IP masquerading. (modules?)

9. Secure RSH, RCP, RLOGIN and friends

10. Newbie Question about running Apache Locally

11. Question concerning Kcron

12. "Operator" group question concerning UFSDUMP

13. Another great question concerning DEC Unix..