Keeping the lid on users
2007-12-25 9:00:00
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.
>
Comments
Got something to say?
You must be logged in to post a comment.
