SUMMARY: Keeping the lid on users

From: Mike Jones (cso2!c6!mike@uunet.uu.net)
Date: Wed Apr 19 1995 - 09:49:01 CDT


Thanks to all who replied:

Jim Anderson
        Suggested a pair of programs; one to run as user, passing
        requests via a socket to a "trusted" server. (I've never
        written any socket programs, but I suspect that STREAMS or
        IPCS could be used).

parallaxinc.com!tmornini (Tom Mornini)
        Suggested renaming the *real* file access commands, and
        wrapping them in a script which *was* accessible to the users.

Mark <lochard.com.au!mark>
        Suggested NFS (read-only) mounting the data directories into
        the users' file space

Sun.COM!mshon (Michael J. Shon {*Prof Services} Sun Rochester)
        Suggested using the automounter - create a mapping file which
        is INSIDE the restricted environment, and let the automount
        daemon (outside the restricted space) handle file attaches.

Glenn.Satchell (Glenn Satchell - Uniq Professional Services)
        Suggested a C program to read the contents of a directory not
        on the user's path, and copy it/pipe it/run it through 'more'
        into the user's home directory.

It looks like all the above approaches could work (but I'll have to do
a bit more studying about SunOs's automounter - we have more experience
with other UNIXes which don't work that way...). However, they all came
with a "not tried - but should work..." warning.

Kevin.Sheehan (Kevin Sheehan {Consulting Poster Child})
        Suggested chroot; he creates a chroot "jail" and lets the users
        roam around it at will. He can give them an ordinary unrestricted
        shell, because they can only see/run what he chooses to put in
        (or below) their new root directory.

This looks like a "tried and tested" approach, and after a few
experiments, I think it will work for us.

Thanks again to all who responded - and apologies to anyone I've missed.

-- 
=============================================================================
Mike Jones:                              Tel: +44 (0)1633 812432
Unix Support                             (GTN) 1211 2432
Room D.171                               Fax: +44 (0)1633 812863
Central Statistical Office               Email: mike%cso2.uucp@britain.eu.net
Cardiff Road, NEWPORT, Gwent. NP9 1XG
** Opinions & comments are mine - not necessarily those of my employers **
========================================================= written on CSO6 ===

The original query:-

> > Hello, Sun managers > > Can anybody suggest anything to solve this problem? > > The background: > We run Solaris 2 on a SparcServer 10. Some of the users on this > system come from outside our company, so according to our > security policy we *can't* trust them. > > We give them a restricted login shell (/usr/bin/rksh) and put all > the commands they need in a separate directory. Then (in > .profile), we change their PATH variable to point only to that > directory (and $HOME). > > So far, so good - this is all textbook stuff. The users can't cd out of > their home directory, and can't execute any command not on their path. > > The problem: > We have to provide read access to data files on the fly; as > the files are created or deleted elsewhere, we have to allow > or deny access to them. We do this by linking the data files to > each of the users' home directories in turn, and deleting the > links when the files are deleted. > > This is just about manageable for the handful of users we have > now - but it's going to be a nightmare when we have tens or > hundreds of users. > > What we need is some equivalent of the $PATH environment variable, for > data files, which will allow users to read files just by specifying > their basenames. > > Any suggestions welcomed - I will summarise. >



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:22 CDT