Mudlib security issues
Scatter ///oo/\)
What are the most common ways security is compromised in a mudlib? I've
abandoned the outdated uid/euid stuff and written a fully fledged security
handler in my mudlib and I want to make sure I've covered all the ways
"bad" creators can hack access to things they shouldn't have.
I'm fairly sure I've covered all bases, I've read through the description of the
security system in Lima and although mine takes a completely different
approach it does seem to protect as strongly as Lima's. (I've got a huge
"help" document at home describing how the system works, I won't post
it unless people really want to read it though.)
For example the sort of thing I'm after is...
* creator gives an object to an admin to override a command and
do something naughty
* creator overrides simul_efuns
* creator shadows an admin / handler (daemon)
Also any hints and tips people might have as to tightening security,
e.g. returning array/mapping variables via copy() to make sure the
caller doesn't get a pointer to the real data.
Thanks,
--
Dan
///\oo/\\\
Cameron Kaiser
sca...@thevortex.com (Scatter ///\oo/\\\) writes:
>For example the sort of thing I'm after is...
>* creator gives an object to an admin to override a command and
> do something naughty
>* creator overrides simul_efuns
>* creator shadows an admin / handler (daemon)
Look at the valid_*() handlers in master.c. Things I watch for whenever I
make a privileged object are:
a. can someone override it? if it's an sfun, does valid_override() in the
master object prevent overriding?
b. if this function is secure, is it 'private nomask'? If it has to be
called openly, is it checking the call stack (or at least previous_object())
to see who's precipitating the call?
c. can this object be inherited by something else and then its methods
overridden? (use 'nomask' -- sometimes 'static' -- for this)
d. are the objects that are allowed to call the object themselves secure?
e. if it returns anything by reference, like a mapping, is it returning a
copy or the actual object? (And are any copy ?funs like copy_mapping()
secure too?)
Things I never allow to occur are function calls with a null or zero euid/uid
and access direct to the master object (except by "secure" or "root" uid things
like simul_efun). If something like player.c wants to call valid_read(), it
has to use an sfun, which itself calls the master.
>Also any hints and tips people might have as to tightening security,
>e.g. returning array/mapping variables via copy() to make sure the
>caller doesn't get a pointer to the real data.
Hope this helps ...
Evergreen@Icewind
skaidi.hifm.no 2021
--
Cameron Kaiser
cdkaiser at concentric dot net (it hasn't helped the spam yet though)
*** visit the Spectre Server at www.sserv.com
*** C64 software lives! www.computerworkshops.home.ml.org
John Adelsberger
Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
: "help" document at home describing how the system works, I won't post
: it unless people really want to read it though.)
I want to read it.
: * creator gives an object to an admin to override a command and
: do something naughty
Note when considering this scenario that if I give you an object, you can
read the source for it, and I can then wait till you log out, modify the
source, and when you log in again, if you don't read the source, you lose.
: * creator overrides simul_efuns
This is a trivial problem.
: * creator shadows an admin / handler (daemon)
Just eliminate shadows from your driver. They are, were, and will be a
REALLY Bad Idea[tm]. No matter how many objects you protect from them,
there will be things people can do(especially in the area of social
engineering) that WILL compromise your security sooner or later.
: Also any hints and tips people might have as to tightening security,
: e.g. returning array/mapping variables via copy() to make sure the
: caller doesn't get a pointer to the real data.
This isn't a particularly good idea for anything but security data
itself... the overhead involved will suck, and you'll use memory
like it was going out of style. Moreover, nothing but security data
can really compromise your mudlib if your security system is designed
well. Sure, someone might muck up an array of titles for players of
a certain level in a certain guild or something, but thats not a
security problem - thats a 'delete a stupid wannabe hacker and move on'
problem.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
George Reese
Reinventing Lima security is NOT the way to do it. They got it right.
You should simply accept their security system.
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: What are the most common ways security is compromised in a mudlib? I've
: abandoned the outdated uid/euid stuff and written a fully fledged security
: handler in my mudlib and I want to make sure I've covered all the ways
: "bad" creators can hack access to things they shouldn't have.
: I'm fairly sure I've covered all bases, I've read through the description of the
: security system in Lima and although mine takes a completely different
: approach it does seem to protect as strongly as Lima's. (I've got a huge
: "help" document at home describing how the system works, I won't post
: it unless people really want to read it though.)
: For example the sort of thing I'm after is...
: * creator gives an object to an admin to override a command and
: do something naughty
: * creator overrides simul_efuns
: * creator shadows an admin / handler (daemon)
: Also any hints and tips people might have as to tightening security,
: e.g. returning array/mapping variables via copy() to make sure the
: caller doesn't get a pointer to the real data.
: Thanks,
: --
: Dan
: ///\oo/\\\
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
"In our fear, we make an image, and that image we call God."
Antonius Block in The Seventh Seal
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
Paul Miller
On 29 Jan 1998 14:38:21 GMT, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>What are the most common ways security is compromised in a mudlib?
>For example the sort of thing I'm after is...
>* creator gives an object to an admin to override a command and
> do something naughty
Ah, the beauties of add_action(). add_action() is the single worst thing ever to
happen to mud security, simply because there is no way to control via mudlib
code which add_action() gets called first. Since the last registered always
takes precedence, then we get some problems with say, add_action()'ing over rm.
>* creator overrides simul_efuns
I fail to see how this is a significant security breach. Any such override
would only be effective within the same object that did the overriding.
>* creator shadows an admin / handler (daemon)
Shadows are bad anyway. Just disallow them. :P
Let me see, off the top of my head:
* Say there exists a chain of wizards W, W_1, W_2, W_i ... W_n such that W_i's
objects have write access to W_i+1's directory and W_n's objects have global
write access. Then, it is generally possible for W_j (j<n) to code an object
that copies itself to W_j+1's directory, checks and sees if it has enough access
to do_something_nasty(), and if not, copies itself on to W_j+2's directory.
I do not believe there is any way around this, other than preventing such a
chain from existing. In order to do this, one would have to prevent anyone
whose objects have global write access from granting write access to anyone not
trusted, or to carefully regulate (or even disallow) writes to critical mudlib
areas such as the /secure and /lib directories. Writes to these directories
would then have to be acoomplished via FTP or local access.
Alternatively, one can separate objects' access rights from wizards' access
rights. This would mean that when this_player()/this_user()/this_interactive()
does not exist, then writes and reads to outside directories would not be
permitted. For example, an object in /players/foo would not be allowed to write
any file outside of /players/foo if this_player() did not exist.
* Creator codes an object which executes command() without a this_player() so
that it may not show up as a force. This could be accomplished via a call_out()
or something. It's amazing how little information call_out() preserves.
Probable ways around are to check previous_object() or previous_program()'s
instead of relying on this_player(1) or similar mechanisms to detect when a
command is forced.
* Creator attempts to do nasty stuff from an unbound lambda closure or function
pointer. I'm not sure if this is a real problem as probably most of this stuff
gets trapped by valid_bind() or similar mechanisms.
Lars Duning
Scatter ///oo/\) wrote:
> (I've got a huge
> "help" document at home describing how the system works, I won't post
> it unless people really want to read it though.)
Go ahead, post it. It would be completely on-topic for this newsgroup.[1]
> For example the sort of thing I'm after is...
>
> * creator gives an object to an admin to override a command and
> do something naughty
>
> * creator overrides simul_efuns
>
> * creator shadows an admin / handler (daemon)
Don't forget to guard the creation of virtual objects. On one mud it
still is possible to create a 'virtual mailbox' to read and write any
mailfile you want (couldn't happen with Ellery's system).
--
Lars Duening; la...@cableinet.co.uk
Lars Duning
I wrote:
> Don't forget to guard the creation of virtual objects. On one mud it
> still is possible to create a 'virtual mailbox' to read and write any
> mailfile you want (couldn't happen with Ellery's system).
I have to qualify that: this attack can be successful even when using
Ellery's security system, but it's quite easy to close the hole.
--
Lars Duening; la...@cableinet.co.uk
Tim Hollebeek
In article <6aq48t$lek$1...@news.uk.ibm.com>, sca...@thevortex.com writes:
> What are the most common ways security is compromised in a mudlib? I've
> abandoned the outdated uid/euid stuff and written a fully fledged security
> handler in my mudlib and I want to make sure I've covered all the ways
> "bad" creators can hack access to things they shouldn't have.
>
> I'm fairly sure I've covered all bases, I've read through the description of the
> security system in Lima and although mine takes a completely different
> approach it does seem to protect as strongly as Lima's. (I've got a huge
> "help" document at home describing how the system works, I won't post
> it unless people really want to read it though.)
>
> For example the sort of thing I'm after is...
>
> * creator gives an object to an admin to override a command and
> do something naughty
>
> * creator overrides simul_efuns
>
> * creator shadows an admin / handler (daemon)
one that lots of people miss is Foo edits fairly innocuous include
file x.h which is included by privileged object y.c to contain something
like:
#define this_player() (find_player("beek") ? destruct(find_player("beek")) : 0)
or
#define nomask
#define private
#define static
etc
---------------------------------------------------------------------------
Tim Hollebeek | "Everything above is a true
email: t...@wfn-shop.princeton.edu | statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim | false values of true."
Benjamin Goldberg
>
> * creator gives an object to an admin to override a command and
> do something naughty
>
LPMud3.2.1's set_modify_command() efun?
email me if I have no clue what I'm talking about :)
--
Ben Goldberg
John Adelsberger
George Reese <bo...@imaginary.com> wrote:
: Reinventing Lima security is NOT the way to do it. They got it right.
: You should simply accept their security system.
As usual, George has spoken. He's right about this much: the Lima way
is very, very, very good. However, any attempt in an area this complex
to argue that 'you should just accept' anything is so silly I'm surprised
even this doofus would post it...
Preach it, brother... the more absolutist foolishness you spout, the
fewer people will care.
Scatter ///oo/\
Cameron Kaiser intoned these words...
>Look at the valid_*() handlers in master.c. Things I watch for whenever I
>make a privileged object are:
>
>a. can someone override it? if it's an sfun, does valid_override() in the
>master object prevent overriding?
I think I've covered this by preventing anything other than /secure/simul_efun
from using "efun::".
>b. if this function is secure, is it 'private nomask'? If it has to be
>called openly, is it checking the call stack (or at least previous_object())
>to see who's precipitating the call?
Am I correct in thinking "private" means that call_other will not find
the function? As to nomask, I've set valid_shadow to prevent any objects
under /secure being shadowed.
>c. can this object be inherited by something else and then its methods
>overridden? (use 'nomask' -- sometimes 'static' -- for this)
Is there a way to check if something is being inherited? This is an
approach I hadn't thought of, but I think it's covered in that
the resulting object will only have the security rating of the object
that's doing the inheriting rather than that of the secure file.
>d. are the objects that are allowed to call the object themselves secure?
Covered.
>e. if it returns anything by reference, like a mapping, is it returning a
>copy or the actual object? (And are any copy ?funs like copy_mapping()
>secure too?)
Covered.
>Things I never allow to occur are function calls with a null or zero euid/uid
>and access direct to the master object (except by "secure" or "root" uid things
>like simul_efun). If something like player.c wants to call valid_read(), it
>has to use an sfun, which itself calls the master.
I'm not using the euid/uid system, I have a security handler which determines
what level of access an object has to anything. One of the teething troubles
I'm having is that the security handler is too pedantic and likes to
disallow /secure/master to do things like save players on crash() (the
default protection on player save files gave /secure/master only read
access).
>Hope this helps ...
Yup, and saved as a future checklist. :)
--
Scatter ///\oo/\\\
Scatter ///oo/\
John Adelsberger intoned these words...>: "help" document at home describing how the system works, I won't post
>: it unless people really want to read it though.)
I'll run off a shortened version to post, there's a lot I could trim
out (function details etc).
>: * creator gives an object to an admin to override a command and
>: do something naughty
>Note when considering this scenario that if I give you an object, you can
>read the source for it, and I can then wait till you log out, modify the
>source, and when you log in again, if you don't read the source, you lose.
That's a very good point! Following another discussion I'm probably going
to drop add_action which will make this possibility go away.
>: * creator overrides simul_efuns
>This is a trivial problem.
Yeah I was just picking some examples of the sort of things that
should be covered.
>: * creator shadows an admin / handler (daemon)
>Just eliminate shadows from your driver. They are, were, and will be a
>REALLY Bad Idea[tm]. No matter how many objects you protect from them,
>there will be things people can do(especially in the area of social
>engineering) that WILL compromise your security sooner or later.
Unfortunately I need shadows, so this isn't really an option. Does
everyone here despise them? However I can use valid_shadow to ensure
that trusted / secure objects and command objects can't be shadowed.
I also have code in the player object so that creators are warned when
something shadows them and by default shadowing creators is disallowed -
they want to be shadowed they have to explicitly turn it on.
>: Also any hints and tips people might have as to tightening security,
>: e.g. returning array/mapping variables via copy() to make sure the
>: caller doesn't get a pointer to the real data.
>This isn't a particularly good idea for anything but security data
>itself... the overhead involved will suck, and you'll use memory
>like it was going out of style. Moreover, nothing but security data
>can really compromise your mudlib if your security system is designed
>well.
Yes that was the sort of thing I had in mind - sensitive information such
as the mapping of security permissions. :)
--
Scatter ///\oo/\\\
Scatter ///oo/\
George Reese intoned these words...
>Reinventing Lima security is NOT the way to do it. They got it right.
>You should simply accept their security system.
Gee thanks for quoting 40 lines to add 2 completely unhelpful ones.
If you'd bothered to read what you quoted, you'd have seen that I haven't
reinvented Lima's system, simply checked that mine can cope with the
scenarios mentioned in the documentation of Lima's.
And no, I should not simply accept their system because I don't like the
"privileges" system it is based on and I'm not willing to accept the
copyright/credit/licensing agreements on use of Lima code.
--
Scatter ///\oo/\\\
John Adelsberger
Paul Miller (pmiller@*DIESPAMMERS*.lni.net) wrote:
:Ah, the beauties of add_action(). add_action() is the single worst thing ever
:to happen to mud security, simply because there is no way to control via mudlib
:code which add_action() gets called first. Since the last registered always
:takes precedence, then we get some problems with say, add_action()'ing over rm.
How about a simul of add_action? That would allow control, even though
add_action _is_ a piece of shit.
: I fail to see how this is a significant security breach. Any such override
: would only be effective within the same object that did the overriding.
Oh, well, hey, I suppose its no problem if I override your simul-efun
override of the efun that shuts down the mud. You won't mind, will you?
This is just the beginning...
: Probable ways around are to check previous_object() or previous_program()'s
: instead of relying on this_player(1) or similar mechanisms to detect when a
: command is forced.
If I want to force you to do something, the odds are I'm just being annoying,
and I can be annoying a million ways that don't require force. If your
security system is worth anything at all, it will stop forces of any
privileged command one way or another unless the forcer has the privelege,
whether or not it is detected as a force.
Consider that I can easily do something like:
exec foreach(object user in users()) destruct user;
And you'll quickly realize that nothing is going to stop someone who wants
to be annoying and is sufficiently creative. Override destruct? Ok,
I'll log you out. Override users() to exclude certain folks? Ok, I'll
use objects(). See?
Scatter ///oo/\
Paul Miller intoned these words...
>
>>* creator gives an object to an admin to override a command and
>> do something naughty
>
>happen to mud security, simply because there is no way to control via mudlib
>code which add_action() gets called first. Since the last registered always
>takes precedence, then we get some problems with say, add_action()'ing over rm.
Actually my implementation of add_action() means that the first registered
always gets checked first, and that add_action()s cannot override command
server commands which get checked before add_action()s are even looked at.
That said, I think I'm going to drop add_action anyway.
>>* creator shadows an admin / handler (daemon)
>Shadows are bad anyway. Just disallow them. :P
Phoeey, I need them for my magic system. :)
>Let me see, off the top of my head:
>* Say there exists a chain of wizards W, W_1, W_2, W_i ... W_n such that W_i's
>objects have write access to W_i+1's directory and W_n's objects have global
>write access. Then, it is generally possible for W_j (j<n) to code an object
>that copies itself to W_j+1's directory, checks and sees if it has enough access
>to do_something_nasty(), and if not, copies itself on to W_j+2's directory.
>
>I do not believe there is any way around this, other than preventing such a
>chain from existing.
I'm not sure if my system would cope with this or not. I think it would,
because the object's security access would be determined by the player
who originally cloned it, or who caused it to do whatever it is it's
doing - i.e. this_player(1) is used if it exists. Only if this_player(1)
wasn't valid would the object's access be determined by it's directory.
>In order to do this, one would have to prevent anyone
>whose objects have global write access from granting write access to anyone not
>trusted, or to carefully regulate (or even disallow) writes to critical mudlib
>areas such as the /secure and /lib directories. Writes to these directories
>would then have to be acoomplished via FTP or local access.
I've disallowed write access to /secure et al from any object which does
not rate "as secure as the security handler" - which is pretty difficult
(I hesitate to say impossible) to achieve unless you're already
inside /secure.
>* Creator codes an object which executes command() without a this_player() so
>that it may not show up as a force. This could be accomplished via a call_out()
>or something. It's amazing how little information call_out() preserves.
Since I'm not using MudOS add_action handling, command() in my mudlib is a
simul_efun that calls this_player()->process_command() - hence no this_player()
no call. Plus I have MudOS compiled so that this_player() is valid in
call_out()s. :)
>* Creator attempts to do nasty stuff from an unbound lambda closure or function
>pointer.
You lost me there... what is a lambda closure?
>I'm not sure if this is a real problem as probably most of this stuff
>gets trapped by valid_bind() or similar mechanisms.
My master object's valid_bind() simply returns 0, so I guess this would
not be a problem. :)
Thanks for the tips,
--
Scatter ///\oo/\\\
Scatter ///oo/\
Lars Duning intoned these words...
>Scatter ///oo/\) wrote:
>> (I've got a huge
>> it unless people really want to read it though.)
I'm not entirely sure if that's sarcasm...? I'll make a shortened version
of the doc for posting.
>> For example the sort of thing I'm after is...
>> * creator shadows an admin / handler (daemon)
>
>Don't forget to guard the creation of virtual objects. On one mud it
>still is possible to create a 'virtual mailbox' to read and write any
>mailfile you want (couldn't happen with Ellery's system).
So far I don't have virtual objects.
--
Scatter ///\oo/\\\
Scatter ///oo/\
Tim Hollebeek intoned these words...
>
>file x.h which is included by privileged object y.c to contain something
>like:
This was one of the tips I picked up from the Lima documentation. I've
made sure nothing in /secure includes or inherits anything from outside
of /secure.
>#define nomask
>#define private
>#define static
Now those are _nasty_ - I wouldn't have thought of that myself.
--
Scatter ///\oo/\\\
Cameron Kaiser
Scatter ///\oo/\\\ <sca...@thevortex.com> writes:
>>a. can someone override it? if it's an sfun, does valid_override() in the
>>master object prevent overriding?
>I think I've covered this by preventing anything other than /secure/simul_efun
>from using "efun::".
That should take care of it. :-)
>>b. if this function is secure, is it 'private nomask'? If it has to be
>>called openly, is it checking the call stack (or at least previous_object())
>>to see who's precipitating the call?
>Am I correct in thinking "private" means that call_other will not find
>the function? As to nomask, I've set valid_shadow to prevent any objects
>under /secure being shadowed.
Actually, dump shadows altogether. They're no longer needed in this day and
age, and were an ugly hack to begin with. Probably they'll become officially
depreciated one of these days.
You are correct in your assumption. 'private' means only this object may call
that function. This is NOT the same as this_object() making the call (IOW,
undefinedp(this_object()->private_function()) returns true, given that
private_function has been declared private). Not declaring 'private' is
implicitly declaring 'public', as you would expect.
>>c. can this object be inherited by something else and then its methods
>>overridden? (use 'nomask' -- sometimes 'static' -- for this)
>Is there a way to check if something is being inherited? This is an
>approach I hadn't thought of, but I think it's covered in that
>the resulting object will only have the security rating of the object
>that's doing the inheriting rather than that of the secure file.
That sounds sufficient, but make sure that the functions are 'nomask'ed
anyway. If you really need to know if the object is being inherited, a
simple dirty method is to (explode("#", file_name(this_object())))[0] and
see if it's what you expect. There's probably a better way, but I use this with
0.9.19 and it seems to work acceptably well.
>I'm not using the euid/uid system, I have a security handler which determines
>what level of access an object has to anything. One of the teething troubles
>I'm having is that the security handler is too pedantic and likes to
>disallow /secure/master to do things like save players on crash() (the
>default protection on player save files gave /secure/master only read
>access).
Why not put the security handler in /secure/master? That's what it's there for.
Instead of having an outside object and letting /secure/master's access to
it be moderated by the outside handler, let /secure/master do the work. It's
faster and less convoluted. Unless, you have a *good* reason. :-)
>Yup, and saved as a future checklist. :)
Ah, posterity. :-)
John Adelsberger
Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
: Unfortunately I need shadows, so this isn't really an option. Does
: everyone here despise them? However I can use valid_shadow to ensure
: that trusted / secure objects and command objects can't be shadowed.
Implement a hooks system instead. Look at Lima for a nice clean example
of how it's done; lots of libs have them, but few do them cleanly
enough to be worth emulating the example of. Nobody ever needs shadows.
They might be a teeny bit faster than hooks, but if thats a problem,
LPC->C and some strange design will probably solve it, and it isn't
likely to be an issue anyway. A well designed hooks system is nigh
on impossible to abuse(but I do mean -well- designed.)
John Adelsberger
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: I'm not using the euid/uid system, I have a security handler which determines
: what level of access an object has to anything. One of the teething troubles
: I'm having is that the security handler is too pedantic and likes to
: disallow /secure/master to do things like save players on crash() (the
: default protection on player save files gave /secure/master only read
: access).
Why bother limiting what /secure/* can do? Just don't let anyone else into
the directory at ALL, and make your life simple. All that should be in
there are the master, simul_efun, security, and maybe a smart logging object.
Lots of muds use the secure dir to hide their access control obs, login obs,
and so forth, but this is because their security bites ass and they know it.
John Adelsberger
Cameron Kaiser <cdka...@delete.these.four.words.concentric.net> wrote:
: Why not put the security handler in /secure/master? That's what it's there for.
: Instead of having an outside object and letting /secure/master's access to
: it be moderated by the outside handler, let /secure/master do the work. It's
: faster and less convoluted. Unless, you have a *good* reason. :-)
Object size. The master object probably already has dozens of functions
in it, some of which are likely to be large. Better just to separate out
the security stuff in something like /secure/security. Speed is no issue,
readability is, and one can easily allow /secure/* worldwide access with
no problems.
John Adelsberger
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: >Shadows are bad anyway. Just disallow them. :P
: Phoeey, I need them for my magic system. :)
No, you don't. Hooks would work better.
: I'm not sure if my system would cope with this or not. I think it would,
: because the object's security access would be determined by the player
: who originally cloned it, or who caused it to do whatever it is it's
: doing - i.e. this_player(1) is used if it exists. Only if this_player(1)
: wasn't valid would the object's access be determined by it's directory.
Careful then - look at this:
'call_out("/some/sensitive/directory/that/can/write/all/over/object", 0);'
Will, on many muds, leave this_player undefined. You can compile your way
around this. If you do, make sure driver applies never call untrusted code.
Tim Hollebeek
Paul Miller wrote:
>
> >* creator shadows an admin / handler (daemon)
>
>
>
> * Say there exists a chain of wizards W, W_1, W_2, W_i ... W_n such that W_i's
> objects have write access to W_i+1's directory and W_n's objects have global
> write access. Then, it is generally possible for W_j (j<n) to code an object
> that copies itself to W_j+1's directory, checks and sees if it has enough access
> to do_something_nasty(), and if not, copies itself on to W_j+2's directory.
>
> I do not believe there is any way around this, other than preventing such a
> chain from existing.
Two important notes:
(1) having all a wizard's files have their full privileges (i.e. global
privs if they are an admin) is a stupid 2.4.5ism. On a sane MUD,
objects in /wiz/beek have as many privs as those of any other wiz.
If I want an object with more privs, I put it in a secure dir that
I have write access to.
(2) Ellery's SECURE_D will warn you if you do something that creates
such a chain.
> rights. This would mean that when this_player()/this_user()/this_interactive()
> does not exist, then writes and reads to outside directories would not be
> permitted.
Here is your biggest problem. If your security system trusts
this_player() *AT ALL*, then your security is swiss cheese,
trivially breakable, and worrying about any other security
concerns is a complete waste of time.
-Beek
Tim Hollebeek
Benjamin Goldberg wrote:
>
> In article <6aq48t$lek$1...@news.uk.ibm.com>, sca...@thevortex.com writes:
> >
> > * creator gives an object to an admin to override a command and
> > do something naughty
> >
> LPMud3.2.1's set_modify_command() efun?
>
> email me if I have no clue what I'm talking about :)
Corresponds to the process_input() apply, unless my memory of
3.2.1 is finally disappearing after all these years.
-Beek
Tim Hollebeek
John Adelsberger wrote:
>
> Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>
> : >Shadows are bad anyway. Just disallow them. :P
>
> : Phoeey, I need them for my magic system. :)
>
> No, you don't. Hooks would work better.
>
> : I'm not sure if my system would cope with this or not. I think it would,
> : because the object's security access would be determined by the player
> : who originally cloned it, or who caused it to do whatever it is it's
> : doing - i.e. this_player(1) is used if it exists. Only if this_player(1)
> : wasn't valid would the object's access be determined by it's directory.
>
> Careful then - look at this:
>
> 'call_out("/some/sensitive/directory/that/can/write/all/over/object", 0);'
>
> Will, on many muds, leave this_player undefined. You can compile your way
> around this. If you do, make sure driver applies never call untrusted code.
Ahem. man call_out and look at what the first arg is. :-)
Your point is valid, though this is one of the easier this_player()
related problems to solve. Of course, ignoring this_player() completely
and using a better security system is a better solution since it
also closes the other 1000000000 this_player() related holes.
-Beek
Bob Farmer
In article <34D51A53...@wfn-shop.princeton.edu>,
Tim Hollebeek <t...@wfn-shop.princeton.edu> wrote:
[...quoted material removed...]
>Two important notes:
>
>(1) having all a wizard's files have their full privileges (i.e. global
>privs if they are an admin) is a stupid 2.4.5ism. On a sane MUD,
>objects in /wiz/beek have as many privs as those of any other wiz.
>If I want an object with more privs, I put it in a secure dir that
>I have write access to.
Actually, in 2.4.5 (the lib at least; although I think elements of this
may have been hardcoded into the driver as well), all permissions were
based on this_player(), not the filenames of objects. What you're
talking about mostly came about in the 3.x era I believe.
>(2) Ellery's SECURE_D will warn you if you do something that creates
>such a chain.
>
>> rights. This would mean that when this_player()/this_user()/this_interactive()
>> does not exist, then writes and reads to outside directories would not be
>> permitted.
>
>Here is your biggest problem. If your security system trusts
>this_player() *AT ALL*, then your security is swiss cheese,
>trivially breakable, and worrying about any other security
>concerns is a complete waste of time.
Definitely.
--
Bob Farmer ucs...@unx1.shsu.edu
University Computer Services, Sam Houston State Univ. (409)294-3547
Bob Farmer
In article <34D51E4D...@wfn-shop.princeton.edu>,
call_out() preserves this_player() normally. Does MudOS not do that
anymore? Anyhow, heart_beat() would have been the best example...
George Reese
Reinventing the wheel gets you nothing. The Lima security system is
based on ideas that have been documented by Ellery. I am not
suggesting you need to use their code. I am saying writing a new
security system is a waste of time.
Unless you can point out a problem with it.
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: George Reese intoned these words...
: --
: Scatter ///\oo/\\\
--
Threshold RPG
In article <6ar73k$2g1$2...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
>Reinventing Lima security is NOT the way to do it. They got it right.
>You should simply accept their security system.
George, why did you post this?
LIMA security kicks ass- that is true. However, are you insisting that there
is NO WAY *anyone* else could do it better or just as well?
Surely you can see how absurd that statement is. I would guess you were just
exaggerating a bit to make the point that LIMA's security is very good.
Furthermore, what if this guy is writing a mudlib that he wants to run a
commercial game on? If that is the case, its pretty obvious he cant take
LIMA's security system.
-Aristotle@Threshold
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, rich, detailed roleplaying environment.
http://www.threshold.counseltech.com
telnet://threshold.counseltech.com:23
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Threshold RPG
In article <6b3d30$f3s$1...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>: George Reese intoned these words...
>:>You should simply accept their security system.
>
>
>: "privileges" system it is based on and I'm not willing to accept the
>: copyright/credit/licensing agreements on use of Lima code.
>
>based on ideas that have been documented by Ellery. I am not
>suggesting you need to use their code. I am saying writing a new
>security system is a waste of time.
>
>Unless you can point out a problem with it.
George, I think he pointed out a major problem with it. He is not willing to
accept their licensing agreements. Thats pretty much all it takes to decide he
needs to do something different.
Lars Duening
<Scatter> wrote:
> Lars Duning intoned these words...
> >Scatter ///oo/\) wrote:
> >> (I've got a huge
> >> "help" document at home describing how the system works, I won't post
> >> it unless people really want to read it though.)
> >Go ahead, post it. It would be completely on-topic for this newsgroup.[1]
No, I really mean it.
--
Lars Duening; la...@cableinet.co.uk
George Reese
Threshold RPG <thre...@counseltech.com> wrote:
: In article <6b3d30$f3s$1...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
:>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
:>: George Reese intoned these words...
:>:>Reinventing Lima security is NOT the way to do it. They got it right.
:>:>You should simply accept their security system.
:>
:>: Gee thanks for quoting 40 lines to add 2 completely unhelpful ones.
:>
:>: And no, I should not simply accept their system because I don't like the
:>: "privileges" system it is based on and I'm not willing to accept the
:>: copyright/credit/licensing agreements on use of Lima code.
:>
:>Reinventing the wheel gets you nothing. The Lima security system is
:>based on ideas that have been documented by Ellery. I am not
:>suggesting you need to use their code. I am saying writing a new
:>security system is a waste of time.
:>
:>Unless you can point out a problem with it.
: George, I think he pointed out a major problem with it. He is not willing to
: accept their licensing agreements. Thats pretty much all it takes to decide he
: needs to do something different.
There is no licensing agreement with stack based security. Otherwise
Nightmare and Foundation would not have stack based security. Their
license only applies to their code.
George Reese
Threshold RPG <thre...@counseltech.com> wrote:
: In article <6ar73k$2g1$2...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
:>Reinventing Lima security is NOT the way to do it. They got it right.
:>You should simply accept their security system.
: George, why did you post this?
: LIMA security kicks ass- that is true. However, are you insisting that there
: is NO WAY *anyone* else could do it better or just as well?
: Surely you can see how absurd that statement is. I would guess you were just
: exaggerating a bit to make the point that LIMA's security is very good.
: Furthermore, what if this guy is writing a mudlib that he wants to run a
: commercial game on? If that is the case, its pretty obvious he cant take
: LIMA's security system.
First, to do better, you have to identify a problem with what exists
now. I am not making the claim that no one could ever do better. I
am saying that if he has not even identified a problem with the
existing system, then it is foolishness to come up with one of his
own.
With respect to licensing, licensing has nothing to do with the
system, just their implementation of it.
Scatter ///oo/\)
In <6b0kkp$9...@examiner.concentric.net>, Cameron Kaiser <cdka...@delete.these.four.words.concentric.net> writes:
>Scatter ///\oo/\\\ <sca...@thevortex.com> writes:
>
>>>b. if this function is secure, is it 'private nomask'?
>>the function? As to nomask, I've set valid_shadow to prevent any objects
>>under /secure being shadowed.
>Actually, dump shadows altogether.
Looking into it. I spent the weekend putting together a "hooks" system as
someone else suggested to use instead of shadows, but as yet I'm not convinced
it's as easy to use, flexible and fast as shadows are.
>They're no longer needed in this day and age, and were an ugly hack
>to begin with. Probably they'll become officially depreciated one of these days.
I think MudOS already has an option to turn them off which is usually a sign
something has fallen out of favour. :)
>You are correct in your assumption. 'private' means only this object may call
>that function. This is NOT the same as this_object() making the call (IOW,
>undefinedp(this_object()->private_function()) returns true, given that
>private_function has been declared private). Not declaring 'private' is
>implicitly declaring 'public', as you would expect.
Thinking about it, without shadows there is no real reason an object should
call this_object()->blah() is there? It would be faster simply to call blah()
direct.
>>Is there a way to check if something is being inherited?
> If you really need to know if the object is being inherited, a
>simple dirty method is to (explode("#", file_name(this_object())))[0] and
>see if it's what you expect. There's probably a better way, but I use this with
>0.9.19 and it seems to work acceptably well.
I meant to experiment on ways to do this but didn't get round to it. I already
have clonep() checks in create() to make sure that handlers don't get cloned
and was wondering if this would also prevent them being inherited. Failing
that I think there's an inherit_list efun of some description. Still the filename
method is quick and dirty and probably unfoolable unless someone manages
to work a # into a real filename. (Probably possible, I've accidently created
files in a mud with spaces in the name - tricky to get rid of under unix!)
>>I'm not using the euid/uid system, I have a security handler which determines
>>what level of access an object has to anything. One of the teething troubles
>>I'm having is that the security handler is too pedantic and likes to
>>disallow /secure/master to do things like save players on crash() (the
>Why not put the security handler in /secure/master? That's what it's there for.
Because the way it was built and tested continuously meant that it was initially
being developed with /secure/master running the old uid system and it's
much easier to edit and update a seperate object than /secure/master. Especially
considering that at the time I was working on a 4Mb Atari which took around
5 minutes to start up the mud. :)
>Instead of having an outside object and letting /secure/master's access to
>it be moderated by the outside handler, let /secure/master do the work. It's
>faster and less convoluted. Unless, you have a *good* reason. :-)
I don't think it's work the effort to merge it into /secure/master at the moment.
Of course it's entirely possible that /secure/master could inherit it with a few
trivial changes.
--
Dan
///\oo/\\\
Scatter ///oo/\)
In <34d3e...@news.cc.umr.edu>, j...@ultra3.cc.umr.edu (John Adelsberger) writes:
>Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
>
>: Unfortunately I need shadows, so this isn't really an option. Does
>: everyone here despise them? However I can use valid_shadow to ensure
>: that trusted / secure objects and command objects can't be shadowed.
>
>Implement a hooks system instead. Look at Lima for a nice clean example
>of how it's done; lots of libs have them, but few do them cleanly
>enough to be worth emulating the example of. Nobody ever needs shadows.
>They might be a teeny bit faster than hooks, but if thats a problem,
>LPC->C and some strange design will probably solve it, and it isn't
>likely to be an issue anyway. A well designed hooks system is nigh
>on impossible to abuse(but I do mean -well- designed.)
I had a go at a hooks system this afternoon. The general idea is each object
would have a mapping of ([ string function_name : function *hook_to_call ])
along with a query function returning a list of functions that could be hooked
in this way.
As yet I haven't tested it much, but it looks like there will be some extra
overhead as each function that can be hooked will need to check for hooks
i.e. if( hook_exists( "my_function_name" ) )
return call_hooks( "my_function_name"); )
This adds that little bit extra processing time to every query_ you need to
be able to hook - though I'm not sure how significant that will prove.
The other difficulty is emulating the ability of shadows to get the unmodified
response to a function and alter it before returning it - that is to say if
a shadow is shadowing a victim and someone calls victim->blah() then
the shadow can call victim->blah() and get the "real" response and then
alter it.
I think the system I've used to let a hook function call the next hook in
the list will work, but the whole thing seems much more clumsy than
a simple shadow.
The other problem I have is finding documentation of how MudOS handles
"..." type definitions, as in void blah( int a, ... ) - does anyone know how
this works in LPC?
--
Dan
///\oo/\\\
Scatter ///oo/\)
In <34d4d...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>
>: I'm not using the euid/uid system, I have a security handler which determines
>: what level of access an object has to anything. One of the teething troubles
>: I'm having is that the security handler is too pedantic and likes to
>: disallow /secure/master to do things like save players on crash() (the
>: access).
>Why bother limiting what /secure/* can do? Just don't let anyone else into
>the directory at ALL, and make your life simple.
It wasn't a case of explicitly limiting what secure objects can do - rather it
was a case of not explicitly letting them do anything. :)
>All that should be in
>there are the master, simul_efun, security, and maybe a smart logging object.
>Lots of muds use the secure dir to hide their access control obs, login obs,
>and so forth, but this is because their security bites ass and they know it.
I have some other objects in there at present because they need to be
as secure as the security system. The security system is sufficiently strict
that if the default access to "/log" for example is read only then the security
handler will not allow a player triggered action to write something to the
/log directory. Hence there needs to be a class of objects that can bypass
part of the normal security check. I have a safe() call that allows this -
the only objects that are permitted to call safe() are "secure" objects. The
easiest way to make sure they are as secure as the security handler is
to put them in /secure...
Hence logging is in there, and also things like the message board handler
(which needs to able to manipulate message files at the request of a player
without that player having write access to them), the mail handler etc.
--
Dan
///\oo/\\\
Scatter ///oo/\)
In <34d4d...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>
>: Phoeey, I need them for my magic system. :)
>No, you don't. Hooks would work better.
I'm looking into that as I posted elsewhere.
>: I'm not sure if my system would cope with this or not. I think it would,
>: because the object's security access would be determined by the player
>: who originally cloned it, or who caused it to do whatever it is it's
>: doing - i.e. this_player(1) is used if it exists. Only if this_player(1)
>: wasn't valid would the object's access be determined by it's directory.
>
>Careful then - look at this:
>'call_out("/some/sensitive/directory/that/can/write/all/over/object", 0);'
>
>Will, on many muds, leave this_player undefined. You can compile your way
>around this. If you do, make sure driver applies never call untrusted code.
I do have MudOS compiled so that this_player() is defined in call_out()s - I've
been used to a mud where this was the case and found it too useful to leave
out.
As I said, if this_player(1) isn't valid for whatever reason then the object's
directory is used - but that doesn't mean that /w/foo/object.c gets the
access level of Lord Foo. Rather it gets the access level that "/w/foo" has
been granted - since it would be incredibly rare to specifically grant access
to a user directory, this will usually end up as the default access level to
whatever it was trying to access.
This might make more sense when I post my description of the system - I'll
try and get that done tonight.
--
Dan
///\oo/\\\
Scatter ///oo/\)
In <6b3m00$163$1...@usenet88.supernews.com>, thre...@counseltech.com (Threshold RPG) writes:
>In article <6ar73k$2g1$2...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
>>Reinventing Lima security is NOT the way to do it. They got it right.
>>You should simply accept their security system.
>
>is NO WAY *anyone* else could do it better or just as well?
I'm hoping it's just as good, it's certainly based on similar principles (check
all objects in the chain of the call etc). However for my purposes it doesn't
have to be 100% as good or better than Lima - it just has to be good
enough for my purposes, and work in way I find intuitive.
>Furthermore, what if this guy is writing a mudlib that he wants to run a
>commercial game on? If that is the case, its pretty obvious he cant take
>LIMA's security system.
I think (I may be wrong) that if that was the case I wouldn't be able to
use MudOS either.
What I am trying to do is write a mudlib that does what I want it to do in
the way that I want it to work. I don't want to accept other peoples
design decisions or arbitrary restrictions that say you must work this way,
you must do this or that, you must not edit any headers in this file etc. :)
Mostly this is an exercise because I enjoy coding, I like the LPC language
and I like muds. I have to admit I have my doubts that I'll get as far
as finding a host site and opening for players etc - certainly that's a long
way in the future from it's current state.
With that in mind, it's more important to me that it works the way I want it
to and a way that I understand than it is that everything is 100% the best
way it could possibly be done.
--
Dan
///\oo/\\\
Scatter ///oo/\)
In <6b4l51$nj9$3...@darla.visi.com>, George Reese <bo...@imaginary.com> writes:
>: In article <6b3d30$f3s$1...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
>:>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>:>: George Reese intoned these words...
>:>:>You should simply accept their security system.
>:>: And no, I should not simply accept their system because I don't like the
>:>: "privileges" system it is based on and I'm not willing to accept the
>:>: copyright/credit/licensing agreements on use of Lima code.
>:>
>Nightmare and Foundation would not have stack based security. Their
>license only applies to their code.
I misunderstood your statement that I "should simply accept" Lima's system
to mean that I should use Lima's implementation of security. This does
have copyright & usage restrictions.
I'll post the description of my system tonight - assuming by "stack based"
you mean checking security/access of each object in the all_previous_objects()
trace, then yes - my system is stack based. To put it in a nut shell, it
must satisfy itself that all objects in the chain are trustworthy - if not it
refuses the desired access. If they were all trusted then it determines what
level access the originating object has (usually this will correspond to
this_player(1), but thinking about it I don't think it actually checks this_player(1)
- apologies if I have mislead on that point in previous posts) and will then
allow or refuse access depending on the permission that has been granted
to that object.
The only exception to this is a safe() call (which is similar to the way
Lima's unguarded() call works I think) which enables secure objects to
bypass some of the objects in the chain.
Anyway, I'll post the detail tonight and you can see for yourself.
--
Dan
///\oo/\\\
Tim Hollebeek
In article <34d3e...@news.cc.umr.edu>, j...@ultra3.cc.umr.edu writes:
> Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
>
> : Unfortunately I need shadows, so this isn't really an option. Does
> : everyone here despise them? However I can use valid_shadow to ensure
> : that trusted / secure objects and command objects can't be shadowed.
>
> Implement a hooks system instead. Look at Lima for a nice clean example
> of how it's done; lots of libs have them, but few do them cleanly
> enough to be worth emulating the example of.
Lima's remove_hook() has perverse semantics and shouldn't be emulated.
Instead, to help coders, a string "name" should be added, and kept, so
it can be used to remove the hook. E.g. I'd suggest modifying the
interface to be:
some_object->add_hook("remove", "end my spell", (: end_spell_func :));
some_object->remove_hook("remove", "end my spell");
Haven't gotten around to fixing that in the lib though.
-Beek
---------------------------------------------------------------------------
Tim Hollebeek | "Everything above is a true
email: t...@wfn-shop.princeton.edu | statement, for sufficiently
URL: http://wfn-shop.princeton.edu/~tim | false values of true."
Niilo Paasivirta
George Reese <bo...@imaginary.com> wrote:
>Reinventing the wheel gets you nothing. The Lima security system is
>based on ideas that have been documented by Ellery. I am not
>suggesting you need to use their code. I am saying writing a new
>security system is a waste of time.
>Unless you can point out a problem with it.
I can point out a slight problem with security systems: no security
system in any LPmud is ever safe against a coder.
The security system I use is that I only take coders that I really
can trust.
I do have a security system which does check everything one can
imagine, previous_object chains and all, and I have administrated
(and hacked) muds for years...but I think it is all a waste of
time. I'll rather trust linux to do the security.
--
<a href="http://www.jyu.fi/%7Enp/index.html"> Niilo Paasivirta </a>
Stig Hemmer
sca...@thevortex.com (Scatter ///\oo/\\\) writes:
> Looking into it. I spent the weekend putting together a "hooks"
> system as someone else suggested to use instead of shadows, but as
> yet I'm not convinced it's as easy to use, flexible and fast as
> shadows are.
While I don't know your hook system, a properly made hook system is
easy to use, flexible but not very fast.
Stig Hemmer.
Threshold RPG
In article <6b4l7t$nj9$4...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
>: Furthermore, what if this guy is writing a mudlib that he wants to run a
>: LIMA's security system.
>
>now. I am not making the claim that no one could ever do better. I
>am saying that if he has not even identified a problem with the
>existing system, then it is foolishness to come up with one of his
>own.
Why? Why in the HELL does he *HAVE* to use someone else's system.
Why do you feel that just because someone does something well, everyone else
is an IDIOT if they don't use it.
What if they guy just wants to have a mudlib that is TOTALLY of his own
design? Is that a problem? Does this represent a threat to you?
Furthermore, why does someone have to identify a problem with LIMA's security
before deciding to make their own. You act as if LIMA's system is the God of
all programs and nobody can even consider doing something else unless they
have first paid homage at the altar of LIMA security.
Scatter ///oo/\
[Note, apologies for any errors in the formatting below - the help
document is in a format which allows the help/man commands to reformat
it as appropriate for the users terminal. I think I've stripped all
the odd bits, colours etc, but you never know. Additionally this was
written before implementation and hence may not exactly match the
handler as it ended up - but there are only minor differences.]
Security handler
----------------
File: /secure/security.c
Profiles
--------
Almost all security aspects are covered by profiles. A profile consists of a
name, and a set of entries. The name uniquely identifies the profile. Each
entry associates a name with a permission, the name can be a user (creator)
name, an object file name, or a group name. The permission reflects what the
thing identified by the name is allowed to do within the profile.
There are two types of profile, file profiles and group profiles. Both are
handled in more or less the same way.
File profiles
--------------
Directories and files are be protected by file profiles. File profiles are
named for the full path of the file or directory they cover and thus always
start with a "/" character. A file profile will exist for each file or
directory needing protection.
Entries in a file profile allow or deny the thing named by the entry to do
various things within the file or directory. Entries may be made for individual
creators, for groups or for specific objects. There may also be an entry with
the name "default" which assigns a permission to anyone not covered by another
entry.
Valid permissions for file profiles are:
* NONE - Unable to read or write files, 'cd' to directories, this
level reflects no access whatsoever.
* READ - Can 'cd' to a directory, read and load files. This reflects
minimal access, things can be looked at but not changed.
* ALTER - Can 'cd' to the directory, read, load and change files, create
and delete subdirectories. This reflects "full" access, things
can be looked at and changed at will.
* CONTROL - Same full level of access to the file/directory the profile
represents, plus the user is allowed to add/remove entries
from the profile. This level allows the user complete control
over the file/directory itself, plus complete control over
who else can do things to it.
Note that a file profile that doesn't have an entry giving someone CONTROL
access will not be able to be altered from inside the MUD. This is a handy way
to make sensitive files completely invulnerable from inside the MUD, but means
the security handler (or its save file) must be editted externally and then the
MUD restarted to change the profile.
Group Profiles
---------------
A group profile has the same structure as a file profile, having a name and a
set of entries. In a group profile, the name represents a group of people and
may not start with a '/' character so that they can be easily distinguished
from file profiles.
Entries in a group profile again match a name to a permission. The name may be
an individual creator, the name of another group profile, or the filename of a
specific object. The permission represents the status or privilege of the
member within the group. Note - the security handler will not allow groups to
be connected to groups online. This is a security measure, since groups within
groups within groups can make it very difficult to trace where a user's access
comes from.
Valid permissions for group profiles are:
* MEMBER - A member of the group (no special access)
* CONNECT - A member of the group who can add and remove MEMBER
entries, effectively add and delete people from
this group - but able only to give MEMBER permission, and
unable to remove others with CONNECT permission.
* CONTROL - A member of the group with full access - i.e. can add / remove
entries with any permission.
A group with no CONNECT or CONTROL members can never have new members added or
old members deleted from inside the MUD. A group with CONNECT but no CONTROL
member can never change the CONNECT members.
If a group has an entry in the profile for another group, the entry applies to
all members of that other group.
Profile application
-------------------
Profiles are applied and checked on a "Most Specific First" basis. This means
that the profile or entry applying most accurately to something, with the least
number of steps is the one used to permit or forbid an action.
For example, if there are profiles for /foo and /foo/bar/thing.c then the /foo
profile would be used to protect /foo/blah.c and /foo/bar/thing.c profile for
/foo/bar/thing.c. Someone with ALTER access to the /foo profile could still be
barred from looking at /foo/bar/thing.c if the /foo/bar/thing.c profile gave
them NONE access.
Similarly when finding an entry within a profile to match a user, the most
direct entry is used. So if a profile for /foo/bar granted ALTER to group
"admin" and NONE to "joe" then Joe's access will be NONE, even if he is a
member of admin group.
Domains
-------
A domain is an example of a group. For example, a "home" domain would have a
profile called "home", with a set of entries comprising the domain members.
E.g. Mazrak and Krumbo might be ordinary members and have MEMBER permission on
"home". Meester might be a domain overseer and be given CONNECT permission,
allowing him to recruit and evict members. The domain Lord, Scatter, would have
an entry with CONTROL authority.
Some extra restrictions are placed on groups which represent domains by the
handler. A domain group may only have one Lord and therefore may only have one
person with CONTROL authority. Secondly, the domain group must be a MEMBER of a
group entitled "domains" - this enables the handler to distinguish between
domain groups and other groups.
A domain group will have a corresponding file profile to protect the domain
directory under /d - so a "home" domain as outlined above might mean a file
profile for "/d/home", granting a "default" permission of NONE to non-members,
and granting "READ" to the "home" group, and CONTROL to "scatter", the domain
Lord.
A domain may have only one CONTROL member, the Lord of a domain is defined as
the member with CONTROL. A member who is not a Lord may not be given CONTROL.
Only the Lord of Admin domain is permitted to transfer CONTROL permission from
one member of a domain to another, this is handled as a special case.
The security handler enforces these restricitions and ensures integrity of
these profiles. It also prevents direct manipulation of these groups, the
appropriate commands must be used.
Creator ranks
-------------
Creator ranks are represented by a set of groups, one for each rank. These
would be the "player", "apprentice", "junior", "creator", "overseer", "lord"
and "high lord" groups. A creator's rank is determined by which group (s)he is
named an explicit MEMBER of. The "lord" group has CONNECT membership of all
lower ranks to enable Lords to promote anyone freely. The "high lord"
group has CONNECT on the "lord" group. No group has any members with CONTROL
authority, the "high lord" group has no member with CONNECT authority. Each
rank group is named as a MEMBER of the rank below, this enables easy checking
for e.g. "creator or higher".
The security handler prevents direct manipulation of these groups. The
appropriate commands must be used.
Associated with a creator's rank is a number of grade points. The security
handler keeps track of how many grade points a creator has but will not
promote/demote creators based upon it. Manipulation of grade points is only
possible through the appropriate commands. Grade points (or award points)
are intended to be used as an "incentive" for contributing good code.
Clan membership (currently unimplemented)
---------------
Clans are represented by groups in almost the same way as domains. A group
"clans" will contain MEMBER entries for all existing clans, with a CONNECT
entry for "high lord" allowing new clans to be added, old ones to be removed.
Each clan group will have MEMBER entries for all members of the clan, and
CONTROL for the clan leader. The security handler will restrict all changes to
the clan groups so that they must come from the clan handler. The clan handler
will allow the clan leader (CONTROL) to nominate recruiters with CONNECT
permission or to switch leadership from himself to another, replacing his
CONTROL with MEMBER and the new leader from MEMBER or CONNECT to CONTROL. More
than one CONTROL member is not permitted in clan groups - this is enforced by
the clan handler, not the security handler.
Special groups
--------------
A number of "special" group profiles exist which are used to monitor and
control other profiles. Some have been mentioned above. The full list is:
* "domains" - all MEMBERs represent valid domain groups. "admin" is
a special domain, given CONNECT authority to create
new domains and remove defunct ones.
* "admin" - a special domain for managing the domain system.
* "ranks" - all MEMBERs represent rank groups. No CONNECT or CONTROL
members.
* "clans" - all MEMBERs represent clan groups. "high lord" clan is
given CONNECT authority to create new
clans and remove defunct ones.
* "spider" - a special clan for managing the clan system.
* "trusted" - all MEMBERs are directories or objects considered to be
trustworthy. A CONNECT entry also exists for "high lord".
The "secure" group is also a member.
* "secure" - all MEMBERs are directories or objects considered to be at
least as secure as the security handler.
Use of the "trusted" and "secure" groups is explained in detail below.
Basically the "trusted" group contains things like file commands (rm, cp, ls,
cd etc.) and important bits of mudlib and the "secure" group contains the
commands to control profiles.
This list is of groups considered special by the security handler. However
other security groups may be considered special by other objects, for example a
"banished" group may consist of banished players/creators and be considered as
special by the logon handler and associated commands.
Security checking
-----------------
Security checking is the process by which the security handler decides if an
object is allowed to do something or not. This process is quite complex in
order to ensure it cannot be spoofed. In simple terms the handler backtracks
the call made until the object that initiated the call, and then ensures that
that object has the required permission and that all objects the call passed
through are trustworthy.
A couple of examples to explain:
Suppose a creator, Mazrak, tries to delete a file "/w/snitch/error-log" which
falls under the profile "/w/snitch".
This might result in a chain like:
/obj/user/player : Mazrak (executes command "rm /w/snitch/error-log")
|
/global/handlers/command (command server, calls the command file )
|
/global/commands/creator/file/rm (call to rm() efun)
|
/secure/master (valid_write() call from MudOS)
|
/secure/security (called from master to check permission)
In this sequence the trace first locates the originator, Mazrak. As the object
is interactive, the object's query_name() is trusted (a basic requirement of
any user object!). If the "/w/snitch" profile gives Mazrack only READ or NONE
access then the request is failed immediately.
If Mazrack is granted ALTER or CONTROL, then the objects between Mazrack and
the security handler are checked.
The security handler and /secure/master are both members of the "secure" group,
and therefore can be trusted. The rm command and command server are both
members of the "trusted" group and so are also trusted. All objects are deemed
trustable, so the request is permitted.
Suppose Mazrak is an evil creator who wants the file deleted and only has READ
access. So he codes an object to do the delete and hands it to Snitch, hoping
Snitch will type the command to trigger the object and delete the file.
The chain now looks like:
/obj/user/player : Snitch (executes overridden command "smile")
|
/w/mazrak/trojan (Mazrak's object calls rm() efun)
|
/secure/master (valid_write() called by MudOS)
|
/secure/security (called by master)
The security handler traces back to Snitch, Snitch has CONTROL access over
"/w/snitch" so the objects between are checked. Again the security handler and
master object are members of "secure" and so are trusted. But
"/w/mazrak/trojan" is not a member of "secure" and not a member of "trusted"
and so is a suspect link in the chain. The "/w/snitch" profile doesn't contain
an explicit entry for "/w/mazrak/trojan" and the default is READ, so
"/w/mazrak/trojan" is assumed to have READ access. The security handler
therefore decides "/w/mazrak/trojan" cannot be trusted and the request
to delete is denied.
If Snitch wants to allow Mazrak's object to delete the file there are several
ways she can do it. She can add an entry to the "/w/snitch" profile granting
Mazrak ALTER access. Or she can add an entry granting "/w/mazrak/trojan" ALTER
access. Either of these would be sufficient for the security handler to trust
the object. Of course, adding the object to the "trusted" or "secure" groups
would also do it, but this would be very dangerous as it would allow Mazrak to
code anything and call it "/w/mazrak/trojan" and it would automatically be
considered trustworthy. So all Mazrak would then need to do is get an admin to
activate it and he can do almost anything he wants.
The "secure" group is more trustworthy than the "trusted" group. The latter
group is considered to be reliable with respect to operations upon things
external to the security handler only - this means actual file operations etc.
The "secure" group is considered to be trustworthy with respect to the profiles
themselves. Only objects in the "secure" group are considered trustworthy for
operations which modify security profiles. "secure" status should be assigned
with great caution therefore, ideally only to other objects under /secure.
This directory should be carefully protected with file profiles.
There is one more circumstance to be covered. Suppose something without access
to a directory needs to write something into it? For example, a creator ftp's a
file, the ftp handler needs to log the event in /log/ftp but obviously the
creator cannot be given ALTER access to this directory. The trace might be
expected to look like:
/obj/user/player : Mazrak (uploads a file via ftp)
|
/secure/ftpd (ftp server, calls log() simul_efun)
|
/secure/simul_efun (calls write_file() efun)
|
/secure/master (valid_write() called by MudOS)
|
/secure/security (security check called by master)
The sequence given above would fail this immediately as the initial trace would
locate Mazrak, whose access to /log is READ. The way around this is to prevent
the trace locating Mazrak, through use of the safe() call. Instead of using
write_file directly, log() simul_efun instead calls safe() in the security
handler, passing it the details of the write_file call. The trace turns out
like this:
/obj/user/player : Mazrak (uploads a file via ftp)
|
/secure/ftpd (ftp server, calls log() simul_efun)
|
/secure/simul_efun (calls safe( write_file, ... ) )
|
/secure/security (calls write_file efun)
|
/secure/master (valid_write() called by MudOS)
|
/secure/security (security check called by master)
As soon as the security handler spots itself further up the chain it ignores
all objects above it and allows the request. Only "secure" files are permitted
to call safe() so Mazrak wouldn't be able to delete that file in /w/snitch by
calling safe().
The safe() function should be used very carefully to ensure that it doesn't
become a huge security hole. A badly written log() simul_efun that calls safe()
for example, might permit almost any file to be written to.
This should illustrate why only "secure" files may call safe() - these files
are by definition as secure as the security handler, so the people who have
access to edit these files and put in a security hole can potentially code
holes in the security handler anyway.
However BEWARE of security holes arising from poor use of safe() in secure
files! As a general rule, no "secure" file should inherit or #include a file
that is not equally secure. For example, a secure file #including a file from
/open would be a not-very-secure file that anyone could add things too,
including calls to safe().
Misc. Notes
-----------
The highest risk is the CONTROL access. CONTROL is gained by creating a profile
or being granted it by another with CONTROL access. Granting a group CONTROL
access to another profile is risky, since that means everyone in that
group has CONTROL access to the profile and any person in that group with
CONTROL or CONNECT access to that group, can effectively grant anyone CONTROL
of your profile.
Thus the security handler will disallow CONTROL access being granted to groups
from within the mud. Similarly CONNECT can not be granted to a group from
within the mud. These can be done by editing the default profiles in
/secure/security.c and/or editing it's save file.
If a directory/file is not covered by any profile, access NONE is assumed. If a
"default" entry doesn't exist in a file profile, a default of NONE is assumed.
It is recommended that a profile exist for "/" with a default permission of
READ, and CONTROL granted to "high lord". This ensures that every file and
directory has this this fallback profile to rely on should it not be covered
by anything else.
[more examples snipped]
[API snipped]
-- END OF DOCUMENT --
I've trimmed quite a bit, but this is still quite long. I'm happy to answer
questions and/or try things out with the handler since I'd like it to be
as secure as possible. As I said above, the nitty-gritty details of this
documentation does not exactly match the handler as implemented in every
detail, one day I'll have time to go through and make them match.
Questions & comments welcome.
--
Scatter ///\oo/\\\
David W Serhienko
> Beek wrote:
[major snippage]
> (2) Ellery's SECURE_D will warn you if you do something that creates
> such a chain.
This is about the fourth time I have found a reference to Ellery's
SECURE_D
is this thread. Could I get more information about it? If it is as
good as
everyone says, and available, I'd like to know where to grab it and how
it
gets installed.
Anybody able to help me, my thanks in advance,
Tigycho
>
[minor snippage]
> -Beek
John Adelsberger
Tim Hollebeek (t...@wfn-shop.princeton.edu) wrote:
: Ahem. man call_out and look at what the first arg is. :-)
Hehe... I oughta put a copy of the docs up on campus here where I can
actually read them when I post:-)
: Your point is valid, though this is one of the easier this_player()
: related problems to solve. Of course, ignoring this_player() completely
: and using a better security system is a better solution since it
: also closes the other 1000000000 this_player() related holes.
Well, yes, but if I had to guess, the guy I was responding to probably
isn't interested in rewriting everything he's done, even if it WOULD
be a good idea:-)
John Adelsberger
George Reese (bo...@imaginary.com) wrote:
: Reinventing the wheel gets you nothing. The Lima security system is
: based on ideas that have been documented by Ellery. I am not
: suggesting you need to use their code. I am saying writing a new
: security system is a waste of time.
: Unless you can point out a problem with it.
Well, George, this is true, so why aren't you using the original ENIAC
computer architecture and Plan Kalkul as a language? Anyone using
anything else reinvented the wheel, dammit!
Moron...
John Adelsberger
Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
: Looking into it. I spent the weekend putting together a "hooks" system as
: someone else suggested to use instead of shadows, but as yet I'm not convinced
: it's as easy to use, flexible and fast as shadows are.
It _can_ be all of these, except possibly as fast, but the speed
differential should be insignificant. If you're worried about it, put
hooks in a base object and LPC->C that, but you shouldn't have to.
: I think MudOS already has an option to turn them off which is usually a sign
: something has fallen out of favour. :)
Not always, but usually. AFAIK, I'm the only one working seriously on a
new MudOS lib that doesn't use the MudOS containment stuff.
: Thinking about it, without shadows there is no real reason an object should
: call this_object()->blah() is there? It would be faster simply to call blah()
: direct.
Unless the function might be overridden by an inheritor and you want the
overridden version, you're right.
: I meant to experiment on ways to do this but didn't get round to it. I already
: have clonep() checks in create() to make sure that handlers don't get cloned
: and was wondering if this would also prevent them being inherited. Failing
IMHO, LPC could use a 'noinherit' declaration, but failing this, you can
rename all your create() functions to something like init() and then have
your standard include file contain something like:
create()
{
//check to see if we inherit a handler, if so, destruct(this_object());
init();
}
Which is really cheezeball, but ought to work... I'm not sure if load_object
gets implicitly called for demand-loaded objects(it should be, conceptually,
but that doesn't mean much...) but if it does, you could override it to
do your checks, which would be cleaner.
John Adelsberger
Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
: Lima's remove_hook() has perverse semantics and shouldn't be emulated.
: Instead, to help coders, a string "name" should be added, and kept, so
: it can be used to remove the hook. E.g. I'd suggest modifying the
: interface to be:
: some_object->add_hook("remove", "end my spell", (: end_spell_func :));
: some_object->remove_hook("remove", "end my spell");
I freely admit that I don't feel a big need myself for names, but then, I
also freely admit that I think computer architecture is an interesting
and entertaining subject, so this might be a good idea if many people
will have to work with hooks.
Then again, I wouldn't want anyone writing code that needed hooks if he
couldn't cope with the Lima implementation... that kind of failure
indicates to me that he doesn't know what he's doing.
John Adelsberger
Niilo Paasivirta (n...@kanto.cc.jyu.fi) wrote:
: I do have a security system which does check everything one can
: imagine, previous_object chains and all, and I have administrated
: (and hacked) muds for years...but I think it is all a waste of
: time. I'll rather trust linux to do the security.
What a bad idea... Linux is awesome, don't get me wrong, but to say there
are a FEW security problems with it is an understatement.
George Reese
You have come to some false conclusions. I will explain below.
Threshold RPG <thre...@counseltech.com> wrote:
: In article <6b4l7t$nj9$4...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
:>: Furthermore, what if this guy is writing a mudlib that he wants to run a
:>: commercial game on? If that is the case, its pretty obvious he cant take
:>: LIMA's security system.
:>
:>First, to do better, you have to identify a problem with what exists
:>now. I am not making the claim that no one could ever do better. I
:>am saying that if he has not even identified a problem with the
:>existing system, then it is foolishness to come up with one of his
:>own.
: Why? Why in the HELL does he *HAVE* to use someone else's system.
He does not. I never said he has to. I said it is foolishness to
create your own when a proven system already exists and you are not
solving a problem with that working system.
: Why do you feel that just because someone does something well, everyone else
: is an IDIOT if they don't use it.
I never called him an idiot. I said his endeavor was foolishness. I
do not, in fact, think he is an idiot or anything remotely resembling
an idiot. In fact, he has helped to start two threads which actually
have to do with LPMud coding. That is a good thing.
Nevertheless, reinventing the wheel is a bad thing. It requires time
that could otherwise be spent solving problems that have not been
solved. It is also error prone, as you have to go off and prove your
new square wheel will actually move things.
: What if they guy just wants to have a mudlib that is TOTALLY of his own
: design? Is that a problem? Does this represent a threat to you?
Where did the concept of a threat come into play? Does the fact that
you believe the acts of the 'Heaven's Gate' cult to be foolish mean
you are threatended by them (assuming, of course, you believe that
committing suicide under the impression that a UFO will cart you away
is foolish)?
Now, I am not equating redoing security with UFO hitchiking, but the
point is that my finding an act foolish does not mean I am threatened
by it.
: Furthermore, why does someone have to identify a problem with LIMA's security
: before deciding to make their own. You act as if LIMA's system is the God of
: all programs and nobody can even consider doing something else unless they
: have first paid homage at the altar of LIMA security.
The stack security system, to date, IS the god of all security
systems. As far as Lima in general goes, I don't know enough about it
to call it the god of all systems. But I know the theory under which
the security system was designed, and that system is good.
Cameron Kaiser
Stig Hemmer <st...@pvv.ntnu.no> writes:
>While I don't know your hook system, a properly made hook system is
>easy to use, flexible but not very fast.
Viking's hooks are the proof of this :-) unless Auronthas has been under the
hood again. But they're terribly sexy.
Evergreen@Icewind
skaidi.hifm.no 2021
--
Cameron Kaiser
cdkaiser at concentric dot net (it hasn't helped the spam yet though)
*** visit the Spectre Server at www.sserv.com
*** C64 software lives! www.computerworkshops.home.ml.org
Richard
j...@ultra2.cc.umr.edu (John Adelsberger) wrote:
# : Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
# : Thinking about it, without shadows there is no real reason an object should
# : call this_object()->blah() is there? It would be faster simply to call
blah()
# : direct.
# Unless the function might be overridden by an inheritor and you want the
# overridden version, you're right.
I was coding something just the other day, and when you over-ride something
in an inheritor the stand-alone blah() calls the top-most instance
of the function.
e.g. I had query_complete_weight() returning query_weight() in the
base object, in an inheriting object I had query_weight() returning
::query_weight() + 5 and when calling query_complete_weight() on the
object the + 5 result was returned.
Go figure :)
Piotr Banski
John Adelsberger (j...@ultra2.cc.umr.edu) wrote:
: George Reese (bo...@imaginary.com) wrote:
: : Reinventing the wheel gets you nothing. The Lima security system is
: : based on ideas that have been documented by Ellery. I am not
: : suggesting you need to use their code. I am saying writing a new
: : security system is a waste of time.
:
: : Unless you can point out a problem with it.
:
: Well, George, this is true, so why aren't you using the original ENIAC
: computer architecture and Plan Kalkul as a language? Anyone using
: anything else reinvented the wheel, dammit!
:
: Moron...
of sense when you flame or your posts will be treated as nothing but
idiotic blabbing, as I hear they are.
If you can't see a difference between his and yous context of
'reinventing the wheel' then you're more than a moron.
Piotr
Piotr Banski
: : call this_object()->blah() is there? It would be faster simply to call blah()
: : direct.
:
: Unless the function might be overridden by an inheritor and you want the
: overridden version, you're right.
You use :: for overridden versions, mister. The validity of
this_object()->blah() extends a bit farther than just shadows.
What if you use this call in A which is inherited by B which defines
blah() for the 1st time? Will blah() alone do the trick?
And apart from that, as far as I remember, this_object() in a shadow
doesn't point to the shadowed object. Guess what it points to..
: IMHO, LPC could use a 'noinherit' declaration, but failing this, you can
: rename all your create() functions to something like init() and then have
: your standard include file contain something like:
Sure, go ahead, rename create() to init(), lots of fun guaranteed. Then
rename it to clean_up(), for some more thrilling action.
You know, for a person who brags in these newsgroups about his programming
skills and then tries to sell this shit, or is building a mudlib and needs
driver docs to know the syntax of call_out (cf. your earlier post) as if
a bit of thinking wasn't enough for such a specific function even if you
forgot it, for a person who calls others morons freely not being able to
even reason coherently, you seem to me one fucking idiot. No wonder lots
of people have you killfiled, there;s enough crap around without your posts.
Live long and try to get a life some day,
Piotr
Piotr Banski
Richard (rm...@spudent.canterbury.ac.nz) wrote:
: I was coding something just the other day, and when you over-ride something
: in an inheritor the stand-alone blah() calls the top-most instance
: of the function.
:
: e.g. I had query_complete_weight() returning query_weight() in the
: base object, in an inheriting object I had query_weight() returning
: ::query_weight() + 5 and when calling query_complete_weight() on the
: object the + 5 result was returned.
:
: Go figure :)
evaluated query_weight(), as redefined by you. Isn't that the desired
result? :)
Piotr
Piotr Banski
Piotr Banski (ban...@indiana.edu) wrote:
: And apart from that, as far as I remember, this_object() in a shadow
P.
Felix A. Croes
George Reese wrote:
>[...]
> The stack security system, to date, IS the god of all security
> systems. As far as Lima in general goes, I don't know enough about it
> to call it the god of all systems. But I know the theory under which
> the security system was designed, and that system is good.
What is good about the stack-based security system is that Lima has a
non-
buggy implementation of it (bugs are by far the largest cause of
security
holes), and that it has been properly designed. It has several
weaknesses,
however.
The system offers 3 different types of security: wizard-level,
transparent,
and special.
Wizard-level security, for the majority of objects, amounts to: "if you
do
not use unguarded(), it will not work." Moreover, there is a security
hierarchy for wizard objects in Ellery's design which I consider to be a
mistake. There is no reason why a wizard's objects, as opposed to the
wizard
himself, should have file access outside of that wizard's directory,
other
than read access in publicly readable ones. My main criticism on this
level
is that the system is overly complex.
The transparent security involves a large amount of mudlib objects. To
obtain transparent security an object requires global access, which is a
big
weakness, because all of them are now in the class of objects which have
to
be checked for global security holes. Moreover, giving anyone write
access
to an object with transparent security now implies giving that person
global
access.
Special security is for objects which need global access for one reason
or
another. Since privileged functions in these objects frequently have to
be
called when there is an unprivileged object on the stack, unguarded()
has
to be used, and additional security checks are required. Stack-based
security here is of no use whatsoever.
I have one more criticism of the system as a whole: it mixes up file
access
security and call_other/command security. The two systems ought to be
distinct.
Regards,
Dworkin
Timothy Philip Vernum
Richard <rm...@spudent.canterbury.ac.nz> writes:
>j...@ultra2.cc.umr.edu (John Adelsberger) wrote:
># : Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
># : Thinking about it, without shadows there is no real reason an object should
># : call this_object()->blah() is there? It would be faster simply to call
>blah()
># : direct.
># Unless the function might be overridden by an inheritor and you want the
># overridden version, you're right.
>I was coding something just the other day, and when you over-ride something
>in an inheritor the stand-alone blah() calls the top-most instance
>of the function.
>e.g. I had query_complete_weight() returning query_weight() in the
> base object, in an inheriting object I had query_weight() returning
> ::query_weight() + 5 and when calling query_complete_weight() on the
> object the + 5 result was returned.
>Go figure :)
All functions in lpc are automatically "virtual" (in the C++ sense, not the
lpc use of the word)
Base objects calling foo() will call a refinition of the function is one exists.
I can't think of a way around that off-hand.
blah::foo() will work to explicitly call down the inherit chain, but I can't
think of a way to get foo() in this object, except to make it nomask.
Timothy Philip Vernum
ban...@indiana.edu (Piotr Banski) writes:
>John Adelsberger (j...@ultra2.cc.umr.edu) wrote:
>: Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
>: : Thinking about it, without shadows there is no real reason an object should
>: : call this_object()->blah() is there? It would be faster simply to call blah()
>: : direct.
>:
>: Unless the function might be overridden by an inheritor and you want the
>: overridden version, you're right.
>You use :: for overridden versions, mister. The validity of
>this_object()->blah() extends a bit farther than just shadows.
>What if you use this call in A which is inherited by B which defines
>blah() for the 1st time? Will blah() alone do the trick?
No, but you're better of creating an empty stub for blah() in this case
[ ie void blah() { } ]
However the this_object() method can work for multiple inheritance,
where C inherits A and B.
if A calls this_object()->blah()
and B has a function blah() then C will merge them nicely.
If you have A put a stub in in these circumstances then you will get multiple
definitions which can be a right royal pain...
>And apart from that, as far as I remember, this_object() in a shadow
>doesn't point to the shadowed object. Guess what it points to..
Well I don't have the docs myself, but I am 99% sure that it will call the
inherited function.
Don't think in C(++).
this_object() is a function returning an object reference.
-> is just a short hand way of doing a call_other()
so this_object()->blah() == call_other( ob, "blah" )
where ob happens to be this_object()
It will invoke the shadow, and is in fact (IIRC) the only way to do so from
inside the object.
>: IMHO, LPC could use a 'noinherit' declaration,
I cannot see a point to this.
Anyone who can read the source can just implement it themselves.
Since you can't do any object type checking in LPC anyway (unless you count
testing the inherit_list() ) inheritance doesn't really give
you much except convenience.
It might be nice to stop people inheritning of an object, but I can't really
see what it acheives.
Scatter ///oo/\)
In <6b6vh9$dcv$1...@flotsam.uits.indiana.edu>, ban...@indiana.edu (Piotr Banski) writes:
>John Adelsberger (j...@ultra2.cc.umr.edu) wrote:
>: Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
>: : Thinking about it, without shadows there is no real reason an object should
>: : call this_object()->blah() is there? It would be faster simply to call blah()
>: : direct.
>: Unless the function might be overridden by an inheritor and you want the
>: overridden version, you're right.
>You use :: for overridden versions, mister.
He meant if you want the overriding version rather than the overridden.
The point was that if object A defines blah() and object B inherits A and
overrides the definition, if a function in A calls blah() will it get the overriding
version of blah() from B? I think it does, but without trying it I don't
know for sure. I would expect it to.
>The validity of
>this_object()->blah() extends a bit farther than just shadows.
>What if you use this call in A which is inherited by B which defines
>blah() for the 1st time? Will blah() alone do the trick?
It does, in my experience - providing the driver is compiled so that it
doesn't require a prototype for the function. I think this is one
of MudOS's "broken type checking" type options. I don't know offhand
whether MudOS will load a file that has a function prototype but
never actually defines the function.
>And apart from that, as far as I remember, this_object() in a shadow
>doesn't point to the shadowed object. Guess what it points to..
The point was not using this_object() in a shadow. The point was that
if you want a function to be modifyable by shadows, and you want to
call that function within the object then your call must look like
this_object()->blah() or your call cannot be intercepted by a shadow.
I don't think there is another case where you must use this_object()->blah()
to get the desired behaviour.
>: IMHO, LPC could use a 'noinherit' declaration, but failing this, you can
>: rename all your create() functions to something like init() and then have
>: your standard include file contain something like:
>Sure, go ahead, rename create() to init(), lots of fun guaranteed. Then
>rename it to clean_up(), for some more thrilling action.
No reason at all not to use init() if you have NO_ADD_ACTION defined and
nothing else using that name. On the other hand he said "something like
init()" - Lima uses a mudlib_create() function I believe to help avoid
problems with create() being inherited and overridden.
>You know, for a person who brags in these newsgroups about his programming
>skills and then tries to sell this shit, or is building a mudlib and needs
>driver docs to know the syntax of call_out (cf. your earlier post) as if
Anyone can make a mistake. I bet not all your code works loads with no
syntax errors first time, everytime.
>a bit of thinking wasn't enough for such a specific function even if you
>forgot it, for a person who calls others morons freely not being able to
>even reason coherently, you seem to me one fucking idiot. No wonder lots
>of people have you killfiled, there;s enough crap around without your posts.
Do try and understand posts before you flame them.
--
Scatter
///\oo/\\\
Paul Miller
On Mon, 02 Feb 1998 19:45:31 GMT, thre...@counseltech.com (Threshold RPG)
wrote:
>In article <6b4l7t$nj9$4...@darla.visi.com>, George Reese <bo...@imaginary.com> wrote:
>>First, to do better, you have to identify a problem with what exists
>>now. I am not making the claim that no one could ever do better. I
>>am saying that if he has not even identified a problem with the
>>existing system, then it is foolishness to come up with one of his
>>own.
>
>Why? Why in the HELL does he *HAVE* to use someone else's system.
>
>Why do you feel that just because someone does something well, everyone else
>is an IDIOT if they don't use it.
Whoa, hold on here. It looks like you are flaming George just for being George
here. In this case, his comment has obvious merit. Lima's security system is
very good and very flexible. I won't claim it is bulletproof, but as George
says, unless there is a problem with the design someplace, a divergent design
can only be equally or less secure.
>What if they guy just wants to have a mudlib that is TOTALLY of his own
>design? Is that a problem? Does this represent a threat to you?
That'd make a great learning experience, for sure. I doubt many people have the
necessary skills to sit down and just design the ultimate mudlib in one go,
though. Borrowing others' work, such as the security system of Lima, helps.
[In fact, it looks like the original poster is headed toward a security system
very much resembling the stack-based approach, with the safe() call, and such.]
John Viega
In article <34D694...@hotmail.com> David W Serhienko
<tig...@hotmail.com> writes:
What they are talking about is the security system that comes with the
Lima mudlib. If you want, you're more than welcome to extract it from
the mudlib, etc.
Paul Miller
j...@ultra4.cc.umr.edu (John Adelsberger) wrote:
>Paul Miller (pmiller@*DIESPAMMERS*.lni.net) wrote:
>:Ah, the beauties of add_action(). add_action() is the single worst thing ever
>:to happen to mud security, simply because there is no way to control via mudlib
>:code which add_action() gets called first. Since the last registered always
>:takes precedence, then we get some problems with say, add_action()'ing over rm.
>How about a simul of add_action? That would allow control, even though
>add_action _is_ a piece of shit.
Sure, but if you're going to sim add_action(), you might as well not have the
original around anyway.
>: I fail to see how this is a significant security breach. Any such override
>: would only be effective within the same object that did the overriding.
>Oh, well, hey, I suppose its no problem if I override your simul-efun
>override of the efun that shuts down the mud. You won't mind, will you?
>This is just the beginning...
Ehrm, by "override a simul_efun" I assumed he meant "define a function of the
same name with the same return time, returning the same parameters as a simul
efun, within some object". In that case, creating a function void shutdown()
wouldn't really do anything (in MudOS or 3.2.1), except allow you to call
this_object()'s shutdown(). As long as one cannot get at efun::shutdown(), then
no security breach is possible. In DGD, this might be a different story, but
I'm not qualified to comment on that really.
>If I want to force you to do something, the odds are I'm just being annoying,
>and I can be annoying a million ways that don't require force. If your
>security system is worth anything at all, it will stop forces of any
>privileged command one way or another unless the forcer has the privelege,
>whether or not it is detected as a force.
Isn't this a contradiction: "it will stop forces of any privilidged command one
way or another unless the forcer has the privelege, ****whether or not it is
detected as a force.****"? Lets say rm is the privilidged action in question.
How could I possibly prevent forced rm's and allow non-forced rm's, without
detecting which are which? [Not that detecting forces is difficult by any
means; that point is moot.]
I think you might be confusing rm the command which most muds implement to
remove a file, and the efun/kfun which removes a file from the mud. The rm
command would do such things as check who is the user, does this user have
permission to remove this file? Yes -> remove it, no -> sorry. The remove file
efun/kfun should check, does the my caller have priviledge to remove this file?
Yes -> remove, no -> sorry. The rm efun doesn't care about what
this_player()/this_user() is, while the rm command does.
>Consider that I can easily do something like:
>exec foreach(object user in users()) destruct user;
... which is not a security violation. "Security violation" as I interpret it
in this context, is obtaining privilidges one does not usually have. Since an
object can generally destruct another object (unless you want to make a really
memory-hogging mud), it follows that destruct (user) isn't a privilidge
violation in any reasonable sense.
>And you'll quickly realize that nothing is going to stop someone who wants
>to be annoying and is sufficiently creative. Override destruct? Ok,
>I'll log you out. Override users() to exclude certain folks? Ok, I'll
>use objects(). See?
Being annoying isn't a violation of security. Getting rid of annoying people is
an entirely different thread. ;-)
Mike McGaughey
>: : Reinventing the wheel gets you nothing. The Lima security system is
>: : based on ideas that have been documented by Ellery. I am not
>: : suggesting you need to use their code. I am saying writing a new
>: : security system is a waste of time.
>:
>: computer architecture and Plan Kalkul as a language? Anyone using
>:
> 'reinventing the wheel' then you're more than a moron.
No. There are any number of different ways of implementing security.
I wrote one of them (before Lima existed). I prefer mine to the one
subsequently used in Lima. However, *they* reinvented the wheel by not
using my ideas.
So what's your point?
Cheers,
Mike.
Hint: George's comment about reinventing the wheel is strictly false in
this context.
--
Mike McGaughey AARNET: mm...@cs.monash.edu.au
"Thousands at his bidding speed,
And post o'er land and ocean without rest" - Milton.
Scatter ///oo/\
John Adelsberger intoned these words...
>Tim Hollebeek (t...@franck.Princeton.EDU.composers) wrote:
>
>: Lima's remove_hook() has perverse semantics and shouldn't be emulated.
>: Instead, to help coders, a string "name" should be added, and kept, so
>: it can be used to remove the hook. E.g. I'd suggest modifying the
>: interface to be:
>: some_object->add_hook("remove", "end my spell", (: end_spell_func :));
>: some_object->remove_hook("remove", "end my spell");
>
>Then again, I wouldn't want anyone writing code that needed hooks if he
>couldn't cope with the Lima implementation... that kind of failure
>indicates to me that he doesn't know what he's doing.
The problem simply that whereas 3 == 3 and "hello" == "hello",
(: write, "hello" :) != (: write, "hello" :) as I've just discovered.
Hence something added with add_hook( "blah", (: some_function :) ) cannot
be removed with remove_hook( "blah", (: some_function :) ) because the
two function pointers are considered to be different.
You would have to do function f; f = (: some_function :); and then
add_hook and remove_hook using f.
Function pointers are not the most easily understood type at the best
of times and this behaviour can easily cause confusion even amongst
experienced coders because to all intents and purposes (: write, "hello" :)
looks like a constant, but isn't treated as a constant.
--
Scatter ///\oo/\\\
George Reese
Mike McGaughey <mm...@mjolnir.cs.monash.edu.au> wrote:
: ban...@indiana.edu (Piotr Banski) writes:
:> John Adelsberger (j...@ultra2.cc.umr.edu) wrote:
:>: George Reese (bo...@imaginary.com) wrote:
:>: : Reinventing the wheel gets you nothing. The Lima security system is
:>: : based on ideas that have been documented by Ellery. I am not
:>: : suggesting you need to use their code. I am saying writing a new
:>: : security system is a waste of time.
:>:
:>: Well, George, this is true, so why aren't you using the original ENIAC
:>: computer architecture and Plan Kalkul as a language? Anyone using
:>:
:> If you can't see a difference between his and yous context of
:> 'reinventing the wheel' then you're more than a moron.
: No. There are any number of different ways of implementing security.
: I wrote one of them (before Lima existed). I prefer mine to the one
: subsequently used in Lima. However, *they* reinvented the wheel by not
: using my ideas.
: So what's your point?
: Cheers,
: Mike.
: Hint: George's comment about reinventing the wheel is strictly false in
: this context.
This has nothing to do with anything. As has been pointed out on many
thing Shattered Worlds has claimed to invented first, it was never
open to public viewing. An invention in the dark is no invention at
all.
John Viega
In article <6b840a$q3q$2...@towncrier.cc.monash.edu.au> mm...@mjolnir.cs.monash.edu.au (Mike McGaughey) writes:
> No. There are any number of different ways of implementing security.
> I wrote one of them (before Lima existed). I prefer mine to the one
> subsequently used in Lima. However, *they* reinvented the wheel by not
> using my ideas.
Yes, there are different ways to implement security. Feel free to
prefer yours.
The real contribution in Ellery's work was a theoretical foundation
for mud security that strongly limits the number of places in the lib
where you have to concern yourself with the question, "do I have to
think about security here?" Prior to that, many of us had never seen a
system we couldn't find a hole in, because it was so easy to open up a
hole, and it was difficult to realize that you might be doing so.
Also, we had never previously seen a solid theory applied to muds,
especially not one with such strong garuntees.
Ellery's theory and implementation were both the first of its kind for
this community. Perhaps you could have been the first to contribute
such a thing to the community at large, but you did not. If you or
anyone did something similar first and made it publicly availible to
this community, then it *would have gotten used*, because most of us
are more concerned with safety than novelty. That is, I'd rather have
something simple that I believe in, than something cool that I don't
believe in, which is pretty much every other security system that has
ever been written that wasn't based in a solid theory. In the 5 years
or so since Ellery started working on his system, there have been
plenty of people who choose to completely ignore all of this work, and
I have never seen such a system that I couldn't break onto. That
doesn't mean such a system couldn't be written, or even that it hasn't
been written. It is just really, really hard to begin with,
especially without a good theory to guide you (I've seen systems based
on his theory I'd probably believe in, but Ellery's system does have
the advantage of being better tested and scrutinized).
John
-------------------------------------------------------------------------------
|John Viega "The public at large tends to confuse the |
|vi...@list.org composing of a symphony with the writing of |
|http://list.org/~viega/ its score." |
|University of Virginia -- Edsger Dijkstra |
-------------------------------------------------------------------------------
Piotr Banski
$88k$2...@news.uk.ibm.com>
Distribution: world
Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
: In <6b6vh9$dcv$1...@flotsam.uits.indiana.edu>,
ban...@indiana.edu (Piotr Banski) writes:
: >John Adelsberger (j...@ultra2.cc.umr.edu) wrote:
: >: Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
: >: : Thinking about it, without shadows there is no real reason an
object should
: >: : call this_object()->blah() is there? It would be faster simply to
call blah() : >: : direct.
: >: Unless the function might be overridden by an inheritor and you want the
: >: overridden version, you're right.
: >You use :: for overridden versions, mister.
:
: He meant if you want the overriding version rather than the overridden.
What can I say. You're a better mind reader than I am. *Even* if we assume
that he meant the overrid_ing_ function, his claim is just as nonsensical,
cause you obviously don't need a call_other to this_object() for that.
And someone calling others morons and himself an experienced lpc
programmer all the time should perhaps know that.
: The point was that if object A defines blah() and object B inherits A and
: overrides the definition, if a function in A calls blah() will it get
the overriding
: version of blah() from B? I think it does, but without trying it I don't
: know for sure. I would expect it to.
And my point was that it may be hard w/o call_others to this_object(),
even if you don't need them in the case you describe. Of course both my and
Timothy's examples could be redone to get rid of the call_other overhead,
at the cost of having to resolve stuff in the inheritor, for example. And
then the answer to your question might be 'yes'.
My point was also that John doesn't have a point with his stupid example.
: >The validity of
: >this_object()->blah() extends a bit farther than just shadows.
: >What if you use this call in A which is inherited by B which defines
: >blah() for the 1st time? Will blah() alone do the trick?
:
: It does, in my experience - providing the driver is compiled so that it
In my experience it doesn't, even without prototypes required. Unless you
create an empty function to be overridden. Timothy's example with
multiple inheritance actually illustrates the point better, I think,
cause you may choose not to bother resolving the two blah()s and simply
call_other to this_object instead. (on the other hand, won't the order
in which they are inherited help resolve this? but i) it would not be
very obvious, ii) what if we also have bleh() and bluh() in various
configurations which won't simply get resolved by the order of inheritance)
[ cut ]
: if you want a function to be modifyable by shadows, and you want to
: call that function within the object then your call must look like
: this_object()->blah() or your call cannot be intercepted by a shadow.
: I don't think there is another case where you must use this_object()->blah()
: to get the desired behaviour.
It seems to me the answer is 'no, if you go to the extreme'. I'm not
sure it's worth pushing to the extreme though. I mean, creating in A
empty functions to be inherited and resolved in C which also inherits B
with the 'real' definitions of those functions is a bit extreme. Of
course, John will say that the architecture of His Lib won't make that
necessary and I'll bow down and happily believe him, cause the guy is
obviously gifted.
: >: IMHO, LPC could use a 'noinherit' declaration, but failing this, you can
: >: rename all your create() functions to something like init() and then have
: >: your standard include file contain something like:
: >Sure, go ahead, rename create() to init(), lots of fun guaranteed. Then
: >rename it to clean_up(), for some more thrilling action.
:
: No reason at all not to use init() if you have NO_ADD_ACTION defined and
: nothing else using that name. On the other hand he said "something like
: init()" - Lima uses a mudlib_create() function I believe to help avoid
: problems with create() being inherited and overridden.
As far as I understood from other posts in this and the tmi/lima thread,
both of you make some use of add_action(). I apologize if I was wrong.
Anyway, even if you don't use it, what's the point in using a function
name so heavy with meaning, unless you're just wierd and want less
experienced coders to have problems reading your lib.
: >You know, for a person who brags in these newsgroups about his programming
: >skills and then tries to sell this shit, or is building a mudlib and needs
: >driver docs to know the syntax of call_out (cf. your earlier post) as if
:
: Anyone can make a mistake. I bet not all your code works loads with no
: syntax errors first time, everytime.
Nope, of course not. The difference is that I don't constantly spam these
newsgroups with crap, in an attempt to boost my ego, as John does.
: >a bit of thinking wasn't enough for such a specific function even if you
: >forgot it, for a person who calls others morons freely not being able to
: >even reason coherently, you seem to me one fucking idiot. No wonder lots
: >of people have you killfiled, there;s enough crap around without your
posts. :
: Do try and understand posts before you flame them.
The only thing I may have failed to understand is that neither of you
uses add_action. If so (?), then I'm sorry. Just for that.
Best bluh()s,
Piotr
Mike McGaughey
George Reese <bo...@imaginary.com> writes:
> This has nothing to do with anything. As has been pointed out on many
> thing Shattered Worlds has claimed to invented first, it was never
> open to public viewing. An invention in the dark is no invention at
> all.
I posted a complete description to this newsgroup around five years
ago - rationale, implementation, etc. So it is hardly unknown.
But this isn't the point. Designing and implementing one's own
solution to some problem - even security problems - is never a
pointless exercise. To insist that one is uselessly reinventing
the wheel by not re-using some pre-existing system is arrogant
nonsense. I might equally well slag you off for writing the
Nightmare mudlib.
Cheers,
Mike.
Mike McGaughey
jt...@adder.cs.virginia.edu (John Viega) writes:
>
> The real contribution in Ellery's work was a theoretical foundation
> for mud security that strongly limits the number of places in the lib
> where you have to concern yourself with the question, "do I have to
> think about security here?"
Ooh, precisely the same principles as those upon which I based my system,
described in my posts about them. That was at a time when I used to
be concerned about provable correctness :)
> Ellery's theory and implementation were both the first of its kind for
> this community. Perhaps you could have been the first to contribute
> such a thing to the community at large, but you did not.
I did. I'd repost my original descriptions of the system (from
five or six years ago) to prove my point, but that'd mean trolling
through dejanews to find them. I can't be bothered, and it's not
really important to either of us.
It really gets up my nose when people snootily claim that reinvention
is necessarily a bad thing - it assumes, for a start, that the
people doing the re-inventing knew about the original invention;
it also assumes that the re-invention won't be *better*. George
was claiming that one shouldn't re-solve problems already addressed
by Lima. I found it amusing and ironic that I had solved the same
problems years before then, and was rubbing *george's* nose in it,
not yours.
It's not me that claims you should never have re-invented Lima
security - go argue with George instead.
John Viega
In article <34D70A77...@simplex.remove-this.nl> "Felix A. Croes" <fe...@simplex.remove-this.nl> writes:
> The system offers 3 different types of security: wizard-level,
> transparent,
> and special.
Well, that may be a mental model for it that we use on Lima, but the
security system itself really has no notion of 'transparent' at all.
> Wizard-level security, for the majority of objects, amounts to: "if you
> do
> not use unguarded(), it will not work."
I agree 100% that this is a valid criticism. Yet, since that
primarily only applies to write_file (on Lima), that's fine with me,
honestly. I.e., that is the way we want it, and it boils down to a
matter of opinion. Our rationalle is that we want wizards to have to
use unguarded(), to think about how they might be granting write
permissions to the public that they shouldn't be granting. They can
always avoid unguarded() by writing to a priv 0 directory, which is
always an option on Lima.
> Moreover, there is a security
> hierarchy for wizard objects in Ellery's design which I consider to be a
> mistake. There is no reason why a wizard's objects, as opposed to the
> wizard
> himself, should have file access outside of that wizard's directory,
> other
> than read access in publicly readable ones. My main criticism on this
> level
> is that the system is overly complex.
Well, in general I agree with you. However, not everybody feels the
same way-- I've seen people who would disagree, who feel everything
should happen in the wizard's directory if the wizard is responsible
for it, etc... Plus, I've found that wizards don't even really
notice. It's a complexity that people who wouldn't understand it tend
not to be exposed to anyway.
> The transparent security involves a large amount of mudlib objects. To
> obtain transparent security an object requires global access, which is a
> big
> weakness, because all of them are now in the class of objects which have
> to
> be checked for global security holes. Moreover, giving anyone write
> access
> to an object with transparent security now implies giving that person
> global
> access.
See, there really isn't a notion of transparent in the security
system. Without a first class notion of transparent, this isn't going
to be something you could change... If you had a proposal for a clean
system like that, we might consider adopting it. But really, this
isn't a big issue for us. On Lima, stuff we consider "transparent"
mentally boils down to a handful of commands, and like 8 other
objects. That's a small, small part of the lib, and it has never even
been an inconvience that only admins could touch that stuff, that I
can recall.
> I have one more criticism of the system as a whole: it mixes up file
> access
> security and call_other/command security. The two systems ought to be
> distinct.
I'm not sure that I understand this one... the user can explicitly
check the whole stack if he really wants to do so, but the mudlib only does
its own checks at file access time, IIRC.
Another criticism the Lima team has of the system is that it doesn't address
inheriting or including across permissions. For example, a priv 1
object inheriting anything of a lesser priv opens up a hole. This
means that most of our include files are going to be priv 1, and we
can't open them up for just anyone to muck with. That is far more of
an inconvenience than the "trans" problem, but it still hasn't been
*that* big a deal.
On Lima we've talked about fixing the inherit/include problem, but it
would really warrant driver level changes which probably won't happen
for a while. It isn't that urgent: we still know the 3 places where a
person could potentially add a security hole (unguarded(), inherit and
include), and for someone who knows enough about the security system
it is generally pretty easy to check by hand if you've added any holes
like this.
Niilo Paasivirta
John Adelsberger <j...@ultra2.cc.umr.edu> wrote:
>Niilo Paasivirta (n...@kanto.cc.jyu.fi) wrote:
>: time. I'll rather trust linux to do the security.
>What a bad idea... Linux is awesome, don't get me wrong, but to say there
>are a FEW security problems with it is an understatement.
True... I'd still say LPmud is a BIT less secure than Linux, and that is
too an understatement. And I will not even mention certain "operating
systems" by a certain huge software company, in a thread about security...
If I could, I'd put a LPmud and its machine behind a firewall. That
is not possible, the experts said. (No one could log in into the mud.)
Anyway, I would not take coders I don't absolutely trust. Certainly I
would not advertise "coders needed" here.
There are also other ways to "code" than to give coder access. Designers
can write room descriptions etc. and e-mail them. Is there any more
secure method?
--
<a href="http://www.jyu.fi/%7Enp/index.html"> Niilo Paasivirta </a>
Threshold RPG
In article <34d77e83...@nntp.lni.net>, pmiller@*DIESPAMMERS*.lni.net (Paul Miller) wrote:
>Whoa, hold on here. It looks like you are flaming George just for being George
>here.
First off, I wasnt flaming him. I didnt call him a moron, idiot, asshole, or
any other name.
Second, I was pointing to his comment that anyone who designed their own
system would be foolish. Who is he to tell someone they are foolish for trying
something new.
> In this case, his comment has obvious merit. Lima's security system is
>very good and very flexible. I won't claim it is bulletproof, but as George
>says, unless there is a problem with the design someplace, a divergent design
>can only be equally or less secure.
Since you cannot claim it is bulletproof, then it must not be foolish for
someone to try something new.
>>What if they guy just wants to have a mudlib that is TOTALLY of his own
>>design? Is that a problem? Does this represent a threat to you?
>
>That'd make a great learning experience, for sure. I doubt many people have
> the necessary skills to sit down and just design the ultimate mudlib in one go,
>though. Borrowing others' work, such as the security system of Lima, helps.
Right, it would be a great learning experience. So if they guy wants to do
it, then it is NOT a 'foolish' exercise.
If I was going to design a security system, I know damn well I would look
closely at other systems. I know that I do not have the skills to design my
own. However, there are other people who DO have the skills, and if they want
to try something new that is not inherently or automatically foolish.
-Aristotle@Threshold
]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, rich, detailed roleplaying environment.
http://www.threshold.counseltech.com
telnet://threshold.counseltech.com:23
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lars Duning
Niilo Paasivirta wrote:
>
> John Adelsberger <j...@ultra2.cc.umr.edu> wrote:
> >Niilo Paasivirta (n...@kanto.cc.jyu.fi) wrote:
> >: time. I'll rather trust linux to do the security.
> >What a bad idea... Linux is awesome, don't get me wrong, but to say there
> >are a FEW security problems with it is an understatement.
>
> True... I'd still say LPmud is a BIT less secure than Linux, and that is
> too an understatement. And I will not even mention certain "operating
> systems" by a certain huge software company, in a thread about security...
Now I am confused: are you talking about general system security here, or
simple security _within_ the mud and the mud only.
> If I could, I'd put a LPmud and its machine behind a firewall. That
> is not possible, the experts said. (No one could log in into the mud.)
Why that? (I'm always eager to expand my knowledge, in this case about
firewalls)
> Anyway, I would not take coders I don't absolutely trust. Certainly I
> would not advertise "coders needed" here.
>
> There are also other ways to "code" than to give coder access. Designers
> can write room descriptions etc. and e-mail them. Is there any more
> secure method?
Sounds more that you have a Diku-type mud in mind, not an LP.
--
Lars Duening; la...@cableinet.co.uk (Home)
Lars Duning
John Viega wrote:
>
> In article <6b840a$q3q$2...@towncrier.cc.monash.edu.au> mm...@mjolnir.cs.monash.edu.au (Mike McGaughey) writes:
>
> > No. There are any number of different ways of implementing security.
> > I wrote one of them (before Lima existed). I prefer mine to the one
> > subsequently used in Lima. However, *they* reinvented the wheel by not
> > using my ideas.
>
> Yes, there are different ways to implement security. Feel free to
> prefer yours.
>
> for mud security that strongly limits the number of places in the lib
> where you have to concern yourself with the question, "do I have to
Hah, that reminds me...
/* Warning! Irrelevant, fond memories follow! */
During the time he[1] developed his system, I was thinking about ways to
make better use of the 3.2-uids in terms of security; and we had a few
discussions about this. Probably his ideas already shone through - in
the end I ended up with a system which basically was a static variant
of the system he presented here. Not that that proves anything.
Those were the days...
[1] Am I the only one here remembering him as 'Macbeth'?
--
Lars Duening; la...@cableinet.co.uk
John Viega
> [1] Am I the only one here remembering him as 'Macbeth'?
Most of us in the states couldn't spend much time on TubMUD due to the lag.
I remember him as Macbeth, yes, but even when he still logs on Lima it
is as Ellery :)
George Reese
Mike McGaughey <mm...@mjolnir.cs.monash.edu.au> wrote:
: George Reese <bo...@imaginary.com> writes:
:> This has nothing to do with anything. As has been pointed out on many
:> thing Shattered Worlds has claimed to invented first, it was never
:> open to public viewing. An invention in the dark is no invention at
:> all.
: I posted a complete description to this newsgroup around five years
: ago - rationale, implementation, etc. So it is hardly unknown.
Clearly the collective memory on this one is running a bit low. I
would certainly love to see that post. Or in absence of it, a new
rationale and implementation. See, for you to have a point, two
things are required:
* collective knowledge of the system prior to the invention of Ellery's
* Ellery's system not solving a superset of problems handled by SW's
I am fairly certain the former does not exist.
: But this isn't the point. Designing and implementing one's own
: solution to some problem - even security problems - is never a
: pointless exercise.
Why not rewrite the OS while at it? Solving well-understood and
well-solved problems, especially when they relate to security, is bad
form while there are other problems to solve.
: To insist that one is uselessly reinventing
: the wheel by not re-using some pre-existing system is arrogant
: nonsense. I might equally well slag you off for writing the
: Nightmare mudlib.
Why would you do that? At the time I wrote Nightmare, nothing else
did what it did.
Felix A. Croes
John Viega wrote:
>In article <34D70A77...@simplex.remove-this.nl> "Felix A. Croes" <fe...@simplex.remove-this.nl> writes:
>
>> The system offers 3 different types of security: wizard-level, transparent,
>> and special.
>
>Well, that may be a mental model for it that we use on Lima, but the
>security system itself really has no notion of 'transparent' at all.
I have used the Lima terminology, but otherwise what I wrote concerned
the stack-based security system without taking the particular mudlib
into account. The "transparency" feature is not a Lima add-on or a
clever "abuse" of the system. It is present by design.
>[...]
>> The transparent security involves a large amount of mudlib objects. To
>> obtain transparent security an object requires global access, which is a big
>> weakness, because all of them are now in the class of objects which have to
>> be checked for global security holes. Moreover, giving anyone write access
>> to an object with transparent security now implies giving that person global
>> access.
>
>See, there really isn't a notion of transparent in the security
>system. Without a first class notion of transparent, this isn't going
>to be something you could change...
Well, since it immediately follows from other factors, all you have to
do is change one of those other factors, yes? Or even more than one.
Junk the whole system. Yes!
>If you had a proposal for a clean
>system like that, we might consider adopting it. But really, this
>isn't a big issue for us. On Lima, stuff we consider "transparent"
>mentally boils down to a handful of commands, and like 8 other
>objects. That's a small, small part of the lib, and it has never even
>been an inconvience that only admins could touch that stuff, that I
>can recall.
But the security system was not designed for Lima in particular. Any
weakness that only becomes apparent in other, even hypothetical,
mudlibs is still a weakness. Saying that it does not effect Lima
defends Lima, not the security system.
>> I have one more criticism of the system as a whole: it mixes up file access
>> security and call_other/command security. The two systems ought to be
>> distinct.
>
>I'm not sure that I understand this one... the user can explicitly
>check the whole stack if he really wants to do so, but the mudlib only does
>its own checks at file access time, IIRC.
File access security is that which allows any particular object to
access a file. Call_other security is what makes the following a safe
function:
void foo(string bar, string gnu) { write_file(bar, gnu); }
It is a mistake to combine these two types of security in one system.
File access privileges are not meaningful for many operations that have
nothing to do with files, but that one nevertheless might want to make
secure. For example,
void foo() { destruct(object_only_I_can_destruct); }
This function can be made safe with call_other security, but file
access permissions are simply not appropriate here. Yes, you can do
your own stack checks, but the point is that the security system as
present in Lima cannot be used for this.
What is more, in many cases the stack checks get in the way, which
is why unguarded() has to be used so often. You may argue that this
makes wizards think about what they are doing, but I do not see it
as significantly better than renaming write_file() to
be_careful_write_file().
Regards,
Dworkin
P.S. If you are going to reply to this, please don't put my
unmutilated email address in the cc: line of the posting.
I am trying to foil spammers. Thanks.
John Adelsberger
Richard (rm...@spudent.canterbury.ac.nz) wrote:
: I was coding something just the other day, and when you over-ride something
: in an inheritor the stand-alone blah() calls the top-most instance
: of the function.
This is the 'proper OO' way, so I suppose thats why it is done, but I know
some old driver or another didn't behave this way... truth be known, the
'improper' semantics are far more useful, despite the claims of so-called
experts.
(To see why, just think a moment - you can ALWAYS get the 'proper' semantics
with this_object()->blah() if you have the 'improper' defaults, but try doing
it the other way around. One can take this sort of argument too far, as in
C++, but in this case, even a 5 year old can be made to know what's going on.)
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
John Adelsberger
Piotr Banski (ban...@indiana.edu) wrote:
I wrote:
: : Well, George, this is true, so why aren't you using the original ENIAC
: : computer architecture and Plan Kalkul as a language? Anyone using
: : anything else reinvented the wheel, dammit!
: What if he can point out a problem with that, smartass?
Seeing as he knows nothing about ENIAC's architecture(note that architecture
does not mean implementation or even overall construction) and probably
doesn't even know what Plan Kalkul IS, much less what it can do or how,
I'm fairly safe.
: Try to make a bit
: of sense when you flame or your posts will be treated as nothing but
: idiotic blabbing, as I hear they are.
You hear? Hey hey, folks, he heard! Hey, I heard that the international
space station was going to be the next one up, but it ISN'T TRUE!!! Imagine
that... you can hear something, and it can be wrong anyway.
: If you can't see a difference between his and yous context of
: 'reinventing the wheel' then you're more than a moron.
This is true. I _am_ more than a moron.
Hint: the reason I was so hard on this is because reuse is George's religion.
He has said in the past that if you have something that works, it is
ALWAYS wrong to redo it from scratch. He may dishonestly claim
otherwise, but the archives don't lie. He made no qualifications about
suitability of the reused product for the new task whatsoever, and I
think this may well be a result of the fact that if people DON'T buy
the reuse religion, he's out of work. Yes, I know that reuse is a good
thing; I'm preparing to build a system which will likely use it more
extensively than it has ever been used before. This does not mean that
simply because a toaster heats things, you should convert it for use as
a bread oven.
John Adelsberger
Piotr Banski (ban...@indiana.edu) wrote:
: You use :: for overridden versions, mister. The validity of
That's Mr. Asshole to you.
: What if you use this call in A which is inherited by B which defines
: blah() for the 1st time? Will blah() alone do the trick?
If in fact another poster was correct, it SHOULD do the trick, but it
probably doesn't in current implementations.
: And apart from that, as far as I remember, this_object() in a shadow
: doesn't point to the shadowed object. Guess what it points to..
Yes, in the shadow. Not in the shadowed object. Perhaps if you'd maintain
some sense of context?
: : IMHO, LPC could use a 'noinherit' declaration, but failing this, you can
: : rename all your create() functions to something like init() and then have
: : your standard include file contain something like:
: Sure, go ahead, rename create() to init(), lots of fun guaranteed. Then
: rename it to clean_up(), for some more thrilling action.
You're an idiot. I wasn't referring to crusty old systems taht actually
use add_action and related garbage. I like distributed parsing, but not
using add_action.
: You know, for a person who brags in these newsgroups about his programming
: skills and then tries to sell this shit, or is building a mudlib and needs
: driver docs to know the syntax of call_out (cf. your earlier post) as if
I do more different things than you probably ever will. No, I don't have
the syntax of call_out memorized - I only use it once in a great while,
because it doesn't have that many good uses. I keep things I'm currently
doing committed to memory, and the rest I can look up if I care.
: a bit of thinking wasn't enough for such a specific function even if you
Actually, I can think of several different ways to set up the arguments,
and I've seen a suggestion for a much improved form. When and if you
gain the background to even know that there ARE alternatives, come back
and play again. For now, you're boring me.
John Adelsberger
Piotr Banski (ban...@indiana.edu) wrote:
: Piotr Banski (ban...@indiana.edu) wrote:
: : And apart from that, as far as I remember, this_object() in a shadow
: Ooops, this point seems invalid to the discussion. Sorry.
No kidding...
John Adelsberger
Felix A. Croes (fe...@simplex.remove-this.nl) wrote:
: There is no reason why a wizard's objects, as opposed to the
: wizard himself, should have file access outside of that wizard's directory,
I'm not sure about this. I haven't finalized my system yet, but what I'm
looking at currently is allowing a wiz's objects EITHER to possess some or all
of his file access rights OR to be callable from outside the wiz and his
directory. Occasionally, it is handy to have objects that do things for you
that you wouldn't want just anyone to be able to do, but that affect files
not in your directory.
: other than read access in publicly readable ones. My main criticism on this
: level is that the system is overly complex.
No question that the Lima system is complex, but unless someone demonstrates
a simpler system that does what it does, this isn't much of an argument.
Still, I think that can be done.
: The transparent security involves a large amount of mudlib objects. To
: obtain transparent security an object requires global access, which is a
: big weakness, because all of them are now in the class of objects which have
: to be checked for global security holes. Moreover, giving anyone write
: access to an object with transparent security now implies giving that person
: global access.
This I wondered about also. So far as I can tell, transparency basically
means 'this object ignores the security system entirely,' and most of
the objects that matter are transparent.
: I have one more criticism of the system as a whole: it mixes up file
: access security and call_other/command security. The two systems ought to
: be distinct.
I certainly agree here. I think, however, that doing call/command security
right will make file security trivial.
John Adelsberger
Paul Miller (pmiller@*DIESPAMMERS*.lni.net) wrote:
: On Mon, 02 Feb 1998 19:45:31 GMT, thre...@counseltech.com (Threshold RPG)
: wrote:
: Whoa, hold on here. It looks like you are flaming George just for being
: George here.
Not at all a bad practice. Quite respectable, in fact.
: In this case, his comment has obvious merit. Lima's security system is
: very good and very flexible. I won't claim it is bulletproof, but as George
: says, unless there is a problem with the design someplace, a divergent design
: can only be equally or less secure.
If you think everyone wants the same thing when he says 'security,' you'd
better lay off the drugs. If not, your argument doesn't make any sense.
: >What if they guy just wants to have a mudlib that is TOTALLY of his own
: >design? Is that a problem? Does this represent a threat to you?
: That'd make a great learning experience, for sure. I doubt many people have
: the necessary skills to sit down and just design the ultimate mudlib in one
: go, though. Borrowing others' work, such as the security system of Lima,
: helps.
Borrowing design ideas might help. Anything else just tends to make you a
copy. As for 'one go,' I'm on my third, I think. Each time I get farther,
and the results to a certain point are exactly as I want them. I expect
this to be the last or maybe 2nd to last time through. Considering that
my first attempt failed because I switched to a significantly different
driver and LPC dialect, I'm not doing so bad, IMHO.
John Adelsberger
Paul Miller (pmiller@*DIESPAMMERS*.lni.net) wrote:
: j...@ultra4.cc.umr.edu (John Adelsberger) wrote:
: >How about a simul of add_action? That would allow control, even though
: >add_action _is_ a piece of shit.
: Sure, but if you're going to sim add_action(), you might as well not have the
: original around anyway.
Agreed, but I figured you probably didn't feel like modding the driver. If
you do, go for it:-)
: >Oh, well, hey, I suppose its no problem if I override your simul-efun
: >override of the efun that shuts down the mud. You won't mind, will you?
: >This is just the beginning...
: Ehrm, by "override a simul_efun" I assumed he meant "define a function of the
: same name with the same return time, returning the same parameters as a simul
: efun, within some object". In that case, creating a function void shutdown()
The MudOS docs use simul_efun override to mean doing efun::some_efun(), as
I recall.
: >If I want to force you to do something, the odds are I'm just being annoying,
: >and I can be annoying a million ways that don't require force. If your
: >security system is worth anything at all, it will stop forces of any
: >privileged command one way or another unless the forcer has the privelege,
: >whether or not it is detected as a force.
: Isn't this a contradiction: "it will stop forces of any privilidged command one
: way or another unless the forcer has the privelege, ****whether or not it is
: detected as a force.****"? Lets say rm is the privilidged action in question.
: How could I possibly prevent forced rm's and allow non-forced rm's, without
: detecting which are which? [Not that detecting forces is difficult by any
: means; that point is moot.]
This would depend on details of a specific design, but it is possible in
general. That said, detecting forces is not difficult, but it is not
trivial; most implementations you've probably seen are fairly easy to
break. If it uses this_player(), you lose.
: I think you might be confusing rm the command which most muds implement to
: remove a file, and the efun/kfun which removes a file from the mud. The rm
: command would do such things as check who is the user, does this user have
: permission to remove this file? Yes -> remove it, no -> sorry. The remove file
: efun/kfun should check, does the my caller have priviledge to remove this file?
: Yes -> remove, no -> sorry. The rm efun doesn't care about what
: this_player()/this_user() is, while the rm command does.
No, my rm command does not. this_player() is useless. The only place
security is checked on files in my lib is valid_read/valid_write. I'm
considering various implementations of a new valid_call_other or similar.
Putting security checks in commands means all I have to do to violate your
security is create an object that calls rm(). If you check this_player,
I can play social engineering games to get a nasty object into an admin's
hands. The only good this_player() does is in non-security situations it
makes getting a user's name a bit easier.
: >exec foreach(object user in users()) destruct user;
: ... which is not a security violation. "Security violation" as I interpret it
This was my point.
: in this context, is obtaining privilidges one does not usually have. Since an
: object can generally destruct another object (unless you want to make a really
: memory-hogging mud), it follows that destruct (user) isn't a privilidge
: violation in any reasonable sense.
Actually, preventing universal destruct rights doesn't imply being a memory
hog at all. Use a simul wrapper for destruct() that does whatever checks you
like, and use clean_up extensively, if not nearly universally. Many entire
categories of problems can be solved by realizing that you can extend LPC in
a lot of ways you don't usually think about using simuls. ATM, just to see
how it works, I'm working on simul'ing call_other... not sure if it'll even
work though:-)
John Adelsberger
Scatter ///\oo/\\\ (sca...@thevortex.com) wrote:
: The problem simply that whereas 3 == 3 and "hello" == "hello",
: (: write, "hello" :) != (: write, "hello" :) as I've just discovered.
: Hence something added with add_hook( "blah", (: some_function :) ) cannot
: be removed with remove_hook( "blah", (: some_function :) ) because the
: two function pointers are considered to be different.
: You would have to do function f; f = (: some_function :); and then
: add_hook and remove_hook using f.
You could also use ints as hook-handles(yes, you heard that right:) into
an array of hooks, or use strings as keys into a mapping of hooks.
John Adelsberger
George Reese (bo...@imaginary.com) wrote:
: An invention in the dark is no invention at all.
This is a good one, even for George. Hey, George, lay off the drugs.
John Adelsberger
Piotr Banski (ban...@indiana.edu) wrote:
: My point was also that John doesn't have a point with his stupid example.
You have a point, but if you wear a big hat...
: : if you want a function to be modifyable by shadows, and you want to
: : call that function within the object then your call must look like
: : this_object()->blah() or your call cannot be intercepted by a shadow.
: : I don't think there is another case where you must use this_object()->blah()
: : to get the desired behaviour.
: with the 'real' definitions of those functions is a bit extreme. Of
: course, John will say that the architecture of His Lib won't make that
: necessary and I'll bow down and happily believe him, cause the guy is
: obviously gifted.
Gifted enough that my lib doesn't HAVE shadows. Oops. Do you in fact know
any of what you're talking about, or are you just spouting shit?
: : No reason at all not to use init() if you have NO_ADD_ACTION defined and
: : nothing else using that name. On the other hand he said "something like
: : init()" - Lima uses a mudlib_create() function I believe to help avoid
: : problems with create() being inherited and overridden.
: As far as I understood from other posts in this and the tmi/lima thread,
: both of you make some use of add_action(). I apologize if I was wrong.
You were wrong. You are sorry.
: Anyway, even if you don't use it, what's the point in using a function
: name so heavy with meaning, unless you're just wierd and want less
: experienced coders to have problems reading your lib.
It has no meaning to me, except what I give it. It has no meaning to the
people who work with my lib, except what I give it. If what you mean is
that poor old high-school Bobby and his DW-clone coding experience won't
cut it on my mud, you're right, but function names have NOTHING to do with
that.
: Nope, of course not. The difference is that I don't constantly spam these
: newsgroups with crap, in an attempt to boost my ego, as John does.
My ego is large, solid, and made of metal. It needs no boosting. I post
for grins:-)
: The only thing I may have failed to understand is that neither of you
: uses add_action. If so (?), then I'm sorry. Just for that.
You're sorry for a lot more than just that.
John Adelsberger
Lars Duning (ldu...@mdisystems.com) wrote:
: Niilo Paasivirta wrote:
: > If I could, I'd put a LPmud and its machine behind a firewall. That
: > is not possible, the experts said. (No one could log in into the mud.)
: Why that? (I'm always eager to expand my knowledge, in this case about
: firewalls)
Because the whole purpose of a firewall is to disallow incoming network
traffic.
Mike McGaughey
George Reese <bo...@imaginary.com> writes:
> Mike McGaughey <mm...@mjolnir.cs.monash.edu.au> wrote:
>: But this isn't the point. Designing and implementing one's own
>: solution to some problem - even security problems - is never a
>: pointless exercise.
> Why not rewrite the OS while at it? Solving well-understood and
> well-solved problems, especially when they relate to security, is bad
> form while there are other problems to solve.
Well, hell, go argue with Linus Torvalds.
Linux is a re-implementation of ideas that were freely available
in BSD, and which had in any case been solved long before either
system was developed.
George Reese
John Adelsberger <j...@ultra4.cc.umr.edu> wrote:
: Hint: the reason I was so hard on this is because reuse is George's religion.
: He has said in the past that if you have something that works, it is
: ALWAYS wrong to redo it from scratch. He may dishonestly claim
: otherwise, but the archives don't lie. He made no qualifications about
: suitability of the reused product for the new task whatsoever, and I
: think this may well be a result of the fact that if people DON'T buy
: the reuse religion, he's out of work. Yes, I know that reuse is a good
: thing; I'm preparing to build a system which will likely use it more
: extensively than it has ever been used before. This does not mean that
: simply because a toaster heats things, you should convert it for use as
: a bread oven.
I would appreciate you cite my arguments where you reference any
belief you are attributing to me. It makes for a far more
constructive discussion than one where you make up arguments and
attribute them to me.
I really fail to see how you have come to the conclusion I believe
something should be reused at all costs, regardless of whether it is
fit for a certain task. I do not believe that and would never
consciously imply such a thing. If you know of a place where I have
implied such a thing, I would very much appreciate you pointing it
out.
In the context of this thread, I have simply stated that the original
poster should make use of an existing, proven security system instead
of inventing his own. This is not using a toaster as a bread oven.
It is using a security system as a security system.
George Reese
John Adelsberger <j...@ultra4.cc.umr.edu> wrote:
: Lars Duning (ldu...@mdisystems.com) wrote:
: : Niilo Paasivirta wrote:
: : > If I could, I'd put a LPmud and its machine behind a firewall. That
: : > is not possible, the experts said. (No one could log in into the mud.)
: : Why that? (I'm always eager to expand my knowledge, in this case about
: : firewalls)
: Because the whole purpose of a firewall is to disallow incoming network
: traffic.
No, it is not. A firewall exists in order to put greater controls on
what comes from the network.
John Adelsberger
George Reese (bo...@imaginary.com) wrote:
: belief you are attributing to me. It makes for a far more
: constructive discussion than one where you make up arguments and
: attribute them to me.
Sorry, I chopped the top line of your reply by accident. Anyway, go back
and look at the big argument you got into with me about reuse a little
while back(last fall/winter sometime.) If you didn't mean what I thought
I saw, you must have been almost deliberate in deceiving me. Lots of
very absolutist statements about 'never reinventing the wheel,' and no
response whatsoever to the point(which was made repeatedly) that not
all software is fit to be reused.
: In the context of this thread, I have simply stated that the original
: poster should make use of an existing, proven security system instead
: of inventing his own. This is not using a toaster as a bread oven.
: It is using a security system as a security system.
Using Z rated tires on an F1 car might be a better analogy in this case.
Not all security systems have the same goals, and goals aren't better
or worse, but just different.
John Adelsberger
: > Why not rewrite the OS while at it? Solving well-understood and
: > well-solved problems, especially when they relate to security, is bad
: > form while there are other problems to solve.
: Well, hell, go argue with Linus Torvalds.
My current BIG project is the beginnings of a new operating
system; this system will use MANY things found in your typical intro
to OS book, but that doesn't mean you could EVER duplicate it using
a stock UNIX kernel and the associated baggage. Doing distribution
and several other things which are my primary goals requires rethinking
from the ground up unless you want the result to be a bad hack(ala DCE.)
Similarly, I have goals for my mud security which, while I'll use stack
based methods and other things which have been done before, do NOT admit
of being hacked onto an existing system.
Sooner or later, George is going to learn that in computing, there is no
One True Way that suits all purposes, and that sometimes rewriting from
scratch is the best answer. I hope the paramedics are close by when it
happens, because he'll be an old man by then, and his heart may not take
the shock well.
Jon A. Lambert
On 5 Feb 98 00:45:05 GMT, John Adelsberger spaketh...
>
>Sooner or later, George is going to learn that in computing, there is no
>One True Way that suits all purposes, and that sometimes rewriting from
>scratch is the best answer.
[John Adelsberger spaketh on 11/23/97]
"Unless you intend to do something graphical, telnet is the One True Way[tm]
regardless of language."
Blah, blah, blah. Both of you deserve noogies.
--
--/*\ Jon A. Lambert - TychoMUD Email:jlsy...@nospam.ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
George Reese
John Adelsberger <j...@ultra3.cc.umr.edu> wrote:
: George Reese (bo...@imaginary.com) wrote:
: : belief you are attributing to me. It makes for a far more
: : constructive discussion than one where you make up arguments and
: : attribute them to me.
: Sorry, I chopped the top line of your reply by accident. Anyway, go back
: and look at the big argument you got into with me about reuse a little
: while back(last fall/winter sometime.) If you didn't mean what I thought
: I saw, you must have been almost deliberate in deceiving me. Lots of
: very absolutist statements about 'never reinventing the wheel,' and no
: response whatsoever to the point(which was made repeatedly) that not
: all software is fit to be reused.
Why am I not surprised? You attribute arguments to me and then
completely fail to to provide anything resembling a relevant citation
to back that up. You do this even though I am explicitly saying I do
not advocate this position. Do you understand how ridiculous this sounds?
: : In the context of this thread, I have simply stated that the original
: : poster should make use of an existing, proven security system instead
: : of inventing his own. This is not using a toaster as a bread oven.
: : It is using a security system as a security system.
: Using Z rated tires on an F1 car might be a better analogy in this case.
: Not all security systems have the same goals, and goals aren't better
: or worse, but just different.
I have heard nothing to suggest the goals of the security system in
question are different than anyone elses. In fact, that was the
general idea behind him posting and getting feedback in the first
place. Security is damn simple--you want to make sure that each
object on the mud only has access to the resources it needs and
nothing more.
John Viega
In article <34D8A5EC...@simplex.remove-this.nl> "Felix A. Croes" <fe...@simplex.remove-this.nl> writes:
> >Well, that may be a mental model for it that we use on Lima, but the
> >security system itself really has no notion of 'transparent' at all.
>
> I have used the Lima terminology, but otherwise what I wrote concerned
> the stack-based security system without taking the particular mudlib
> into account. The "transparency" feature is not a Lima add-on or a
> clever "abuse" of the system. It is present by design.
Huh? For an object to be transparent to the security system for all
possible callers, it needs to have priv 1. The security system has no
special notion that maps directly to transparent objects. They're
just normal priv 1 objects that don't really do any of their own file
access.
> But the security system was not designed for Lima in particular. Any
> weakness that only becomes apparent in other, even hypothetical,
> mudlibs is still a weakness. Saying that it does not effect Lima
> defends Lima, not the security system.
Nope, it was designed for TubMUD in particular. I agree, it works
well for Lima, and that might not be what is best for everyone. I
never said otherwise.
> >> I have one more criticism of the system as a whole: it mixes up file access
> >> security and call_other/command security. The two systems ought to be
> >> distinct.
> >
> >I'm not sure that I understand this one... the user can explicitly
> >check the whole stack if he really wants to do so, but the mudlib only does
> >its own checks at file access time, IIRC.
>
> File access security is that which allows any particular object to
> access a file. Call_other security is what makes the following a safe
> function:
Ok, I got you now, and I completely disagree with respect to Lima.
That would just add another layer of complexity for little payoff
beyond orthogonality (for us). Like I said, we don't represent the
whole world, I can see why others might find it desirable.
> What is more, in many cases the stack checks get in the way, which
> is why unguarded() has to be used so often. You may argue that this
> makes wizards think about what they are doing, but I do not see it
> as significantly better than renaming write_file() to
> be_careful_write_file().
Yes, I think that would also be an acceptable user interface, though
I'd probably pick a name like unsafe_write_file().
> P.S. If you are going to reply to this, please don't put my
> unmutilated email address in the cc: line of the posting.
> I am trying to foil spammers. Thanks.
I didn't realize the CC line made it into the final distribution, I
thought it was just a hint to the newsreader. But I've got 2 lines of
code that automatically detected and removed the "bogus" part of your
address, and place it in the CC line, so I wouldn't have to do so
manually. I'm sure spammers will start doing the same thing as soon
as this practice becomes widespread enough. I'll disable that removal
now that I know the CC shows up, and I just won't send you a copy at
all :)
John Viega
> Richard (rm...@spudent.canterbury.ac.nz) wrote:
>
> : I was coding something just the other day, and when you over-ride something
> : in an inheritor the stand-alone blah() calls the top-most instance
> : of the function.
>
> This is the 'proper OO' way, so I suppose thats why it is done, but I know
> some old driver or another didn't behave this way... truth be known, the
> 'improper' semantics are far more useful, despite the claims of so-called
> experts.
>
> (To see why, just think a moment - you can ALWAYS get the 'proper' semantics
> with this_object()->blah() if you have the 'improper' defaults, but try doing
> it the other way around. One can take this sort of argument too far, as in
> C++, but in this case, even a 5 year old can be made to know what's going on.)
Let's say you've got a language with these semantics:
1) this->foo() starts at the most derived class in the current object
and works down
2) foo() starts at the current derived class in the current object
and works down
So if A inherits B, and both define foo(), B has to explicitly say
"this is 'virtual' with the special syntax (virtual is a bad name,
IMHO, but I'll use it anyway).
Now, that's all fine and dandy until you come across an
"unanticipated" use. Which happens all the time, read Stein,
Lieberman & Ungar's "A Shared View of Sharing: The Treaty of Orlando"
in OO Concepts, Apps & Databases (Addison-Wesley) for a good
discussion, IIRC.
Whole languages such as Self try to promote unanticipated use, it is
so common. 'virtual' not being the default makes this difficult. If
the class B *really* wants to keep something 'non-virtual' in a system
where everything is 'virtual', B can write a method my_foo(), make it
non-overridable by whatever language mechanism (assuming there is one,
or by convention if there isn't...) and call *that* when it *really*
thinks it is smarter than class A which will probably be written
later, with the knowlege of B's representation. If A really wants to
dispatch back to B, then it could, in a system where all methods are
virtual.
However, the flip side is that 'virtual' functions detract from the
notion of manifest interface. If A, by some complex chain inherits Z
for its definition of foo(), and Z calls and defines bar()... when I'm
browsing Z, it is definitely not apparent by the syntax if F's version
of bar() would really get called. That's why I like the notion of
*always* qualifying with: self.blah() or this->blah() or whatever
syntax you'd prefer: the syntax serves to remind the programmer of the
implementation In such a system, I'd have a different syntax for
'non-virtual' calls though, I definitely wouldn't have blah() result
in such a call, because it would be highly overused since it involves
less typing. I have no real recommendation for the syntax I'd use in
place, though.
I'll agree greatly that C++'s virtual function mechanism is way
confusing to people. For example,the fact that b->foo() acts
different when you cast down from a variable of type B to a variable
of type A unless foo is virtual in A confuses the heck out of most
novices, and even some experts I've seen.
John Viega
In article <6bbabt$8...@dfw-ixnews11.ix.netcom.com> jlsy...@nospam.ix.netcom.com (Jon A. Lambert) writes:
> On 5 Feb 98 00:45:05 GMT, John Adelsberger spaketh...
> >
> >Sooner or later, George is going to learn that in computing, there is no
> >One True Way that suits all purposes, and that sometimes rewriting from
> >scratch is the best answer.
>
> [John Adelsberger spaketh on 11/23/97]
> "Unless you intend to do something graphical, telnet is the One True Way[tm]
> regardless of language."
>
> Blah, blah, blah. Both of you deserve noogies.
>
Hahaha... :)
Sometimes you've gotta wonder what arguments are heartfelt, and which
are being made just to gainsay the opposition and make them seem
stupid. :O
And sometimes it is very obvious :)