berndmz@pcsbst.UUCP (Zimmermann) (07/06/84)
(I hope it's a new question.) Is the restricted shell really secure against unix-wizards if they are allowed to log in here over the net, or is `rsh' just good to control beginner students? (Should I ask this the net.unix-wizards?)
mcferrin@inuxc.UUCP (P McFerrin) (07/17/84)
The restricted shell CAN be secure if the administrator follows certain guidelines, some of which are included: 1- Do not have PATH setup to search the standard directories. Have it search only a directory that contains ONLY the commands you are allowing the restricted user. (called the restricted bin directory) 2- Do not permit the restricted user access to the bin directory established in step 1. 3- Use the .profile to setup any important variables you want and set them to read-only if necessary. Do a cd(1) to the appropiate directory. Include SHELL=/bin/rsh in the .profile. 4- The commands you put in the restricted bin directory should check the arguments to insure that the restrictions are not being bypassed. (e.g. arguments beginning with '/' or '../'. 5- If you want to include some standard Unix commands in the restricted bin directory, use the following example: cd $RESTRICTED_BIN ed .cmd a PATH="/bin:/usr/bin:..........$RESTRICTED_BIN" # ^^^^^^ your normal bin directories here for arg in $* do case $arg in /*|../) : echo "$0: \"$arg\" not allowed, restricted." 1>&2 exit 255 ;; *) : ok ;; esac done exec $0 $* . w q chmod 775 .cmd ln .cmd ls ln .cmd cat ln .cmd diff # The last 3 commands will make the ls, cat, & diff commands available # to the restricted user. Remember, shell scripts will be executed by a NON-RESTRICTED shell, thus giving you, the administrator, the full power in controlling what you are allowing the restricted user. Paul McFerrin AT&T Consumer Products
henry@utzoo.UUCP (Henry Spencer) (07/21/84)
Paul McFerrin comments: > The restricted shell CAN be secure if the administrator follows certain > guidelines... Dennis Ritchie has been heard to say, roughly, "You can't build a secure restricted shell by trying to take things out of the regular shell. Every one of those I've seen, I've broken." The "restricted shell" that Paul is referring to is almost certainly "one of those". So beware. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
john@genrad.UUCP (John Nelson) (07/26/84)
Whoops! I could break out of that restricted argument checker. While it checks for arguments that begin with "/" or "../", it did not check for filenames that start with "./../" or other equivalent aliases for "..".
smk@axiom.UUCP (Steven M. Kramer) (07/29/84)
John, another good one is //.., since on most UNIX systems, ///////// is
treated as a single / (in nami), and utility code that doesn't also
do the reduction is gonna <plop>!
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)bsafw@ncoast.UUCP (The WITNESS) (07/30/84)
On a related question: we have implemented a restricted filesystem-cum-shell
by means of a program that does a Xenix chroot() syscall and then execs the
shell. But the only way to make it really secure, that I can see, is to break
the '..' link in the restricted root. Anyone see a way that won't get fsck
upset?
For those (a majority, I would guess) without chroot system call: it causes
the current process to consider / to point to the directory named in the call.
The program that we use does this:
main() {
chroot("/ROOT");
chdir("/usr/guest"); /* actually /ROOT/usr/guest */
setuid(GUESTUID);
setgid(GUESTGID);
execl("/bin/tsh", "tsh", 0);
}
Thanks for any help you can provide.
--
Brandon Allbery: decvax!cwruecmp{!atvax}!bsafw
6504 Chestnut Road, Independence, OH 44131
Witness, n. To watch and learn, joyously.greggt@ncoast.UUCP (Gregg Thompson) (07/31/84)
It make the chroot() call not
go back past the 'new' root area you
use the following program.
main()
{
unlink("DIRECTORY/..");
link("DIRECTORY/.","DIRECTORY/..");
}
I think that is right. This
will make sure there is the right
number of links and will make '..'
point to '.'.
--
Gregg Thompson
{ucbvax}!decvax!cwruecmp!ncoast!greggt
{ucbvax}!decvax!cbosgd!aat!m-net!greggt
{ucbvax}!decvax!microsoft!trsvax!sneaky!greggt
{decvax}!ucbvax!dual!proper!greggt
{ucbvax}!decvax!vortex!ihnp4!wlcrjs!greggtbsafw@ncoast.UUCP (The WITNESS) (07/31/84)
The problem is that "smart" file system checkers (i.e. "fsck") will
also check to make sure that "." points to the current directory and that ".."
points to its parent. Running fsck on a filesystem with ".." pointed to "."
will cause everything from that point on to be discarded by fsck. (It is much
more likely that something damaged the filesystem than that someone unlinked
".." -- so the designers of fsck would have thought.)
What I'm after is a means of protecting the filesystem without
unlinking or modifying the directory links. Can anyone help
--
Brandon Allbery: decvax!cwruecmp{!atvax}!bsafw
6504 Chestnut Road, Independence, OH 44131
Witness, n. To watch and learn, joyously.jdb@mordor.UUCP (John Bruner) (08/03/84)
You should be able to keep a restricted account from wandering afield via ".." by making the parent directory non-executable. I.e. make the home directory for the restricted account "foo" be "/mnt/locked/foo" (replace "/mnt" with whatever top-level directory you plan to use) where "/mnt/locked" is owned by root and is mode 700. This assumes, of course, that the restricted account isn't running under user-id 0 :-) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
did@UCLA-LOCUS.ARPA (08/05/84)
From: "David I. Dalva" <did@UCLA-LOCUS.ARPA>
You should be able to keep a restricted account from wandering afield
home directory for the restricted account "foo" be "/mnt/locked/foo"
[...] where "/mnt/locked" is owned by root and is mode 700.
Sorry, "cd /" gets you out into the free world. You'd have to take cd
(and chdir) out of the shell (but a C program which did a chdir(2) call
and a fork would simulate *that* :-( ).
...and there's also the problem of not being able to access your home
directory at login time.
Dave
Arpa: did@UCLA-LOCUS.ARPA
UUCP: {ihnp4 | randvax | sdcrdcf | trwspp | ucbvax}!ucla-cs!didguy@rlgvax.UUCP (Guy Harris) (08/07/84)
> On a related question: we have implemented a restricted filesystem-cum-shell > by means of a program that does a Xenix chroot() syscall and then execs the > shell. But the only way to make it really secure, that I can see, is to break > the '..' link in the restricted root. Anyone see a way that won't get fsck > upset? Yup. Modify "namei" so that if it detects a directory entry called ".." which points above the current root directory, it gets remapped to the current root directory. That's what all 4.xBSD and System X UNIXes do (note; this may give ".." a special meaning, but vanilla V7 also treats some directory entries specially; any entry ".." that moves above the root of a mounted file system gets remapped to the parent of the mount point, to permit 'chdir("..")' to work correctly from a mount point). > For those (a majority, I would guess) without chroot system call: it causes > the current process to consider / to point to the directory named in the call. If it is the majority, that's unfortunate; the system call is provided in V7 and all its successors. The only reason for ripping it out of a UNIX version is fear of the security hole produced by permitting 'chdir("..")' above the fake root, and that's easy to fix. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
bsa@ncoast.UUCP (The WITNESS) (08/12/84)
I found out about it being in V7 just recently; the call is of the type that
Microsoft appeared to have added to the system in the interests of security,
so I made an assumption on insufficient data and it jumped back and bit me.
Unfortuantely, you just made an assumption too: that we had source for Unix
(or so it appeared); Microsoft may make it available but Tandy touched this one
and I have yet to hear of their providing source. (trsvax || microsoft please
correct me if I'm wrong.)
Just changing the protection & owner of .. is enough, I realized; and better
because root and the owner of the restricted filesystem can get out if necess-
ary. I have already implemented a scheme using this to provide a tutorial
minisystem to attach to my pet software project.
Thanks for the replies, anyway, all; I am starting to learn something about
the system I've been using.
--
Brandon Allbery: decvax!cwruecmp{!atvax}!bsafw: R0176@CSUOHIO.BITNET
6504 Chestnut Road, Independence, OH 44131 <> (216) 524-1416
"The more they overthink the plumbin', the easier 'tis tae stop up the drain."