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
+------------------------------------------------------------+
| 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