on my mud security of 'big' itemes is mainly direct IDNUM checks.
anyways i'm more interested on how you would go about making a subshell in
the mud that could access the rest of the computer includeing perl. i have
tried to use perl in c/c++ before and never could get any where with it.
>From: Peter Ajamian <peter@PAJAMIAN.DHS.ORG>
>Reply-To: Circle Discussion List <CIRCLE@post.queensu.ca>
>To: CIRCLE@post.queensu.ca
>Subject: Re: [CIRCLE] Sorry about where can I get this MUD.
>Date: Sat, 19 Feb 2000 02:40:33 -0800
>
>Patrick Dughi wrote:
> >
> > > Hrmmm, an interesting idea might be to set up your own login and
> > > restricted shell inside the shell you are given, a moderate amount of
> > > perl scripting would probably be needed for this and you could assign
> > > all your programers user names and maintain a database with encrypted
> > > passwords, then they have to do a double-login, first they telnet (or
> > > ssh) to the shell account and then the .bash_profile will launch a
> > > secondary login/authentication with thier assigned username/passwd
>which
> > > then gives them access to a restricted shell that you control, you can
> > > maintain filelists for each programmer to only allow them access to
> > > ceartain files, and do a host of other things to limit them
> > > appropriately (use your imagination). You set it up so that you and
> > > your most trusted programmers will have access to the full shell also.
> >
> > This is a good idea; my first on this thread actually, but I
> > discounted it because of the lack of good control allowed. You could
> > start at the same problems net providers experience when they change
> > someone's login shell from a valid one to '/bin/false'. They still have
> > access, and if they're tenacioius, usually they can still use the
> > account/change it back. Trying to give them partial access would be
> > scary.
> >
>There is a security risk for any kind of access you give someone,
>however, I think it is safe to say that allowing a programmer full shell
>access is less secure than allowing access to a restricted shell. There
>will always be holes, but by restricting a programmer's access you are
>adding one more deterrent, and if you make it difficult enough for
>someone to break they may decide that it is simply easier to write thier
>own code than to gain access to yours.
> > >
> > > Another possibility would be to set it up to allow a limited amount of
> > > programming from within the MUD itself, you could use a modified form
>of
> > > the tedit and file (patch/snippet?) along with copyover and then write
>a
> > > simple command to run ./configure and make from inside the MUD.
> > >
> > Good idea, but same problems. Though I did want to have it so I
> > could shell out from within the mud, it was for reasons other than
> > security. I was just curious how much could be done using the mud as an
> > access control + log generator. It'd be nice for management reasons.
>
>Well, I do have to admit that this one poses ceartain greater security
>risks, when you open up a method to allow access to from within the MUD,
>then any player has the potential of finding and exploiting a hole which
>gives them that access or a subset of it. This method is, therefore,
>more of a conveniance than for security and anytime you increase
>conveniance in a manner such as this you decrease your security as a
>result. It is a give and take as any conveniance on the internet is.
>
>Regards, Peter
>
>
----------------
Daniel Staudt <dstaudt@hotmail.com>
I'm out of my mind, but feel free to leave a message.
ICQ UIN# <14148959>
<http://www.geocities.com/ResearchTriangle/5404/>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT