MudOS bug? all_previous_objects()
Scatter ///oo/\
I've discovered the following using MudOS (v22.2a25). If you have
the following:
void blah()
{
write( sprintf( "%O\n", all_previous_objects() ) );
input_to( "blah2" );
}
void blah2()
{
write( sprintf( "%O\n", all_previous_objects() ) );
}
Call blah() in the object and I get:
({ /* sizeof() == 3 */
/global/commands/creator/call ("/global/commands/creator/call"),
/global/handlers/command ("/global/handlers/command"),
/obj/user/lord#1 ("Scatter")
})
..which is what I'd expect. Hit return to run blah2() and I get:
({ })
Which is not what I'd expect - I'd hoped for /obj/user/lord#1 at least
and hoped for /w/scatter/test as well. Is this a feature or a bug?
Using call_stack(1) instead didn't help either - that gave:
({ /* sizeof() == 1 */
/w/scatter/test ("/w/scatter/test")
})
What I'm trying to get at is that in a function run by "input_to" there
seems to be no way to ascertain the identity of the object (player)
that ran the "input_to" function. call_stack(3) says "internal"
which is correct in a way, but unhelpful. :)
The reason this is causing me grief is because my security handler
uses all_previous_objects() to determine whether a file write is
permitted or not. I have a couple of cases where I have a menu-driven
interface (using input_to) to do things that need to use the player's
access level to save files. Because the player isn't in the trace,
the security handler finds the interface object at the top and disallows
the write since the interface object has no access.
Is the only way around this to replace input_to with a mudlib version?
--
Scatter ///\oo/\\\
George Reese
The behaviour you are describing is the correct behaviour. After all,
in an input_to() call back, there is no previous object. The right
way to handle security with the situations you describe is to make
sure the input_to() functions are static.
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: I've discovered the following using MudOS (v22.2a25). If you have
: the following:
: ({ })
: --
: Scatter ///\oo/\\\
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
and this is why i hate you and how i understand
that no one ever knows or loves another ...or loves another
-The Cure "How Beautiful You Are"
John Adelsberger
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: What I'm trying to get at is that in a function run by "input_to" there
: seems to be no way to ascertain the identity of the object (player)
: that ran the "input_to" function. call_stack(3) says "internal"
: which is correct in a way, but unhelpful. :)
: Is the only way around this to replace input_to with a mudlib version?
Yet another poor soul discovers one of the two obvious demonstrations of
LPC's one real weakness - asynchronous events. If there were efuns to
enable and disable terminal echoing, you could use process_input for
this in a really snazzy way. I also experimented(and still use, for the
moment) with a hack that uses a simul for noechoed input and calls input_to.
The only other alternative is to manually save the call stack, which, if
I had to guess, is what I'd guess Lima does, although its been so long now
since I looked at that stuff and I was so little interested in security
at the time that I can't swaer to that. The 'right way' is probably either
a major increase in language complexity(threads:) or else moving security
into the driver(which, despite the trend in the opposite direction, isn't
necessarily a bad idea - security of the filesystem is a reasonable thing
to stick in there, and light isn't:-)
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
John Adelsberger
George Reese <bo...@imaginary.com> wrote:
: The behaviour you are describing is the correct behaviour. After all,
: in an input_to() call back, there is no previous object. The right
: way to handle security with the situations you describe is to make
: sure the input_to() functions are static.
This works, but it also requires the functions to be in the same object, and
it also means you're going to have LOTS of code for which the usual
security system is utterly useless. Saving the call stack can be a more
general solution, but it has problems too. Frankly, this is the ONE
thing I've found about MudOS that just outright sucks nads.
Do note that if MudOS provided efuns such as 'echo_off' and 'echo_on,'
you could just use process input and an input system similar to Lima's
and never need to use input_to, which is a piece of shit anyway. This
is where I'm going with my driver, since I've given up on staying stock
anyway. That leaves resolve() calls, for which I imagine I'll devise
a new solution - I refuse on humanitarian grounds to put speical case
code all over my lib to ignore security just because DNS is rarely
cached.
Scatter ///oo/\)
>The behaviour you are describing is the correct behaviour. After all,
>in an input_to() call back, there is no previous object. The right
>way to handle security with the situations you describe is to make
>sure the input_to() functions are static.
Ok, granted there's no actual call_other from the player to the function, in
that sense there's no previous object. I would consider the player to be the
"originator" of the call however.
How does making the function static tell me who the player was? The
security problem arises from the unknown identity, there is no issue with
who might call the function and from where.
As far as I can tell, the only way to do that is this_player() and I'm
certainly not going to have the security handler use that...
--
Scatter ///\oo/\\\
Scatter ///oo/\)
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>
>: What I'm trying to get at is that in a function run by "input_to" there
>: seems to be no way to ascertain the identity of the object (player)
>: that ran the "input_to" function. call_stack(3) says "internal"
>: which is correct in a way, but unhelpful. :)
>
>: Is the only way around this to replace input_to with a mudlib version?
>
>Yet another poor soul discovers one of the two obvious demonstrations of
>LPC's one real weakness - asynchronous events.
Out of interest, what's the other one?
>If there were efuns to
>enable and disable terminal echoing, you could use process_input for
>this in a really snazzy way.
I think that's the way I'm going to have to go, replace input_to with a simul
which just sets a bit of info in the player object to be used by the next
process_input() call.
Isn't it possible to write a couple of echo_on/off simul's that simply
write() the appropriate telnet echo on/off commands? Time to find
the telnet rfc again.
>I also experimented(and still use, for the
>moment) with a hack that uses a simul for noechoed input and calls input_to.
I think the only time I use no-echoed input is for login password entry.
That said, it's a fairly important use. :)
>The only other alternative is to manually save the call stack, which, if
>I had to guess, is what I'd guess Lima does,
Ah good point, I'll peer at Lima tonight.
--
Scatter ///\oo/\\\
Scatter ///oo/\)
In <6nslio$1i60$3...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) writes:
>In <35a19...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
>>If there were efuns to
>>enable and disable terminal echoing, you could use process_input for
>>this in a really snazzy way.
>
>Isn't it possible to write a couple of echo_on/off simul's that simply
>write() the appropriate telnet echo on/off commands? Time to find
>the telnet rfc again.
Experiments with telnet set to show option negotiation seem to indicate
that MudOS enables/disables local echoing by sending telnet WILL ECHO
and WON'T ECHO sequences respectively. I.e. it turns off client local echo
by telling the client it'll do the echoes itself, and vice versa.
So, the following simuls should work:
#define IAC 255
#define WILL 251
#define WONT 252
#define ECHO 1
void echo_off( object player )
{
string cmd = "xxx";
cmd[0] = IAC;
cmd[1] = WILL;
cmd[2] = ECHO;
tell_object( player, cmd );
}
void echo_on( object player )
{
string cmd = "xxx";
cmd[0] = IAC;
cmd[1] = WONT;
cmd[2] = ECHO;
tell_object( player, cmd );
}
I'll play with it tonight and see what breaks...
--
Scatter ///\oo/\\\
telnet user
In article <35a19...@news.cc.umr.edu>, John Adelsberger <j...@umr.edu> writes:
>
> Do note that if MudOS provided efuns such as 'echo_off' and 'echo_on,'
> you could just use process input and an input system similar to Lima's
> and never need to use input_to, which is a piece of shit anyway.
Funny. Lima handles no-echo input just fine without those efuns.
The idea that input_to shouldn't be used as anything other than the
basis for a more MUD-specific input system isn't that far off base,
though.
---------------------------------------------------------------------------
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."
telnet user
>
> ({ })
>
> Which is not what I'd expect - I'd hoped for /obj/user/lord#1 at least
> and hoped for /w/scatter/test as well. Is this a feature or a bug?
If it returned anything else, it'd be a bug, since those objects
aren't on the call stack at the time. input_to's (and other things)
use callbacks; trying to think in some abstract terms about this being
"a continuation of the previous thread" will just get you in trouble.
> What I'm trying to get at is that in a function run by "input_to" there
> seems to be no way to ascertain the identity of the object (player)
> that ran the "input_to" function. call_stack(3) says "internal"
> which is correct in a way, but unhelpful. :)
Well, IMO, if you're writing functions that get input_to'd, and you
don't know who did the input_to already, that's your problem :-)
input_to callbacks should probably always be private. If you have to
remember some information (like who did the call, what the call_stack was,
etc) pass that as an argument.
> The reason this is causing me grief is because my security handler
> uses all_previous_objects() to determine whether a file write is
> permitted or not. I have a couple of cases where I have a menu-driven
> interface (using input_to) to do things that need to use the player's
> access level to save files. Because the player isn't in the trace,
> the security handler finds the interface object at the top and disallows
> the write since the interface object has no access.
>
> Is the only way around this to replace input_to with a mudlib version?
Something like that, if you want it to work in general.
John Adelsberger
: >Yet another poor soul discovers one of the two obvious demonstrations of
: >LPC's one real weakness - asynchronous events.
: Out of interest, what's the other one?
resolve() has the same problem.
: >If there were efuns to
: >enable and disable terminal echoing, you could use process_input for
: >this in a really snazzy way.
: Isn't it possible to write a couple of echo_on/off simul's that simply
: write() the appropriate telnet echo on/off commands? Time to find
: the telnet rfc again.
As soon as you start talking about sending telnet protocol using write()
you know you should be doing driver mods. There is a _reason_ the
driver contains tons of telnet code:-)
: >I also experimented(and still use, for the
: >moment) with a hack that uses a simul for noechoed input and calls input_to.
: I think the only time I use no-echoed input is for login password entry.
: That said, it's a fairly important use. :)
Probably for changing passwords, too.
John Adelsberger
: Funny. Lima handles no-echo input just fine without those efuns.
Sure, it can be done. I've heard of entire small 'custom programming'
houses that use nothing but Excel macros, too.
Seriously, the input, and more generally, the asynchronous event handling
of LPC just plain out blows, and that is the only major weakness it still
has; this is worthy of consideration, regardless of egos or personalities.
A simple fix is the efuns I was talking about, but that doesn't address
the larger issue - which may be acceptable since the only other
category of asynch events that are common at all are calls to resolve().
George Reese
:>The behaviour you are describing is the correct behaviour. After all,
:>in an input_to() call back, there is no previous object. The right
:>way to handle security with the situations you describe is to make
:>sure the input_to() functions are static.
: Ok, granted there's no actual call_other from the player to the function, in
: that sense there's no previous object. I would consider the player to be the
: "originator" of the call however.
You control who the originator is. You only make callbacks public
when there are no security implications behind them. The efun
all_previous_objects() means no more than what it says, and there is
no previous object for a callback.
: How does making the function static tell me who the player was? The
: security problem arises from the unknown identity, there is no issue with
: who might call the function and from where.
It tells you that only a function in that object could have had the
input_to() call. So, if you have in thing.c:
void promptName() {
write("Name: ");
input_to((: enterName :));
}
static /* or protected for later MudOS */ void enterName(string nom) {
name = nom;
}
You know that enterName() was only called from some method in thing.c
(like promptName()). It was not triggered by a call_other(). If
there are security issues surrounding this call, they should exist in
promptName().
: As far as I can tell, the only way to do that is this_player() and I'm
: certainly not going to have the security handler use that...
this_player() is not an issue here.
Scatter ///oo/\)
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>: >If there were efuns to
>: >enable and disable terminal echoing, you could use process_input for
>: >this in a really snazzy way.
>: Isn't it possible to write a couple of echo_on/off simul's that simply
>: write() the appropriate telnet echo on/off commands? Time to find
>: the telnet rfc again.
>As soon as you start talking about sending telnet protocol using write()
>you know you should be doing driver mods. There is a _reason_ the
>driver contains tons of telnet code:-)
Yes, but for something this trivial I'm not going to wade into the MudOS
source code. I'd rather have an unmodified driver so that I can be sure
anything wrong with it isn't my own stupid fault. :)
BTW, the echo_off/on functions I posted work flawlessly so I've now
solved my problem by a simple mudlib version of input_to. This gets
called from process_input() and so the player object is where it
should be at the top of the call stack.
>: I think the only time I use no-echoed input is for login password entry.
>: That said, it's a fairly important use. :)
>Probably for changing passwords, too.
Yup, that too. :)
--
Scatter ///\oo/\\\
Scatter ///oo/\)
>
>:>The behaviour you are describing is the correct behaviour. After all,
>:>in an input_to() call back, there is no previous object. The right
>:>way to handle security with the situations you describe is to make
>:>sure the input_to() functions are static.
>: Ok, granted there's no actual call_other from the player to the function, in
>: that sense there's no previous object. I would consider the player to be the
>: "originator" of the call however.
>You control who the originator is. You only make callbacks public
>when there are no security implications behind them. The efun
>all_previous_objects() means no more than what it says, and there is
>no previous object for a callback.
The only security implication is that the security handler has no
independent verification that the subsequent file write should be
allowed and therefore it fails safe and disallows it. Sure I know
in the callback itself who called it, that's not the problem. From
the point of view of the callback, who called it is irrelevant because
the normal operation of the security system will prevent unauthorised
file access anyway.
>: How does making the function static tell me who the player was? The
>: security problem arises from the unknown identity, there is no issue with
>: who might call the function and from where.
>It tells you that only a function in that object could have had the
>input_to() call. So, if you have in thing.c:
[snip example]
>You know that enterName() was only called from some method in thing.c
>(like promptName()). It was not triggered by a call_other(). If
>there are security issues surrounding this call, they should exist in
>promptName().
Again, the only security issue is that the security handler disallows
a call that would be permitted if the originating player was present
at the top of the call stack.
My security system is designed to fail safe in any questionable
circumstance. I'm happy after much testing that it is solid. I have
no desire to introduce any method for an object to tell the
security handler what access it should have (i.e. the player's in
this case) because such a method would be a potentially huge
loophole (how would the security handler know whether the
object could be trusted when it said "oh, and use this player's
access level please"?) and would mean a fairly vast amount of
regression testing. Not to mention that it would violate a couple
of principles of my security system -
1) That all security access levels are determined only by the
security system itself, and
2) That no extra work be needed in other objects in order to
be secure, and
3) That information from any objects not defined to be "as
secure as the security handler" cannot be trusted.
The input_to callback has no security checking at all, despite
the fact that it does a file write. Why? Because it doesn't matter
who called it - whatever it was, that object's access level will
be used by the security handler to allow or disallow the file
write. This breaks down because it's too secure, not because
it's insecure - if the input_to callback is called via call_other(),
security checking works perfectly because the originating object
is known.
I've solved the problem now by replacing input_to with a mudlib
equivalent checked for and called from process_input() in the
player. This is satisfactory for me, though I would have preferred
a way that would have left the driver doing the work instead of
the mudlib.
--
Scatter ///\oo/\\\
George Reese
:>: George Reese <bo...@imaginary.com> writes:
:>
:>:>The behaviour you are describing is the correct behaviour. After all,
:>:>in an input_to() call back, there is no previous object. The right
:>:>way to handle security with the situations you describe is to make
:>:>sure the input_to() functions are static.
:>: Ok, granted there's no actual call_other from the player to the function, in
:>: that sense there's no previous object. I would consider the player to be the
:>: "originator" of the call however.
:>You control who the originator is. You only make callbacks public
:>when there are no security implications behind them. The efun
:>all_previous_objects() means no more than what it says, and there is
:>no previous object for a callback.
: The only security implication is that the security handler has no
: independent verification that the subsequent file write should be
: allowed and therefore it fails safe and disallows it.
Fails safe? Whose security system? I know Nightmare allows an
operation with a zero stack based on the caller's permissions. I
would assume Lima does to since there is no reason not to allow the
operation.
: Sure I know
: in the callback itself who called it, that's not the problem. From
: the point of view of the callback, who called it is irrelevant because
: the normal operation of the security system will prevent unauthorised
: file access anyway.
No, that is not the case. From the security system point of view, the
object to which the callback is made is the only object involved in
the operation. The file succeeds or fails on that object's authority.
Just as it should.
:>: How does making the function static tell me who the player was? The
:>: security problem arises from the unknown identity, there is no issue with
:>: who might call the function and from where.
:>It tells you that only a function in that object could have had the
:>input_to() call. So, if you have in thing.c:
: [snip example]
:>You know that enterName() was only called from some method in thing.c
:>(like promptName()). It was not triggered by a call_other(). If
:>there are security issues surrounding this call, they should exist in
:>promptName().
: Again, the only security issue is that the security handler disallows
: a call that would be permitted if the originating player was present
: at the top of the call stack.
It probably disallows the operation in question. The fact that this
was an input_to() should be 100% completely irrelevant to the issue.
: My security system is designed to fail safe in any questionable
: circumstance. I'm happy after much testing that it is solid.
Then this is a bug with your security system, because this is NOT a
questionable circumstance.
: I have
: no desire to introduce any method for an object to tell the
: security handler what access it should have (i.e. the player's in
: this case) because such a method would be a potentially huge
: loophole (how would the security handler know whether the
: object could be trusted when it said "oh, and use this player's
: access level please"?) and would mean a fairly vast amount of
: regression testing. Not to mention that it would violate a couple
: of principles of my security system -
: 1) That all security access levels are determined only by the
: security system itself, and
: 2) That no extra work be needed in other objects in order to
: be secure, and
: 3) That information from any objects not defined to be "as
: secure as the security handler" cannot be trusted.
Lima and Nightmare have managed to create security systems that meet
all three goals and are quite secure. And no changing of semantics
for all_previous_objects() was required.
: The input_to callback has no security checking at all, despite
: the fact that it does a file write. Why? Because it doesn't matter
: who called it - whatever it was, that object's access level will
: be used by the security handler to allow or disallow the file
: write.
This is a HUGE bug. The fact is, for the valid_write() call, the
object that did the file write is on the stack and is the object that
should be checked for valid access. This does not mean you let the
object itself determine its permissions... It means your security
system keeps track of permissions for that object.
: This breaks down because it's too secure, not because
: it's insecure - if the input_to callback is called via call_other(),
: security checking works perfectly because the originating object
: is known.
If call_other() makes a difference, you have a big security bug.
: I've solved the problem now by replacing input_to with a mudlib
: equivalent checked for and called from process_input() in the
: player. This is satisfactory for me, though I would have preferred
: a way that would have left the driver doing the work instead of
: the mudlib.
You are writing a hack that ignores the real problem.
Scatter ///oo/\)
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>: George Reese <bo...@imaginary.com> writes:
>:>: George Reese <bo...@imaginary.com> writes:
>:>
>:>when there are no security implications behind them.
>: independent verification that the subsequent file write should be
>: allowed and therefore it fails safe and disallows it.
>
>Fails safe?
Yes, that means it will never default or "fall through" to permitting
an object to do something dangerous without clear, independently
determinable evidence that the operation should be permitted.
>Whose security system?
Mine.
>I know Nightmare allows an operation with a zero stack based on the
>caller's permissions.
If the stack is empty, how do you know who the caller was? Or do you
mean "If the only object in the stack is the previous_object() to the
call to the security system"?
>I would assume Lima does to since there is no reason not to allow
>the operation.
>: Sure I know
>: in the callback itself who called it, that's not the problem. From
>: the point of view of the callback, who called it is irrelevant because
>: the normal operation of the security system will prevent unauthorised
>: file access anyway.
>No, that is not the case.
It might not be the case in your system, it is definitely the case
in my system.
>From the security system point of view, the object to which the
>callback is made is the only object involved in the operation.
>The file succeeds or fails on that object's authority.
Yes, that's the problem. The menu-interface object (i.e. the object
in which the input_to callback exists) does not have authority to
write files anywhere (except publically writeable directories). So
the file write always fails in any directory that is not publically
writeable.
> Just as it should.
No, this is my point. It shouldn't always fail. It should succeed
or fail based on the authorities of the player who is using the
menu-interface. A tool for rapid editing of files is fairly useless
if you have to copy all the files to a publically writeable
directory first, and is a massive liability if you grant the tool
itself access to write anywhere else since that would give _anyone_
who used it access to edit files anywhere.
>: Again, the only security issue is that the security handler disallows
>: a call that would be permitted if the originating player was present
>: at the top of the call stack.
>It probably disallows the operation in question. The fact that this
>was an input_to() should be 100% completely irrelevant to the issue.
I agree, it SHOULD be 100% irrelevant. It isn't irrelevant because
an input_to() callback does not have the player in the stack and
therefore the player's security access cannot be determined and
used in place of the callback objects (null) authority.
>: My security system is designed to fail safe in any questionable
>: circumstance. I'm happy after much testing that it is solid.
>Then this is a bug with your security system, because this is NOT a
>questionable circumstance.
It's questionable in my opinion because it's a way for coders
to do operations without appearing in the call stack.
Why do you consider it a bug that a system does not use the access
levels of an object for which it has no evidence that the object
was involved in the call?
>: 1) That all security access levels are determined only by the
>: security system itself, and
>: 2) That no extra work be needed in other objects in order to
>: be secure, and
>: 3) That information from any objects not defined to be "as
>: secure as the security handler" cannot be trusted.
>Lima and Nightmare have managed to create security systems that meet
>all three goals and are quite secure. And no changing of semantics
>for all_previous_objects() was required.
Correct, no changing of semantics for all_previous_objects() was
required. As Tim Hollebeek pointed out, I was expecting it to pick
up an abstract relationship between the player and the callback
that doesn't exist in terms of previous objects.
Some changing of how input_to() works was required instead, to ensure
that input_to() callbacks can be traced to the player that invoked
them.
>: The input_to callback has no security checking at all, despite
>: the fact that it does a file write. Why? Because it doesn't matter
>: who called it - whatever it was, that object's access level will
>: be used by the security handler to allow or disallow the file
>: write.
>This is a HUGE bug.
Why? Please give an example of how it could be abused or is insecure?
>The fact is, for the valid_write() call, the
>object that did the file write is on the stack and is the object that
>should be checked for valid access. This does not mean you let the
>object itself determine its permissions... It means your security
>system keeps track of permissions for that object.
That's exactly how it works, yes. You seem to be repeatedly missing
the point - the file write is disallowed because the tool in which
the callback exists in which the file write is done DOES NOT HAVE
and SHOULD NOT HAVE access to write files.
>: This breaks down because it's too secure, not because
>: it's insecure - if the input_to callback is called via call_other(),
>: security checking works perfectly because the originating object
>: is known.
>If call_other() makes a difference, you have a big security bug.
Call other makes a difference because it adds an object to the stack
which does have permission to write files - the player object who
originated the call.
How is this a bug?
>: I've solved the problem now by replacing input_to with a mudlib
>: equivalent checked for and called from process_input() in the
>: player.
>You are writing a hack that ignores the real problem.
I've written a "hack" that allows the security system to correctly
trace the origin of all calls involving player input right back to
the player. I don't see how this can be a bad thing.
I've also found two other benefits as side effects -
(1) Standard MudOS prompt handling occurs even in input_to()
meaning that the telnet GA signal is sent for prompts sent using
write() prior to input_to(). This allows intelligent prompt
handling from clients like tf to work even with input_to().
(2) I can 'stack' input_to() calls as many times as I like and they
will run through in the correct order - the driver version of
input_to() doesn't do this, only the most recent input_to()
call takes effect.
So my "hack" has been quite a success, IMO.
--
Scatter ///\oo/\\\
George Reese
: George Reese <bo...@imaginary.com> writes:
:>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
:>caller's permissions.
: If the stack is empty, how do you know who the caller was? Or do you
: mean "If the only object in the stack is the previous_object() to the
: call to the security system"?
:>I would assume Lima does to since there is no reason not to allow
:>the operation.
#1: In valid_write(), the call stack is never empty.
#2: Ff the only object is previous_object(), then the entire operation
is based solely on previous_object(). Why is one object on the call
stack different from ten?
:>: Sure I know
:>: in the callback itself who called it, that's not the problem. From
:>: the point of view of the callback, who called it is irrelevant because
:>: the normal operation of the security system will prevent unauthorised
:>: file access anyway.
:>No, that is not the case.
: It might not be the case in your system, it is definitely the case
: in my system.
Then the system is flawed. You are treating something differently
that is conceptually no different from other situations.
:>From the security system point of view, the object to which the
:>callback is made is the only object involved in the operation.
:>The file succeeds or fails on that object's authority.
: Yes, that's the problem. The menu-interface object (i.e. the object
: in which the input_to callback exists) does not have authority to
: write files anywhere (except publically writeable directories). So
: the file write always fails in any directory that is not publically
: writeable.
Then that is simply a problem with your security system, not a problem
with all_previous_objects() or input_to().
Your menu interface object should be a priveledged object that is
designed to manage security for itself.
:> Just as it should.
: No, this is my point. It shouldn't always fail. It should succeed
: or fail based on the authorities of the player who is using the
: menu-interface.
Here is a weakness in your security system. If adding the player
object to the call stack makes a difference, then your security system
a) is not a stack based security system and b) can be fooled simply by
finding a way to get a priveldged player's object onto the call stack.
In stack based security, an operation should succeed or fail based on
the permissions of the entire stack.
Now, you have not explicitly said your system is stack. I have
assumed that from some of the stuff you have said about it. The
point, however, is if it is stack based, you have implemented a stack
based system wrong. If it is not stack based, then you are writing a
security system wrong.
: A tool for rapid editing of files is fairly useless
: if you have to copy all the files to a publically writeable
: directory first, and is a massive liability if you grant the tool
: itself access to write anywhere else since that would give _anyone_
: who used it access to edit files anywhere.
I am not sure how Lima handles this, but on Nightmare, all file
manipulation tools are priveledged objects. Because the security
system is stack security, however, people are only able to use these
tools with their permissions.
The problem arises when such a tool needs to perform an operation from
a callback. In such cases, the tool needs to make security calls to
protect itself *before* calling input_to() (or any thing else that
causes a callback to be called at some point) with user entered data.
Now, it is true that these are extra operations not required in normal
security contexts. This is, however, ok. You know you are in a
special security context in writing this tool.
It is also possible that this could be designed by making this menu
object an inheritable of the player object, and thus the object
requesting permissions is the player object itself.
:>: Again, the only security issue is that the security handler disallows
:>: a call that would be permitted if the originating player was present
:>: at the top of the call stack.
:>It probably disallows the operation in question. The fact that this
:>was an input_to() should be 100% completely irrelevant to the issue.
: I agree, it SHOULD be 100% irrelevant. It isn't irrelevant because
: an input_to() callback does not have the player in the stack and
: therefore the player's security access cannot be determined and
: used in place of the callback objects (null) authority.
Again, this is a design problem in your system that the player object
matters at this point. It is not a problem with callbacks or
input_to().
:>: My security system is designed to fail safe in any questionable
:>: circumstance. I'm happy after much testing that it is solid.
:>Then this is a bug with your security system, because this is NOT a
:>questionable circumstance.
: It's questionable in my opinion because it's a way for coders
: to do operations without appearing in the call stack.
How can somone call an operation without appearing in the call stack?
They called the method which calls input_to()... all things can be
checked at that point.
: Why do you consider it a bug that a system does not use the access
: levels of an object for which it has no evidence that the object
: was involved in the call?
It is not supposed to. The object with the callback should perform
those checks *before* making the input_to() call.
:>: 1) That all security access levels are determined only by the
:>: security system itself, and
:>: 2) That no extra work be needed in other objects in order to
:>: be secure, and
:>: 3) That information from any objects not defined to be "as
:>: secure as the security handler" cannot be trusted.
:>Lima and Nightmare have managed to create security systems that meet
:>all three goals and are quite secure. And no changing of semantics
:>for all_previous_objects() was required.
: Correct, no changing of semantics for all_previous_objects() was
: required. As Tim Hollebeek pointed out, I was expecting it to pick
: up an abstract relationship between the player and the callback
: that doesn't exist in terms of previous objects.
: Some changing of how input_to() works was required instead, to ensure
: that input_to() callbacks can be traced to the player that invoked
: them.
I believe this_player(1) is good enough for an input_to() and cannot
be faked. But, ask Tim. At any rate, determining the player is not
really important.
:>: The input_to callback has no security checking at all, despite
:>: the fact that it does a file write. Why? Because it doesn't matter
:>: who called it - whatever it was, that object's access level will
:>: be used by the security handler to allow or disallow the file
:>: write.
:>This is a HUGE bug.
: Why? Please give an example of how it could be abused or is insecure?
Because permissions should not be determined by an individual object
on the call stack. A security system designed this way is somewhere
in security between this_player() and previous_object() based
security. Like I said above, to fake permissions, you just need to
shove the proper object somewhere into the call stack. As opposed to
this_player() which involves faking a specific object (albeit, an
easily faked object) into the call stack and previous_object() which
involves faking a very specific object into the call stack.
:>The fact is, for the valid_write() call, the
:>object that did the file write is on the stack and is the object that
:>should be checked for valid access. This does not mean you let the
:>object itself determine its permissions... It means your security
:>system keeps track of permissions for that object.
: That's exactly how it works, yes. You seem to be repeatedly missing
: the point - the file write is disallowed because the tool in which
: the callback exists in which the file write is done DOES NOT HAVE
: and SHOULD NOT HAVE access to write files.
No, you are missing the point. If it does not have permissions in the
case of input_to(), it should no more have permissions when the player
is directly in the call stack.
:>: This breaks down because it's too secure, not because
:>: it's insecure - if the input_to callback is called via call_other(),
:>: security checking works perfectly because the originating object
:>: is known.
:>If call_other() makes a difference, you have a big security bug.
: Call other makes a difference because it adds an object to the stack
: which does have permission to write files - the player object who
: originated the call.
: How is this a bug?
Because no one object on the stack should *enhance* permissions unless
that object is the object requesting the operation AND that object has
requested that object be performed in a special security context (for
example, a security context in which only its permissions are
considered).
Individual objects on the call stack should only have the power to
maintain the current permissions or weaken them. And never should an
external object change the security context of an operation performed
by a different object (i.e. the player object change the security
context of an operation being performaed by the menu object).
:>: I've solved the problem now by replacing input_to with a mudlib
:>: equivalent checked for and called from process_input() in the
:>: player.
:>You are writing a hack that ignores the real problem.
: I've written a "hack" that allows the security system to correctly
: trace the origin of all calls involving player input right back to
: the player. I don't see how this can be a bad thing.
Hack was a poor choice of words. The system itself may or may not be
a good thing. As has been pointed out, input_to() is not a perfect
system and LPC is fairly weak when it comes to asynchronous processing.
Having said that, the issues you have brought up are not issues with
respect to that system. Thus, if your input_to() workaround is
designed to deal with the issue of who is on the call stack, then it
is a hack in the sense that it was done to fix a problem with one
system (the input_to system) that is really a problem with security
system and it now masks the problem with the security system.
From your descriptions of it, it is probably a good input_to()
replacement on its own. My concern is the masking of the problems
with your security system.
: I've also found two other benefits as side effects -
: (1) Standard MudOS prompt handling occurs even in input_to()
: meaning that the telnet GA signal is sent for prompts sent using
: write() prior to input_to(). This allows intelligent prompt
: handling from clients like tf to work even with input_to().
: (2) I can 'stack' input_to() calls as many times as I like and they
: will run through in the correct order - the driver version of
: input_to() doesn't do this, only the most recent input_to()
: call takes effect.
: So my "hack" has been quite a success, IMO.
Like I said, it has nothing to do with the system itself, but the fact
that it hides weaknesses in your security system. Nightmare and Lima
both have input_to() replacements similar to this.
Err, or at least I was working on a replacement. I cannot remember
since I have not done any mud work in about a year.
John Adelsberger
: >I know Nightmare allows an operation with a zero stack based on the
: >caller's permissions.
: >I would assume Lima does to since there is no reason not to allow
: >the operation.
Mr. Reese means either:
1) the stack is empty - in this case, there is no call, so he doesn't mean
this
2) the stack has one object on it, and he uses that object's permissions -
this is the default behavior of stack based security in this case, and
Mr. Reese is being silly.
What he misses is that if an admin types 'dns WankerPlayer' to get a DNS
name for some wanker of a player and resolve() gets called and throws
this info back at him, it is impossible to tell whether or not, for
instance, the callback fn should be allowed to update a DNS cache. Don't
blame him - he's never been too bright:)
: >No, that is not the case.
: It might not be the case in your system, it is definitely the case
: in my system.
Hehe... now Georgy is telling other people how their homebrew libs work -
I'm waiting for his treatise on Beek being ignorant of Lima:-)
: >From the security system point of view, the object to which the
: >callback is made is the only object involved in the operation.
: >The file succeeds or fails on that object's authority.
: Yes, that's the problem. The menu-interface object (i.e. the object
: in which the input_to callback exists) does not have authority to
: write files anywhere (except publically writeable directories).
In this case, saving a copy of the call stack might be feasible, but as I've
said before, there are better answers, the best of which probably aren't
mudlib work, and a good one of which you've already done(use process_input()
instead of input_to().)
: >It probably disallows the operation in question. The fact that this
: >was an input_to() should be 100% completely irrelevant to the issue.
: I agree, it SHOULD be 100% irrelevant. It isn't irrelevant because
: an input_to() callback does not have the player in the stack and
: therefore the player's security access cannot be determined and
: used in place of the callback objects (null) authority.
Mr. Reese is suffering from delusions of understanding security. On
the bright side, he's harmless, but the downside is that it looks likle
he's never getting any better...
: >: My security system is designed to fail safe in any questionable
: >: circumstance. I'm happy after much testing that it is solid.
: >Then this is a bug with your security system, because this is NOT a
: >questionable circumstance.
: Why do you consider it a bug that a system does not use the access
: levels of an object for which it has no evidence that the object
: was involved in the call?
Because he likes to jump to conclusions without even acquiringa basic
understanding of what he's commenting on, and is utterly clueless about
what you are articulating?:-)
: >: The input_to callback has no security checking at all, despite
: >: the fact that it does a file write. Why? Because it doesn't matter
: >: who called it - whatever it was, that object's access level will
: >: be used by the security handler to allow or disallow the file
: >: write.
: >This is a HUGE bug.
: Why? Please give an example of how it could be abused or is insecure?
Because, as usual, he doesn't understand what you're doing. I can't swear
that your system is foolproof - I haven't seen it. However, it is certainly
a workable solution to save a security level from a user and make use of it
in a subsequent call you know that user approves of.
: That's exactly how it works, yes. You seem to be repeatedly missing
: the point - the file write is disallowed because the tool in which
: the callback exists in which the file write is done DOES NOT HAVE
: and SHOULD NOT HAVE access to write files.
I think Mr. Reese's problem is that his input_tos are probably all going
directly to user objects of some sort, and are probably part of a
mechanism designed specifically for that purpose, and so he DOES have
security info on them. This is a workable solution for this and also
for resolve, I think, but to call it ugly is an understatement. The
thought that some random object might be the target of an input_to is
probably beyond his current scope of thought, which isn't surprising -
after all, Javaheads don't much like function pointers:)
: >: I've solved the problem now by replacing input_to with a mudlib
: >: equivalent checked for and called from process_input() in the
: >: player.
: >You are writing a hack that ignores the real problem.
: I've written a "hack" that allows the security system to correctly
: trace the origin of all calls involving player input right back to
: the player. I don't see how this can be a bad thing.
It isn't a bad thing - Mr. Reese is a complete fucking moron. Get used
to it.
: (2) I can 'stack' input_to() calls as many times as I like and they
: will run through in the correct order - the driver version of
: input_to() doesn't do this, only the most recent input_to()
: call takes effect.
: So my "hack" has been quite a success, IMO.
Look at what Lima did(I have something similar, albeit much, much smaller,
which is roughly equal in function. The Lima fascination with hugeness
is still beyond me, but I admit, the thing works well when it isn't
erroring out on load due to call stack overrun by the documentation
daemon:)
Scatter ///oo/\)
>:>I know Nightmare allows an operation with a zero stack based on the
>:>caller's permissions.
>: If the stack is empty, how do you know who the caller was? Or do you
>: mean "If the only object in the stack is the previous_object() to the
>: call to the security system"?
That's what I thought too, which is why your "zero stack" comment
confused me.
>#2: Ff the only object is previous_object(), then the entire operation
>is based solely on previous_object(). Why is one object on the call
>stack different from ten?
I agree with that entirely, one object is treated no differently than
ten objects (except that more processing is involved to check each of
the ten objects).
>:>: Sure I know
>:>: in the callback itself who called it, that's not the problem. From
>:>: the point of view of the callback, who called it is irrelevant because
>:>: the normal operation of the security system will prevent unauthorised
>:>: file access anyway.
>Then the system is flawed. You are treating something differently
>that is conceptually no different from other situations.
Nothing is treated differently, the security handler treats every
call in exactly the same way.
>:>From the security system point of view, the object to which the
>:>callback is made is the only object involved in the operation.
>:>The file succeeds or fails on that object's authority.
>: Yes, that's the problem. The menu-interface object (i.e. the object
>: in which the input_to callback exists) does not have authority to
>: write files anywhere (except publically writeable directories).
>
>Then that is simply a problem with your security system, not a problem
>with all_previous_objects() or input_to().
>
>Your menu interface object should be a priveledged object that is
>designed to manage security for itself.
This would violate principle #2 that you agreed with below (that no
extra work be needed in other objects in order to be secure). It's
also impossible to implement since my security system was deliberately
designed to have no concept of "global access" and such a tool would
need to be given global access to manage security for itself.
(There is no "global access" because (a) it's putting all your
eggs in one basket - someone hacks global access and they can
do anything; and (b) it's not necessary for anything in the mud).
I don't believe in giving objects security permissions and I avoid
it whenever possible. Permissions are for people, not for objects.
There are a few special cases to cover things like logging, sending
mail, posting to boards etc, but in these circumstances the object
in question has access only to a very specific place (/log, /mail
etc.) and in very specific circumstances.
As soon as I allow the interface object to manage security for
itself, that object becomes a security risk. The possibility is
opened that that object can be fooled by someone into doing
something that that person should not be able to do. If the
security is left to the security system then that person can
never do anything that they don't have access to do.
>: No, this is my point. It shouldn't always fail. It should succeed
>: or fail based on the authorities of the player who is using the
>: menu-interface.
>Here is a weakness in your security system. If adding the player
>object to the call stack makes a difference, then your security system
>a) is not a stack based security system and b) can be fooled simply by
>finding a way to get a priveldged player's object onto the call stack.
It is not sufficient merely to get a privileged player's object onto the
call stack. That player's object would have to be at the top of the
stack (that is to say the furthest object the call can be traced to)
and there must be no other object on the stack that isn't considered
trustworthy in the current context. That means no objects that aren't
in the "trusted" security group (which contains things like mudlib
command objects etc) or in the "secure" security group (which contains
things defined to be as secure as the security handler) and it means
no objects that aren't 'owned' by (in the personal directory of) the
priviledged player. There must also be no destructed objects in the
stack at any point.
This is certainly non-trivial to fool. I haven't managed it yet,
though admittedly I'm not an expert in manipulating call stacks. :)
Note that "trusted" or "secure" status does not imply any particular
security access for an object - the vast majority of even "secure"
objects have no access to anything. It simply means that the object
is permitted to be present on the call stack even if not owned by
the caller.
>In stack based security, an operation should succeed or fail based on
>the permissions of the entire stack.
Yes.
>Now, you have not explicitly said your system is stack. I have
>assumed that from some of the stuff you have said about it. The
>point, however, is if it is stack based, you have implemented a stack
>based system wrong. If it is not stack based, then you are writing a
>security system wrong.
It is stack based. I've discussed it here before, though it's been
modified since then as a result of that discussion. Hopefully the
above description will clarify it.
>I am not sure how Lima handles this, but on Nightmare, all file
>manipulation tools are priveledged objects. Because the security
>system is stack security, however, people are only able to use these
>tools with their permissions.
That's how it should work because the interface object has "trusted"
status and thus any person should be able to use this tool with any
security checks using their own permissions.
>The problem arises when such a tool needs to perform an operation from
>a callback. In such cases, the tool needs to make security calls to
>protect itself *before* calling input_to() (or any thing else that
>causes a callback to be called at some point) with user entered data.
This violates principle #2 as you are making the object do extra work
in order to be secure.
>Now, it is true that these are extra operations not required in normal
>security contexts. This is, however, ok. You know you are in a
>special security context in writing this tool.
I don't agree that the tool is a special security context. It is
only a "special context" because the player is not a previous object
in a standard input_to() callback.
This is not a problem with the tool or with the security system,
it's a consequence of how input_to() works. Hence I have corrected
the problem by changing the way input_to() works.
>It is also possible that this could be designed by making this menu
>object an inheritable of the player object, and thus the object
>requesting permissions is the player object itself.
Now that I would call a hack. :)
>: It's questionable in my opinion because it's a way for coders
>: to do operations without appearing in the call stack.
>How can somone call an operation without appearing in the call stack?
>They called the method which calls input_to()... all things can be
>checked at that point.
This requires the object to do extra work to be secure. Since I cannot
guarentee that anyone coding objects will remember to do the extra
work, I stick to principle #2 and don't require any extra work
to be needed.
:>: 1) That all security access levels are determined only by the
:>: security system itself, and
:>: 2) That no extra work be needed in other objects in order to
:>: be secure, and
:>: 3) That information from any objects not defined to be "as
:>: secure as the security handler" cannot be trusted.
:>Lima and Nightmare have managed to create security systems that meet
:>all three goals and are quite secure.
Nightmare might be quite secure, however from what you say above
it definitely does not meet goal 2.
>:>: The input_to callback has no security checking at all, despite
>:>: the fact that it does a file write. Why? Because it doesn't matter
>:>: who called it - whatever it was, that object's access level will
>:>: be used by the security handler to allow or disallow the file
>:>: write.
>:>This is a HUGE bug.
>: Why? Please give an example of how it could be abused or is insecure?
>Because permissions should not be determined by an individual object
>on the call stack.
IMO, permissions should never be determined by an object that is not
present on the command stack. Judging by what you say above, Nightmare
does do this.
>A security system designed this way is somewhere
in security between this_player() and previous_object() based
>security. Like I said above, to fake permissions, you just need to
>shove the proper object somewhere into the call stack.
Insufficient. You must shove the proper object at the top of the stack,
make sure no object between that one and the security handler is not
untrustworthy in the context of the call, and make sure there are no
destructed objects on the stack.
>: That's exactly how it works, yes. You seem to be repeatedly missing
>: the point - the file write is disallowed because the tool in which
>: the callback exists in which the file write is done DOES NOT HAVE
>: and SHOULD NOT HAVE access to write files.
>No, you are missing the point. If it does not have permissions in the
>case of input_to(), it should no more have permissions when the player
>is directly in the call stack.
That's correct, the tool has no permissions regardless of what else
is in the stack. In the case of the standard input_to() callback, the
call cannot be traced back further than the tool, the tool has no
permissions so the call is disallowed. In the case where the callback
is called from process_input(), the call cannot be traced back farther
than the player, so the player's permissions are used. The call is then
allowed or disallowed depending on the player's permissions providing
all other objects in the stack are trustworthy. The tool is trusted.
>Because no one object on the stack should *enhance* permissions unless
>that object is the object requesting the operation AND that object has
>requested that object be performed in a special security context (for
>example, a security context in which only its permissions are
>considered).
I agree with that, and my system follows it. I allow only one special
security context however, and that is where an object has been given
a permission of "special" on a particular thing - in which case
all objects before that object in the call stack are ignored.
>Individual objects on the call stack should only have the power to
>maintain the current permissions or weaken them.
Yes, that's exactly how it works. However, there being no concept
of a privileged object with global permissions it is impossible
to weaken permissions to the player's level. Thus the player must be
the originator, and the permissions therefore start off at their
level and can be maintained or weakened by anything else present.
>And never should an
>external object change the security context of an operation performed
>by a different object (i.e. the player object change the security
>context of an operation being performaed by the menu object).
I agree again. This means that the player must be part of the context
of the operation - which isn't true of the standard input_to()
callback.
:>: I've solved the problem now by replacing input_to with a mudlib
:>: equivalent checked for and called from process_input() in the
:>: player.
[snip]
>Having said that, the issues you have brought up are not issues with
>respect to that system. Thus, if your input_to() workaround is
>designed to deal with the issue of who is on the call stack, then it
>is a hack in the sense that it was done to fix a problem with one
>system (the input_to system) that is really a problem with security
>system and it now masks the problem with the security system.
I remain unconvinced that there is any problem with the security
system. :) Once I open for play-testing (later this year assuming
real-life doesn't slow down mud development) you'll be welcome
to come and try to break it for me.
--
Scatter ///\oo/\\\
George Reese
:>designed to manage security for itself.
: This would violate principle #2 that you agreed with below (that no
: extra work be needed in other objects in order to be secure).
I guess I should ammend that then. No extra work should be required
for objects not related to security. Objects designed to provide
*general* file access are in fact part of the security system. Just
like the file manipulation library calls in UNIX.
: It's
: also impossible to implement since my security system was deliberately
: designed to have no concept of "global access" and such a tool would
: need to be given global access to manage security for itself.
The security system itself, however, does inherently have a concept of
global access. For example, your menu object *does* have global
access. It is able to write to secure files.
: (There is no "global access" because (a) it's putting all your
: eggs in one basket - someone hacks global access and they can
: do anything; and (b) it's not necessary for anything in the mud).
If someone hacks your security system, they can do anything. And
again, general file access objects like the menu object are part of
that system.
And clearly it is necessary for such things on the mud, hence Ellery's
concept of unguarded access in a stack environment :)
: I don't believe in giving objects security permissions and I avoid
: it whenever possible. Permissions are for people, not for objects.
Actually, that is completely false. People are objects. The entire
game is made up of an interaction of objects. Only sometimes are
those interactions initiated by a user.
Under your system, for example, it would be impossible to create an
online code editor that interacts with the mud via sockets. In that
scenario, you have objects needing file access but no player logged in
to associate with that file access.
Other examples would be mud tools that work via a heart beat or call out.
Objects require permissions, not people.
: There are a few special cases to cover things like logging, sending
: mail, posting to boards etc, but in these circumstances the object
: in question has access only to a very specific place (/log, /mail
: etc.) and in very specific circumstances.
Now you have violated your principle #2.
: As soon as I allow the interface object to manage security for
: itself, that object becomes a security risk.
But the object is a security-related object. Security-related objects
are few in number on the mud and should be handled by a single person
who knows what they are doing.
If you don't know what you are doing (you in the general sense, I am
not taking a shot at YOU :)), you will not be able to secure your
security system no matter how it is written.
A security system should make it possible for the people who code the
other pieces of the game not to worry about security. But that does
not mean that you can avoid worrying about security from within the
security system itself. And, again, I contend that a general file
access object is part of the security system.
: The possibility is
: opened that that object can be fooled by someone into doing
: something that that person should not be able to do. If the
: security is left to the security system then that person can
: never do anything that they don't have access to do.
If it is stack security, it cannot be fooled by anyone into doing
anything. The only weakness is where it performs general file access
calls within a callback routine. Thus you only need do one of two
things:
* protect the call to input_to() with appropriate security calls
or
* avoid using callbacks
You have done the latter and that does make your security system
work. The problem I have with your system is that it allows the
presence of a single object on the stack to *raise* permissions of the
stack.
:>: No, this is my point. It shouldn't always fail. It should succeed
:>: or fail based on the authorities of the player who is using the
:>: menu-interface.
:>Here is a weakness in your security system. If adding the player
:>object to the call stack makes a difference, then your security system
:>a) is not a stack based security system and b) can be fooled simply by
:>finding a way to get a priveldged player's object onto the call stack.
: It is not sufficient merely to get a privileged player's object onto the
: call stack. That player's object would have to be at the top of the
: stack (that is to say the furthest object the call can be traced to)
: and there must be no other object on the stack that isn't considered
: trustworthy in the current context.
Basically, this_player(1);
: That means no objects that aren't
: in the "trusted" security group (which contains things like mudlib
: command objects etc) or in the "secure" security group (which contains
: things defined to be as secure as the security handler) and it means
: no objects that aren't 'owned' by (in the personal directory of) the
: priviledged player. There must also be no destructed objects in the
: stack at any point.
You are saying that objects in the directory of an admin have the
permissions of the admin? That is a security hole as well.
: This is certainly non-trivial to fool. I haven't managed it yet,
: though admittedly I'm not an expert in manipulating call stacks. :)
It is harder than I thought, but, again, it still raises the
permissions of a stack based on an individual object.
: Note that "trusted" or "secure" status does not imply any particular
: security access for an object - the vast majority of even "secure"
: objects have no access to anything. It simply means that the object
: is permitted to be present on the call stack even if not owned by
: the caller.
:>In stack based security, an operation should succeed or fail based on
:>the permissions of the entire stack.
: Yes.
But your system violates this. It allows objects on the stack that do
not have permission to do X nevertheless perform X if another object
is in the right place on the stack.
Furthermore, if I understand the comment about admin directories
properly, it allows objects with minimal permissions to write to
directories that create objects with higher permissions.
:>The problem arises when such a tool needs to perform an operation from
:>a callback. In such cases, the tool needs to make security calls to
:>protect itself *before* calling input_to() (or any thing else that
:>causes a callback to be called at some point) with user entered data.
: This violates principle #2 as you are making the object do extra work
: in order to be secure.
I don't think it violates this principle since I believe such an
object to be part of the security system. Plus, we both agree that
using a different input tool than input_to() is better anyways,
something that coincidentally solves the problem for the menuing system.
:>Now, it is true that these are extra operations not required in normal
:>security contexts. This is, however, ok. You know you are in a
:>special security context in writing this tool.
: I don't agree that the tool is a special security context. It is
: only a "special context" because the player is not a previous object
: in a standard input_to() callback.
I consider the security system itself to be in a special security
context.
: This is not a problem with the tool or with the security system,
: it's a consequence of how input_to() works. Hence I have corrected
: the problem by changing the way input_to() works.
It is not a problem specific to input_to(). It is a problem with any
execution stack not originated by a player action. input_to() is just
one of many, and it happens to be one that is easily replaceable (and
where replacement is desireable for other reasons).
You will encounter the same problem with socket callbacks, DNS lookup
callbacks, and call outs.
Thus, you have not really corrected the problem.
:>It is also possible that this could be designed by making this menu
:>object an inheritable of the player object, and thus the object
:>requesting permissions is the player object itself.
: Now that I would call a hack. :)
If it is a hack, then I do not understand your menu system.
Why is inheriting support for a menu interface not something that
belongs to being a player object? After all, the player object
generally contains the game UI elements in an LPC environment.
:>: It's questionable in my opinion because it's a way for coders
:>: to do operations without appearing in the call stack.
:>How can somone call an operation without appearing in the call stack?
:>They called the method which calls input_to()... all things can be
:>checked at that point.
: This requires the object to do extra work to be secure. Since I cannot
: guarentee that anyone coding objects will remember to do the extra
: work, I stick to principle #2 and don't require any extra work
: to be needed.
That principle applies to systems outside of the security system where
you want to allow people 'who might not remember to do the extra work'
to code things. You do not want to allow access to such people for
security-related objects, such as an object that provides general file
system access.
: :>: 1) That all security access levels are determined only by the
: :>: security system itself, and
: :>: 2) That no extra work be needed in other objects in order to
: :>: be secure, and
: :>: 3) That information from any objects not defined to be "as
: :>: secure as the security handler" cannot be trusted.
: :>Lima and Nightmare have managed to create security systems that meet
: :>all three goals and are quite secure.
: Nightmare might be quite secure, however from what you say above
: it definitely does not meet goal 2.
I do not think it does if you recognize it as part of the security system.
:>:>: The input_to callback has no security checking at all, despite
:>:>: the fact that it does a file write. Why? Because it doesn't matter
:>:>: who called it - whatever it was, that object's access level will
:>:>: be used by the security handler to allow or disallow the file
:>:>: write.
:>:>This is a HUGE bug.
:>: Why? Please give an example of how it could be abused or is insecure?
:>Because permissions should not be determined by an individual object
:>on the call stack.
: IMO, permissions should never be determined by an object that is not
: present on the command stack. Judging by what you say above, Nightmare
: does do this.
No, it does not. Security is never influenced by objects not on the
call stack.
:>A security system designed this way is somewhere
: in security between this_player() and previous_object() based
:>security. Like I said above, to fake permissions, you just need to
:>shove the proper object somewhere into the call stack.
: Insufficient. You must shove the proper object at the top of the stack,
: make sure no object between that one and the security handler is not
: untrustworthy in the context of the call, and make sure there are no
: destructed objects on the stack.
This is slightly more secure than this_player(1) security.
:>Because no one object on the stack should *enhance* permissions unless
:>that object is the object requesting the operation AND that object has
:>requested that object be performed in a special security context (for
:>example, a security context in which only its permissions are
:>considered).
: I agree with that, and my system follows it. I allow only one special
: security context however, and that is where an object has been given
: a permission of "special" on a particular thing - in which case
: all objects before that object in the call stack are ignored.
Your system does not follow it. It enhances the access of the menu
object based on the presence of a given player at the beginning of the
call stack.
:>Individual objects on the call stack should only have the power to
:>maintain the current permissions or weaken them.
: Yes, that's exactly how it works. However, there being no concept
: of a privileged object with global permissions it is impossible
: to weaken permissions to the player's level. Thus the player must be
: the originator, and the permissions therefore start off at their
: level and can be maintained or weakened by anything else present.
And that is a flaw in an environment where a player is not always the
originator of an execution stack. LPMuds are such an environment.
:>And never should an
:>external object change the security context of an operation performed
:>by a different object (i.e. the player object change the security
:>context of an operation being performaed by the menu object).
: I agree again. This means that the player must be part of the context
: of the operation - which isn't true of the standard input_to()
: callback.
Where do you come to this conclusion? The player object is external
to the menu object. The menu object is requesting permission to write
to a file. Its security context is changed by the presence of the
external player object in the stack. That is problematic.
John Adelsberger
Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: George Reese <bo...@imaginary.com> writes:
: >Now, it is true that these are extra operations not required in normal
: >security contexts. This is, however, ok. You know you are in a
: >special security context in writing this tool.
: I don't agree that the tool is a special security context. It is
: only a "special context" because the player is not a previous object
: in a standard input_to() callback.
Scatter is correct beyond any possibility of rational debate, and here's
why: the 'security context' here is an ordinary file operation caused by
ordinary circumstances - the ONLY difference between this and 'nonspecial'
situations is that LPC's lame input_to() is a hideously poor matchup with
stack based security, and the proper answer from an architectural point
of view, since stack based security is such a good idea, is to replace
input_to() with something that works sanely.
: >It is also possible that this could be designed by making this menu
: >object an inheritable of the player object, and thus the object
: >requesting permissions is the player object itself.
: Now that I would call a hack. :)
No kidding. It is amusing to me the way in which Mr. Reese and, to a
lesser extent, Beek, will argue for any lame hack imaginable if it means
not having to rework the driver, but claim that their libs are better
than others because of the lack of hacks and the 'design.' Lima is an
amazing achievement, and if Dead Souls is typical of modern NM, it isn't
a bad piece of work either, but I'm reminded of my arguments with friends
about how it is silly to put OS code into applications - in this case,
it is silly to hack what should be language/environment features into
your lib - such as, say, decent input handling:)
Scatter ///oo/\
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>: George Reese <bo...@imaginary.com> writes:
>:>Your menu interface object should be a priveledged object that is
>:>designed to manage security for itself.
>: This would violate principle #2 that you agreed with below (that no
>: extra work be needed in other objects in order to be secure).
>
>I guess I should ammend that then. No extra work should be required
>for objects not related to security. Objects designed to provide
>*general* file access are in fact part of the security system. Just
>like the file manipulation library calls in UNIX.
The object in question, simply provides a quick and easy way to do
things that can be done in other ways. It does not provide file access
it just uses it. Saying it should be part of the security system is
therefore like saying emacs should be part of the UNIX security since
it "provides" access to files...
>: It's
>: also impossible to implement since my security system was deliberately
>: designed to have no concept of "global access" and such a tool would
>: need to be given global access to manage security for itself.
>The security system itself, however, does inherently have a concept of
>global access.
No, it honestly doesn't. There is no way an object can have access to
everything unless someone specifically grants it access to every
individual security profile in turn. Even the security handler itself
does not have access to everything.
>For example, your menu object *does* have global
>access. It is able to write to secure files.
The menu object has no access. It is not able to write to secure files.
Players are able to write to secure files via the menu object providing
they have permission to do so.
>And clearly it is necessary for such things on the mud, hence Ellery's
>concept of unguarded access in a stack environment :)
Ellery's security system is based on a completely different concept
of what security permissions are and how they are assigned.
>: I don't believe in giving objects security permissions and I avoid
>: it whenever possible. Permissions are for people, not for objects.
>Actually, that is completely false. People are objects.
Now we are venturing into the realms of the absurd. People are living
beings in the real world. People are represented within the mud by
an object, sure. Which object? /obj/user/player.c in my case. But
People are a special case. A person is a specific instance of a
specific object.
When you assign security permissions to a (non-player) object, do
you assign them to /fu/bar/thing#213? No... certainly not in my
system. You assign them to /fu/bar/thing.c and things cloned or
loaded from that file gain that access level.
This is not the case with players - they are a completely different
issue. You can't assign their permissions to /obj/user/player.c
or everyone would have to share one set of permissions. In addition
you can't assign permissions to /obj/user/player#432 which the
player happens to currently be represented by since that player
may well be represented by /obj/user/player#578 only a few minutes
later.
It's blatantly clear to me that people and objects are very
different in terms of assigning permissions. As far as my
security is concerned, an object is uniquely identified by
its file name whereas a player requires a unique name in
combination with a specific file name.
>Under your system, for example, it would be impossible to create an
>online code editor that interacts with the mud via sockets. In that
>scenario, you have objects needing file access but no player logged in
>to associate with that file access.
Rubbish. It's not impossible. If it was then my FTP daemon wouldn't
work since people are able to upload and save files through it
without any requirement to be logged in via telnet.
All that is needed for this to work is for the FTP object to
represent a player, just like the "user" object can represent
a player. Just as a filename of "/obj/user/player.c" and a name
of "scatter" identifies an object as a player object, so can a
filename of "/secure/ftpd.c" plus a name of "scatter".
>Other examples would be mud tools that work via a heart beat or call out.
>Objects require permissions, not people.
The only time objects require permissions is no person is involved.
>: There are a few special cases to cover things like logging, sending
>: mail, posting to boards etc, but in these circumstances the object
>: in question has access only to a very specific place (/log, /mail
>: etc.) and in very specific circumstances.
>Now you have violated your principle #2.
Nope, none of these objects need any extra work in order to be secure.
None of them do any security checking of their own. They rely on
the security system to do its work in the background.
>: As soon as I allow the interface object to manage security for
>: itself, that object becomes a security risk.
>But the object is a security-related object.
No it's not. It's just an extra way to access some commands.
>Security-related objects
>are few in number on the mud and should be handled by a single person
>who knows what they are doing.
I agree with that 100%. However this particular object is not one
of them.
>If you don't know what you are doing (you in the general sense, I am
>not taking a shot at YOU :)), you will not be able to secure your
>security system no matter how it is written.
I agree with that too, though I have no plans to release the lib
so it doesn't really bother me. :)
[snip]
>The problem I have with your system is that it allows the
>presence of a single object on the stack to *raise* permissions of the
>stack.
Your alternative is to start with the highest level of permission
possible and then try to lower it. I don't see how that can be
any better. The level you are starting with is vastly higher than
anything my system could raise permissions to.
>: It is not sufficient merely to get a privileged player's object onto the
>: call stack. That player's object would have to be at the top of the
>: stack (that is to say the furthest object the call can be traced to)
>: and there must be no other object on the stack that isn't considered
>: trustworthy in the current context.
>Basically, this_player(1);
In the case of a player originated call, yes this_player(1) should be
the furthest object the call can be traced to. The caveat is what
else is on the stack and whether it is trusted or not.
>: That means no objects that aren't
>: in the "trusted" security group (which contains things like mudlib
>: command objects etc) or in the "secure" security group (which contains
>: things defined to be as secure as the security handler) and it means
>: no objects that aren't 'owned' by (in the personal directory of) the
>: priviledged player. There must also be no destructed objects in the
>: stack at any point.
>You are saying that objects in the directory of an admin have the
>permissions of the admin? That is a security hole as well.
No, I'm saying that objects in the directory of a person are permitted
to be in the call stack of a call originated by that person without
causing the security handler to disallow the call.
Objects never have any "default" access permissions. They only ever
have access that has been specifically granted to them (and it is
rare to need to do so).
>: This is certainly non-trivial to fool. I haven't managed it yet,
>: though admittedly I'm not an expert in manipulating call stacks. :)
>It is harder than I thought, but, again, it still raises the
>permissions of a stack based on an individual object.
The operation should succeed or fail ultimately based on whether
the object trying to do something has an access level that permits
it. There are two ways to reach that access level. You can either
start with global access and work down (your system) or you can
start with null access and work up (my system).
We'll have to agree to disagree on which method is "better". I
think mine is because it can never work up past the access level
of the object that initially requested something to be done.
>: Note that "trusted" or "secure" status does not imply any particular
>: security access for an object - the vast majority of even "secure"
>: objects have no access to anything. It simply means that the object
>: is permitted to be present on the call stack even if not owned by
>: the caller.
This was the important point you missed before.
>:>In stack based security, an operation should succeed or fail based on
>:>the permissions of the entire stack.
>: Yes.
>But your system violates this. It allows objects on the stack that do
>not have permission to do X nevertheless perform X if another object
>is in the right place on the stack.
It allows objects on the stack to do something that they themselves
do not have access to do alone if, and only if, the operation in
question was initially requested by an object that does have access
to do it AND the object doing the operation is trusted AND all other
objects in the stack are trusted.
>Furthermore, if I understand the comment about admin directories
>properly, it allows objects with minimal permissions to write to
>directories that create objects with higher permissions.
Only if the object with minimal permissions is requested to
do the write by an object with permission to write to that
directory and only if all objects in the call stack are
trusted.
With respect to being trusted, creator home directories are a
special case. They are considered trusted only in a call
originating from their owning creator. This allows a creator
to code and use his own tools but prevents them being loaded
from their directory and used by a different creator. That
second creator must copy the tool to their own directories
before they could use it.
>:>The problem arises when such a tool needs to perform an operation from
>:>a callback. In such cases, the tool needs to make security calls to
>:>protect itself *before* calling input_to() (or any thing else that
>:>causes a callback to be called at some point) with user entered data.
>: This violates principle #2 as you are making the object do extra work
>: in order to be secure.
>I don't think it violates this principle since I believe such an
>object to be part of the security system.
I don't believe that any object that needs to use a callback should
become part of the security system.
>: I don't agree that the tool is a special security context. It is
>: only a "special context" because the player is not a previous object
>: in a standard input_to() callback.
>I consider the security system itself to be in a special security
>context.
The security system itself is contained within one object (apart from
valid_* calls etc which the driver calls in the master). So the
special security context simply means that nothing in the mud is
permitted to edit that one file.
>: This is not a problem with the tool or with the security system,
>: it's a consequence of how input_to() works. Hence I have corrected
>: the problem by changing the way input_to() works.
>It is not a problem specific to input_to(). It is a problem with any
>execution stack not originated by a player action. input_to() is just
>one of many, and it happens to be one that is easily replaceable (and
>where replacement is desireable for other reasons).
It's potentially a problem with any call not originated by a
player object.
>You will encounter the same problem with socket callbacks,
Socket callbacks that need to something sensitive such as write
files are exclusively within player representing objects (such
as the user object, or the ftp object as mentioned above).
>DNS lookup callbacks,
Potentially, though at present I have none that do anything
sensitive and no need for any that do.
> and call outs.
This is the most likely place I'll run into it again.
>Thus, you have not really corrected the problem.
The problem was simply that a player triggers an action (by
typing something in following an input_to()) but doesn't appear
on the call stack as the originator of the call to do the
action.
In the call_out scenario I'm happy to accept that the object
containing the call_out is originating the action rather than
the object that originated the call that set up the call_out.
So my security system's current behaviour is correct in the
case of call_out callbacks and not a problem.
>:>It is also possible that this could be designed by making this menu
>:>object an inheritable of the player object, and thus the object
>:>requesting permissions is the player object itself.
>: Now that I would call a hack. :)
>If it is a hack, then I do not understand your menu system.
>Why is inheriting support for a menu interface not something that
>belongs to being a player object?
Inheriting support for a menu interface is exactly what I've
done by adding input_to() replacement code. However, inheriting
the menu interface object itself smacks of "quick and dirty"
and will only work in this specific case rather than in all
general cases.
>: :>: 2) That no extra work be needed in other objects in order to
>: :>: be secure, and
>: Nightmare might be quite secure, however from what you say above
>: it definitely does not meet goal 2.
>
>I do not think it does if you recognize it as part of the security system.
I don't consider everything that calls write_file to be part of the
security system. :)
>: IMO, permissions should never be determined by an object that is not
>: present on the command stack. Judging by what you say above, Nightmare
>: does do this.
>No, it does not. Security is never influenced by objects not on the
>call stack.
Sorry, but it you've said that it is. You've said that in Nightmare
an input_to() callback, in which the player is not present on the
call stack, can carry out an operation using the player's permissions.
>:>Because no one object on the stack should *enhance* permissions unless
>:>that object is the object requesting the operation AND that object has
>:>requested that object be performed in a special security context (for
>:>example, a security context in which only its permissions are
>:>considered).
>: I agree with that, and my system follows it.
>
>Your system does not follow it. It enhances the access of the menu
>object based on the presence of a given player at the beginning of the
>call stack.
The access level of the menu object is (a) irrelevant and (b) ignored by
the security system. The security system considers the operation to
have been requested by the originating object. The fact that the
originating object asked another object to perform the operation
instead of doing it itself is unimportant.
All that is asked is:
1) Is the originating object permitted to do what it is requesting?
2) Are all the objects which are being used to carry out this
request trusted to carry out the request accurately?
>:>And never should an
>:>external object change the security context of an operation performed
>:>by a different object (i.e. the player object change the security
>:>context of an operation being performaed by the menu object).
>:
>: I agree again. This means that the player must be part of the context
>: of the operation - which isn't true of the standard input_to()
>: callback.
>
>Where do you come to this conclusion? The player object is external
>to the menu object. The menu object is requesting permission to write
>to a file. Its security context is changed by the presence of the
>external player object in the stack. That is problematic.
We're working on different assumptions as to what constitutes the
context of a call.
The player object is external to the menu object. The menu object
is requesting permission to write to a file BECAUSE it was requested
to do so by the player object. That makes the player object part
of the context of the call. The context is represented as far
as the security system is concerned by the call stack, therefore
the player object must be represented in the call stack as the
originator of the request.
Despite the disagreements, I'm enjoying this discussion - at
least it's making me think hard about my system and whether
or not it is flawed. :)
--
Scatter ///\oo/\\
George Reese
:>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
:>: George Reese <bo...@imaginary.com> writes:
:>:>Your menu interface object should be a priveledged object that is
:>:>designed to manage security for itself.
:>: This would violate principle #2 that you agreed with below (that no
:>: extra work be needed in other objects in order to be secure).
:>
:>I guess I should ammend that then. No extra work should be required
:>for objects not related to security. Objects designed to provide
:>*general* file access are in fact part of the security system. Just
:>like the file manipulation library calls in UNIX.
: The object in question, simply provides a quick and easy way to do
: things that can be done in other ways. It does not provide file access
: it just uses it. Saying it should be part of the security system is
: therefore like saying emacs should be part of the UNIX security since
: it "provides" access to files...
They are very different things. The problem is that you are comparing
object interactions in an object world with procedural operations in a
non-OO OS environment (I know, I started the analogy, but it falls
apart once you take it beyond the idea of a library).
:>: It's
:>: also impossible to implement since my security system was deliberately
:>: designed to have no concept of "global access" and such a tool would
:>: need to be given global access to manage security for itself.
:>The security system itself, however, does inherently have a concept of
:>global access.
: No, it honestly doesn't. There is no way an object can have access to
: everything unless someone specifically grants it access to every
: individual security profile in turn. Even the security handler itself
: does not have access to everything.
The security system itself has global access. You need global access
in order to be an arbiter of access.
:>: I don't believe in giving objects security permissions and I avoid
:>: it whenever possible. Permissions are for people, not for objects.
:>Actually, that is completely false. People are objects.
: Now we are venturing into the realms of the absurd.
Not in the least. In an LPMud system, people are represented by
objects.
: People are living
: beings in the real world. People are represented within the mud by
: an object, sure. Which object? /obj/user/player.c in my case. But
: People are a special case. A person is a specific instance of a
: specific object.
There is nothing at all peculiar about people with respect to
security.
: When you assign security permissions to a (non-player) object, do
: you assign them to /fu/bar/thing#213? No... certainly not in my
: system. You assign them to /fu/bar/thing.c and things cloned or
: loaded from that file gain that access level.
: This is not the case with players - they are a completely different
: issue. You can't assign their permissions to /obj/user/player.c
: or everyone would have to share one set of permissions. In addition
: you can't assign permissions to /obj/user/player#432 which the
: player happens to currently be represented by since that player
: may well be represented by /obj/user/player#578 only a few minutes
: later.
: It's blatantly clear to me that people and objects are very
: different in terms of assigning permissions. As far as my
: security is concerned, an object is uniquely identified by
: its file name whereas a player requires a unique name in
: combination with a specific file name.
It may be blatantly clear to you, but you have not shown it. You have
simply shown that one of the properties of player objects is that (if
they are clones) they need instance based permissions. This is not
some grandiose distinction that demands players be the main or only
security element.
:>Under your system, for example, it would be impossible to create an
:>online code editor that interacts with the mud via sockets. In that
:>scenario, you have objects needing file access but no player logged in
:>to associate with that file access.
: Rubbish. It's not impossible. If it was then my FTP daemon wouldn't
: work since people are able to upload and save files through it
: without any requirement to be logged in via telnet.
: All that is needed for this to work is for the FTP object to
: represent a player, just like the "user" object can represent
: a player. Just as a filename of "/obj/user/player.c" and a name
: of "scatter" identifies an object as a player object, so can a
: filename of "/secure/ftpd.c" plus a name of "scatter".
You have skirted the issue here. So, in the case of an online editor,
you assign permissions based on a game user. What about functions
that simply are not related to a game user?
:>Other examples would be mud tools that work via a heart beat or call out.
:>Objects require permissions, not people.
: The only time objects require permissions is no person is involved.
If a person is involved, the player object requires permissions.
:>: As soon as I allow the interface object to manage security for
:>: itself, that object becomes a security risk.
:>But the object is a security-related object.
: No it's not. It's just an extra way to access some commands.
I don't think we are going to agree on this.
: [snip]
:>The problem I have with your system is that it allows the
:>presence of a single object on the stack to *raise* permissions of the
:>stack.
: Your alternative is to start with the highest level of permission
: possible and then try to lower it. I don't see how that can be
: any better. The level you are starting with is vastly higher than
: anything my system could raise permissions to.
It is, IMHO, better because it is easier in your system to manipulate
the call stack. Specifically, all I need to do is manage to trick an
admin player object into doing something odd. Admittedly, this is not
trivial. For starters, I might find a way to write to an area that
will create an object I can trick an admin into using that will
maintain admin permissions--like the admin's home directory.
The advantage of a system where the permissions get lowered is that if
anything fishy is going on, nothing can happen.
:>You are saying that objects in the directory of an admin have the
:>permissions of the admin? That is a security hole as well.
: No, I'm saying that objects in the directory of a person are permitted
: to be in the call stack of a call originated by that person without
: causing the security handler to disallow the call.
: Objects never have any "default" access permissions. They only ever
: have access that has been specifically granted to them (and it is
: rare to need to do so).
And this is the achilles heel of your system.
Another potential place is a poorly written routine in player.c. I am
not suggesting you have any such routines. Granted, in any stack
system, a poorly written routine might cause some danger, but the
range of possibilities is greater in a system where the key is simply
causing a single object to do something.
:>: This is certainly non-trivial to fool. I haven't managed it yet,
:>: though admittedly I'm not an expert in manipulating call stacks. :)
:>It is harder than I thought, but, again, it still raises the
:>permissions of a stack based on an individual object.
: The operation should succeed or fail ultimately based on whether
: the object trying to do something has an access level that permits
: it. There are two ways to reach that access level. You can either
: start with global access and work down (your system) or you can
: start with null access and work up (my system).
: We'll have to agree to disagree on which method is "better". I
: think mine is because it can never work up past the access level
: of the object that initially requested something to be done.
I agree. I think this horse is dead.
: Inheriting support for a menu interface is exactly what I've
: done by adding input_to() replacement code. However, inheriting
: the menu interface object itself smacks of "quick and dirty"
: and will only work in this specific case rather than in all
: general cases.
Not if the meny object is written right.
:>: :>: 2) That no extra work be needed in other objects in order to
:>: :>: be secure, and
:>: Nightmare might be quite secure, however from what you say above
:>: it definitely does not meet goal 2.
:>
:>I do not think it does if you recognize it as part of the security system.
: I don't consider everything that calls write_file to be part of the
: security system. :)
I don;t either. I consider general libraries that wrap around
write_file() to be part of the security system though.
:>: IMO, permissions should never be determined by an object that is not
:>: present on the command stack. Judging by what you say above, Nightmare
:>: does do this.
:>No, it does not. Security is never influenced by objects not on the
:>call stack.
: Sorry, but it you've said that it is. You've said that in Nightmare
: an input_to() callback, in which the player is not present on the
: call stack, can carry out an operation using the player's permissions.
No, I didn't. And it most certainly cannot.
: Despite the disagreements, I'm enjoying this discussion - at
: least it's making me think hard about my system and whether
: or not it is flawed. :)
I am too (well, excepting the crap from JA3). And don't think because
I am criticizing your system what I think it is crap (which is what
JA3 clearly wants to portray me as saying).
John Adelsberger
George Reese <bo...@imaginary.com> wrote:
: I guess I should ammend that then. No extra work should be required
: for objects not related to security. Objects designed to provide
: *general* file access are in fact part of the security system. Just
: like the file manipulation library calls in UNIX.
*mumbles something about UNIX filesystem security being implemented in
the kernel, and the library 'security' being hacks due to poor
implementation of the overall design*
: The security system itself, however, does inherently have a concept of
: global access. For example, your menu object *does* have global
: access. It is able to write to secure files.
George apparently can't conceive of a system that really doesn't have
global access privileges, since he tries to define them out of
existance. Hey George - has it ever occurred to you that 'secure'
files need not all be secure in the same way? For instance, you
could break it down so that there were multiple categories of secure
files, each of which has its own credentials, and so that any access
to a file would have to be done by someone/thing with matching
credentials, and then there is no global access, period.
: If someone hacks your security system, they can do anything. And
: again, general file access objects like the menu object are part of
: that system.
Scatter's point is that the menu object does NOT provide 'general
file access.' Your view of 'The Way' notwithstanding, you're attacking
a straw man. His security system may be breakable(if he lets me at it,
I'll find out:) but your notion that any code that does file access in
any odd way is and should be part of the security system leads to way,
way too much code being above the law...
: And clearly it is necessary for such things on the mud, hence Ellery's
: concept of unguarded access in a stack environment :)
Actually, Ellery's unguarded() concept is not at all the same as global
access, or even 'general file access.' Even it cannot allow access
to a file for which no object on the stack has appropriate privilege.
: : I don't believe in giving objects security permissions and I avoid
: : it whenever possible. Permissions are for people, not for objects.
: Actually, that is completely false. People are objects. The entire
: game is made up of an interaction of objects. Only sometimes are
: those interactions initiated by a user.
Are you impaired in some way? Even if you change his statement to
'I only believe in giving security permissions to objects that correspond
to people,' he still has a damn good point - it is best to minimize to an
extreme extent violations of this guideline, even though it is impossible
to eliminate them.
: Under your system, for example, it would be impossible to create an
: online code editor that interacts with the mud via sockets. In that
: scenario, you have objects needing file access but no player logged in
: to associate with that file access.
He didn't say he never does it. He said he doesn't LIKE it. Similarly,
I try to point out your willfully ignorant obstinance on a regular basis
to prevent anyone's actually buying your silly bs, but I've got other
things I'd rather do:)
: Objects require permissions, not people.
Why don't you ask the government about that? They disagree in no uncertain
terms, and have gone so far as to mandate Scatter's viewpoint in anything
that can contain classified information... granted, that doesn't make them
right, but they _are_ amazingly successful in protecting a lot of things...
: : There are a few special cases to cover things like logging, sending
: : mail, posting to boards etc, but in these circumstances the object
: : in question has access only to a very specific place (/log, /mail
: : etc.) and in very specific circumstances.
: Now you have violated your principle #2.
No, he hasn't. His security system has a general purpose mechanism to
allow for this - the object doesn't have any special code at all.
In my opinion, this is a flaw, because it means that he can give
special privilege to an object which might be writable by any number
of morons, but this isn't the same point.
: : As soon as I allow the interface object to manage security for
: : itself, that object becomes a security risk.
: But the object is a security-related object. Security-related objects
: are few in number on the mud and should be handled by a single person
: who knows what they are doing.
Good idea. A single person. That's how everyone does security. We
wouldn't want to chance anyone finding our mistakes, would we?:-) My
security system, before I am done, will have been desk checked _and_
torture tested by several competent individuals...
: You have done the latter and that does make your security system
: work. The problem I have with your system is that it allows the
: presence of a single object on the stack to *raise* permissions of the
: stack.
Does it? I'm not sure, but if it does, that _is_ a problem.
: If it is a hack, then I do not understand your menu system.
: Why is inheriting support for a menu interface not something that
: belongs to being a player object? After all, the player object
: generally contains the game UI elements in an LPC environment.
Mine doesn't. The trend has been to move such things out - first it
was commands, then souls, and so forth. My user object is more like
a connection object, which is currently inherited into an object that
handles things like aliases, command concatentation, pipes, redirection,
nicknaming, and so forth - this latter object has hooks to the command
system and the stackable input system, which last is where a menu system
would reside, and will also have application hooks to support an object
containing, for instance(in the case of a typical fantasy mud) a
concept of 'character,' with hp, skills, and so forth. As far as I know,
the only major feature I lack plans for at this time is a Lima-style
shell module facility, but I don't know what I'd use it for anyway.
: : Insufficient. You must shove the proper object at the top of the stack,
: : make sure no object between that one and the security handler is not
: : untrustworthy in the context of the call, and make sure there are no
: : destructed objects on the stack.
: This is slightly more secure than this_player(1) security.
Depending on what he means by 'untrustworthy' it might be no better, and
it might be quite good, but it isn't as good as a really hardcore stack
based system if I understand correctly.
Scatter ///oo/\
[snip]
>: The object in question, simply provides a quick and easy way to do
>: things that can be done in other ways. It does not provide file access
>: it just uses it. Saying it should be part of the security system is
>: therefore like saying emacs should be part of the UNIX security since
>: it "provides" access to files...
>They are very different things. The problem is that you are comparing
>object interactions in an object world with procedural operations in a
>non-OO OS environment (I know, I started the analogy, but it falls
>apart once you take it beyond the idea of a library).
I'm not so sure it does fall apart.
user application --> OS filesystem call --> OS security --> result
emacs read() kernel data
menu object read_file() security object data
The menu object is an end-user program if you like. It's not a library
for general use. It could be something the player has custom-written
rather than something provided as a standard tool and the principle
would be the same.
>:>The security system itself, however, does inherently have a concept of
>:>global access.
>: Even the security handler itself does not have access to everything.
>The security system itself has global access. You need global access
>in order to be an arbiter of access.
No you don't. You don't need to be able to read a file in order to
be able to decide if something else is allowed to read it or not. All
you need is information on what that something else is allowed to
do and on whether the file falls into that catagory.
The only access the security handler needs is to the file that
contains its saved data. Everything else is decided based on
that security data.
To refute the statement that the security system has global access,
I present a single example of something it doesn't have access to.
The following profile exists:
({ "/secure/security.c" : ([ default : NONE ]) })
I.e. nothing, neither object nor player has been granted access
to /secure/security.c, not even the security object itself, and
the default access level for unmentioned objects is NONE - no access.
Nothing in the mud, at all, can edit this file.
>:>: I don't believe in giving objects security permissions and I avoid
>:>: it whenever possible. Permissions are for people, not for objects.
>:>Actually, that is completely false. People are objects.
[big snip]
>: It's blatantly clear to me that people and objects are very
>: different in terms of assigning permissions. As far as my
>: security is concerned, an object is uniquely identified by
>: its file name whereas a player requires a unique name in
>: combination with a specific file name.
>It may be blatantly clear to you, but you have not shown it. You have
>simply shown that one of the properties of player objects is that (if
>they are clones) they need instance based permissions.
Which is a property that makes them unique from all other objects.
>This is not some grandiose distinction that demands players be the
>main or only security element.
No, the grandiose distinction is that a player is a living person
rather than merely a few lines of code.
The player is not necessarily the main security element. The main
security element in my system is the object that originally
requested something to be done and thus initiated a sequence of
calls to carry out that request.
The security handler will permit the request providing it's
happy that the object originally requesting it is allowed to
do it and that any other objects present are trusted to pass
on the request without corrupting it or maliciously changing
it.
The players (especially creators) become the main security element
in principle because it is trivial to request an operation and
arrange things so that your player-object does not show up on
the call stack.
This means that any non-player-object that you assign security
permissions to becomes a security risk because a player can
potentially request an operation and arrange for that
non-player-object to appear to be the originator.
Hence you can minimise these risks by making sure as few
non-player-objects have security permissions as possible, thus
giving you the fewest number of risks to track and files
to keep secure from unauthorised editing.
Whilst there may be many players, each with their own set of
security permissions there are a very limited number of
player-object .c source files that need to be kept secure.
Players do things. Non-player-objects provide ways for players
to do things. Generally, non-player-objects don't do security
sensitive things by themselves.
[snip]
>You have skirted the issue here. So, in the case of an online editor,
>you assign permissions based on a game user. What about functions
>that simply are not related to a game user?
If the operation is not being triggered by a game user then there
is a non-player-object that is triggering it. I don't believe in
giving non-player-objects security permissions and I avoid it
whenever possible but that doesn't mean I believe there are no
circumstances where a non-player-object does need security permissions.
However, I can't think of an example that isn't a special case for
one reason or another. Can you give an example of such a case?
>:>But the object is a security-related object.
>: No it's not. It's just an extra way to access some commands.
>I don't think we are going to agree on this.
You're probably right there.
[snip]
>It is, IMHO, better because it is easier in your system to manipulate
>the call stack. Specifically, all I need to do is manage to trick an
>admin player object into doing something odd.
You have to trick an admin player object into doing something in
such a way that nothing appears on the call stack before the
admin player object.
Simply talking an admin into issuing a command for you is a hole
in every security system in existence, so that doesn't count IMO. :)
>Admittedly, this is not
>trivial. For starters, I might find a way to write to an area that
>will create an object I can trick an admin into using that will
>maintain admin permissions--like the admin's home directory.
The principle of objects from your own directory being considered
trustworthy in a call originated by you is a concession to
user friendliness. It's nice to be able to create your own tools
to do things.
To address your possibility, it depends upon you finding a way to
write to that special area, be it the admin's directory or a
trusted mudlib directory. There are only two ways you can do this.
1) You can be given access to that area by an admin
2) You can fool an object with access (like say, an admin player
object) into doing the write, in such a way that nothing appears
on the stack before it...
Now method (2) is obviously catch-22. Method (1) is down to talking
to the admin again. Talking an admin into believing you are
trustworthy and giving you access you intend to abuse is not
something that any security system can protect against.
>The advantage of a system where the permissions get lowered is that if
>anything fishy is going on, nothing can happen.
This is also true of my system. The permissions used for the operation
do not only get raised. They get raised once, to the level of the
originating object. After that, they can only be lowered, and
anything "fishy", i.e. a non-trusted object, will immediately lower
them to zero again.
To be honest, I'm becoming more and more convinced that this whole
disagreement is simply down to semantics since your system could
be described as raising stack permissions once to the highest level
and then lowering per each object on the stack. That's not so
different from mine except that my initial raise is smaller
than yours.
[snip]
>Another potential place is a poorly written routine in player.c. I am
>not suggesting you have any such routines. Granted, in any stack
>system, a poorly written routine might cause some danger, but the
>range of possibilities is greater in a system where the key is simply
>causing a single object to do something.
Any stack system is entirely dependent on the contents of the stack.
The key to unauthorised access is to somehow generate a stack that
satisfies the security system is valid. If you can find a way to
cause an object to do something in my system that satisfies my
stack requirements, then I'm certain the same method of stack
manipulation will be able to fool yours too.
You can fool ANY stack security system if you can untraceably make
an object with the needed permissions carry out the call to do what
you want.
>: Sorry, but it you've said that it is. You've said that in Nightmare
>: an input_to() callback, in which the player is not present on the
>: call stack, can carry out an operation using the player's permissions.
>No, I didn't. And it most certainly cannot.
Maybe I misunderstood then. You said:
>The problem arises when such a tool needs to perform an operation from
>a callback. In such cases, the tool needs to make security calls to
>protect itself *before* calling input_to() (or any thing else that
>causes a callback to be called at some point) with user entered data.
Either:
You have allowed the tool to tell the security system to let the tool
use the player's permissions despite the player not being on the call
stack. This is what I originally thought you meant.
Or:
You have given the tool global access and make the tool check the
player's permissions are sufficient - thus making the tool a
security risk. By doing this you risk bugs in the tool compromising
your security system and you require that the tool's source file
be kept as secure as that of the security system itself!
--
Scatter ///\oo/\\\
Scatter ///oo/\
>George Reese <bo...@imaginary.com> wrote:
>: Scatter wrote:
[snip]
>George apparently can't conceive of a system that really doesn't have
>global access privileges, since he tries to define them out of
>existance. Hey George - has it ever occurred to you that 'secure'
>files need not all be secure in the same way? For instance, you
>could break it down so that there were multiple categories of secure
>files, each of which has its own credentials, and so that any access
>to a file would have to be done by someone/thing with matching
>credentials, and then there is no global access, period.
That's more or less how files are protected in my system. There is
no global access within the mud at all. Of course externally to
the mud, there is.
[re: objects making calls where it is necessary to ignore the stack]
>His security system has a general purpose mechanism to
>allow for this - the object doesn't have any special code at all.
>In my opinion, this is a flaw, because it means that he can give
>special privilege to an object which might be writable by any number
>of morons, but this isn't the same point.
I don't think it's a flaw, though I'll agree it's a potential
weakness. However, the same weakness exists with respect to
any permissions given an object whether they are special (ignore
the stack) or normal (check the whole stack).
Even if an object only has normal access levels, if you can edit
it then you can add code to do a call in such a way that you
deliberately obscure the stack (e.g. call_out) and get access
that way to anything the object has access to.
This is why I dislike giving objects access permissions at all.
So this is not a flaw with the special access level specifically,
but exists in any system where something with any permissions can
be edited to unintended things.
The other point is that objects within the mudlib that have
special access to something (like the system logger, or the
mail system) are by their very nature parts of the mudlib
which I will never give anyone access to without them being
someone I trust implicitly.
Objects outside the mudlib are incredibly unlikely to have
special access to anything dangerous, especially since
profiles covering sensitive files and directories would need
a high level admin (i.e. me) to grant the permission in
the first place. :)
>: You have done the latter and that does make your security system
>: work. The problem I have with your system is that it allows the
>: presence of a single object on the stack to *raise* permissions of the
>: stack.
>Does it? I'm not sure, but if it does, that _is_ a problem.
It's a matter of semantics. From another point of view, there is
no "raise" or "lower" of permissions of the stack. The permissions
are initially set as those of the originating object and are either
used without modifcation or an untrustworthy object is present and
the call is aborted regardless of the permissions.
>: If it is a hack, then I do not understand your menu system.
>: Why is inheriting support for a menu interface not something that
>: belongs to being a player object? After all, the player object
>: generally contains the game UI elements in an LPC environment.
>Mine doesn't. The trend has been to move such things out - first it
>was commands, then souls, and so forth. My user object is more like
>a connection object, which is currently inherited into an object that
>handles things like aliases, command concatentation, pipes, redirection,
>nicknaming, and so forth - this latter object has hooks to the command
>system and the stackable input system, which last is where a menu system
>would reside, and will also have application hooks to support an object
>containing, for instance(in the case of a typical fantasy mud) a
>concept of 'character,' with hp, skills, and so forth. As far as I know,
>the only major feature I lack plans for at this time is a Lima-style
>shell module facility, but I don't know what I'd use it for anyway.
Sounds like a fairly generic system - mine's a bit more firmly bolted
to the character concept since I have no intention at this point of
distributing the lib, or using it for more than one application.
>: : Insufficient. You must shove the proper object at the top of the stack,
>: : make sure no object between that one and the security handler is not
>: : untrustworthy in the context of the call, and make sure there are no
>: : destructed objects on the stack.
>: This is slightly more secure than this_player(1) security.
>Depending on what he means by 'untrustworthy' it might be no better, and
>it might be quite good, but it isn't as good as a really hardcore stack
>based system if I understand correctly.
Trustworthy means "we trust this object to pass on a call as the
caller intended".
An untrustworthy object might for example sneakily convert a call
write_the_file( "callers data", "/w/scatter/blah.data" ) into say
write_file( "my own data", "/w/scatter/blah.data" ).
There are only two ways to be considered trustworthy - either
(a) the object must be a member of the "trusted" security group or
(b) the caller must be a player object, and the object must be
loaded from the appropriate player's own directories.
In the case of the former, membership of the "trusted" security
group is restricted to certain parts of the mudlib. The latter
exists purely to allow people to code their own tools to do things
with.
This is a weak spot and I would remove it if doing so wasn't so
user-unfriendly. Still, if you copy someone elses code into
your directory and clone and use it without checking it through
first, then you're a fool and probably deserve what you get. :)
--
Scatter ///\oo/\\\
George Reese
:>:>global access.
:>: Even the security handler itself does not have access to everything.
:>The security system itself has global access. You need global access
:>in order to be an arbiter of access.
: No you don't. You don't need to be able to read a file in order to
: be able to decide if something else is allowed to read it or not. All
: you need is information on what that something else is allowed to
: do and on whether the file falls into that catagory.
: The only access the security handler needs is to the file that
: contains its saved data. Everything else is decided based on
: that security data.
: To refute the statement that the security system has global access,
: I present a single example of something it doesn't have access to.
: The following profile exists:
: ({ "/secure/security.c" : ([ default : NONE ]) })
What prevents /secure/security.c from ignoring this?
:>You have skirted the issue here. So, in the case of an online editor,
:>you assign permissions based on a game user. What about functions
:>that simply are not related to a game user?
: If the operation is not being triggered by a game user then there
: is a non-player-object that is triggering it. I don't believe in
: giving non-player-objects security permissions and I avoid it
: whenever possible but that doesn't mean I believe there are no
: circumstances where a non-player-object does need security permissions.
: However, I can't think of an example that isn't a special case for
: one reason or another. Can you give an example of such a case?
Off the top of my head, Nightmare's report generation facilities. The
mud generates reports hourly, daily, and weekly about things that have been
going on.
:>It is, IMHO, better because it is easier in your system to manipulate
:>the call stack. Specifically, all I need to do is manage to trick an
:>admin player object into doing something odd.
: You have to trick an admin player object into doing something in
: such a way that nothing appears on the call stack before the
: admin player object.
: Simply talking an admin into issuing a command for you is a hole
: in every security system in existence, so that doesn't count IMO. :)
No, that is not the issue. You could turn an otherwise innocuous
command into something serious because an object can get onto the call
stack that is trusted, yet protected by permissions lesser than the
admins.
:>Admittedly, this is not
:>trivial. For starters, I might find a way to write to an area that
:>will create an object I can trick an admin into using that will
:>maintain admin permissions--like the admin's home directory.
: The principle of objects from your own directory being considered
: trustworthy in a call originated by you is a concession to
: user friendliness. It's nice to be able to create your own tools
: to do things.
There is no need to create secure tools in your own directory. The
most your own directory should ever need to do is write to your own
directory.
: To address your possibility, it depends upon you finding a way to
: write to that special area, be it the admin's directory or a
: trusted mudlib directory. There are only two ways you can do this.
: 1) You can be given access to that area by an admin
: 2) You can fool an object with access (like say, an admin player
: object) into doing the write, in such a way that nothing appears
: on the stack before it...
: Now method (2) is obviously catch-22. Method (1) is down to talking
: to the admin again. Talking an admin into believing you are
: trustworthy and giving you access you intend to abuse is not
: something that any security system can protect against.
For number 1 to be a catch-22, you have to say that there is no reason
on earth for lesser trusted people to have access to an admin
directory. On a mud that has aged for a while, being able to grant
access to lesser truster people to the admin's directory is a
necessity.
:>The advantage of a system where the permissions get lowered is that if
:>anything fishy is going on, nothing can happen.
: This is also true of my system. The permissions used for the operation
: do not only get raised. They get raised once, to the level of the
: originating object. After that, they can only be lowered, and
: anything "fishy", i.e. a non-trusted object, will immediately lower
: them to zero again.
: To be honest, I'm becoming more and more convinced that this whole
: disagreement is simply down to semantics since your system could
: be described as raising stack permissions once to the highest level
: and then lowering per each object on the stack. That's not so
: different from mine except that my initial raise is smaller
: than yours.
That is almost true except for the fact that you have now placed a
supremacy of the person into this environment. Given that, two things
have followed from it:
1. you have to work around the system for processing not related to the
interests of a person
2. you give special meaning to home directories in the name of support
for that person
Now, you can accept the limits those two things place on your system.
The most troublesome is how much care must be taken in guarding write
access to an admin's directory.
: [snip]
:>Another potential place is a poorly written routine in player.c. I am
:>not suggesting you have any such routines. Granted, in any stack
:>system, a poorly written routine might cause some danger, but the
:>range of possibilities is greater in a system where the key is simply
:>causing a single object to do something.
: Any stack system is entirely dependent on the contents of the stack.
: The key to unauthorised access is to somehow generate a stack that
: satisfies the security system is valid. If you can find a way to
: cause an object to do something in my system that satisfies my
: stack requirements, then I'm certain the same method of stack
: manipulation will be able to fool yours too.
: You can fool ANY stack security system if you can untraceably make
: an object with the needed permissions carry out the call to do what
: you want.
But if the files from which objects in the stack are protected by
permissions lesser than those with which the objects operate (as
would be the case for admin directories where people had access to it
as needed by most running game muds), then the stack is in jeaopardy.
:>: Sorry, but it you've said that it is. You've said that in Nightmare
:>: an input_to() callback, in which the player is not present on the
:>: call stack, can carry out an operation using the player's permissions.
:>No, I didn't. And it most certainly cannot.
: Maybe I misunderstood then. You said:
:>The problem arises when such a tool needs to perform an operation from
:>a callback. In such cases, the tool needs to make security calls to
:>protect itself *before* calling input_to() (or any thing else that
:>causes a callback to be called at some point) with user entered data.
: Either:
: You have allowed the tool to tell the security system to let the tool
: use the player's permissions despite the player not being on the call
: stack. This is what I originally thought you meant.
: Or:
: You have given the tool global access and make the tool check the
: player's permissions are sufficient - thus making the tool a
: security risk. By doing this you risk bugs in the tool compromising
: your security system and you require that the tool's source file
: be kept as secure as that of the security system itself!
Sorta the latter, but sorta neither. The latter because I consider
any tool with secure access to be part of the security system and only
people who understand the full implications of what they do are
involved in its maintainence. There is a very low propensity for
error here, because this does not involve that much code.
Nevertheless, like I mentioned elsewhere, I handle input_to()'s in a
manner similar to the one you devised anyways so for such cases as the
one being discussed here, the situation is completely irrelevant.
Khall
ever played one, but...from my experience...isn't someone hacking one
of the trusted player objects from the login sequence a lot bigger
risk than anything else? I've seen far more damage and problems caused
by an IMM having a lousy password than I have from someone hacking the
OLC (inna Diku) or shell. So I'm curious, is this not as much of a
problem in an LP? And if it is, has anyone done anything about it? Any
ideas suggestions etc. about what can be done about it? Just off the
top of my head, by say tying a character login to a site or three? So
that only those sites can login as that character or something? And
having it configurable for the occasional times when someone moves?
*shrug* Since the topic is security issues now...I thought I'd bring
this up:)
K.
Scatter ///oo/\
>Admittedly I don't know anything about LPmuds I'm not even sure I've
>ever played one, but...from my experience...isn't someone hacking one
>of the trusted player objects from the login sequence a lot bigger
>risk than anything else? I've seen far more damage and problems caused
>by an IMM having a lousy password than I have from someone hacking the
>OLC (inna Diku) or shell. So I'm curious, is this not as much of a
>problem in an LP? And if it is, has anyone done anything about it?
It is just as big a problem, possibly a bigger problem in an LP since
hacking an admin's password on an LP is likely to give you access to
the mudlib source code.
That said, I've never seen a case of someone's password being guessed -
usually something of this nature is caused by someone giving out their
password to someone else who then abuses it.
I have a few rules as to what constitutes an acceptible password
to make them harder to guess -
1) Must be at least 6 characters,
2) Must contain at least one number, but not at the start or the end
3) Must not be a readable word (e.g. w1nter or p0pular)
(1) and (2) are enforced by the system, (3) is left up to the players
discretion.
Finally, anyone caught sharing their password with anyone else
will find their character banished. No notice, no warnings.
>Any
>ideas suggestions etc. about what can be done about it? Just off the
>top of my head, by say tying a character login to a site or three? So
>that only those sites can login as that character or something? And
>having it configurable for the occasional times when someone moves?
Dialup dynamic IP addressing means that you would have to tie characters
to domains rather than specific sites, so you'd still have possibly
millions of potential hackers in the case of a big ISP. I'd imagine
this would also be a pain in the neck if you were forced to change
ISP without notice.
--
Scatter ///\oo/\\\
Scatter ///oo/\
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>: George Reese intoned these words...
>:>The security system itself has global access. You need global access
>:>in order to be an arbiter of access.
>: The only access the security handler needs is to the file that
>: contains its saved data. Everything else is decided based on
>: that security data.
>
>: To refute the statement that the security system has global access,
>: I present a single example of something it doesn't have access to.
>
>: The following profile exists:
>: ({ "/secure/security.c" : ([ default : NONE ]) })
>
>What prevents /secure/security.c from ignoring this?
The same thing that prevents /secure/master from automatically
allowing every valid_write() call. It's coded that way. It does
not treat itself as a special case.
Sure you could edit /secure/security.c so that it does automatically
allow itself to write anywhere, but then you don't have my system
anymore. My system has no global access.
>: If the operation is not being triggered by a game user then there
>: is a non-player-object that is triggering it. I don't believe in
>: giving non-player-objects security permissions and I avoid it
>: whenever possible but that doesn't mean I believe there are no
>: circumstances where a non-player-object does need security permissions.
>
>: However, I can't think of an example that isn't a special case for
>: one reason or another. Can you give an example of such a case?
>
>Off the top of my head, Nightmare's report generation facilities. The
>mud generates reports hourly, daily, and weekly about things that have been
>going on.
The report object could be given access to write to specific files, or
to a specific directory for reports. Not a problem there, such reports
are unlikely to be sensitive data. Even if the report object is
compromised, at best you could corrupt only a few reports.
Perhaps better, the report object could be told to send the reports to
someone via the mail system, or post them via the message board system.
That way the report object needs no access permissions to any files
and thus isn't a security risk at all.
>:>It is, IMHO, better because it is easier in your system to manipulate
>:>the call stack. Specifically, all I need to do is manage to trick an
>:>admin player object into doing something odd.
>: You have to trick an admin player object into doing something in
>: such a way that nothing appears on the call stack before the
>: admin player object.
>
>: Simply talking an admin into issuing a command for you is a hole
>: in every security system in existence, so that doesn't count IMO. :)
>
>No, that is not the issue. You could turn an otherwise innocuous
>command into something serious because an object can get onto the call
>stack that is trusted, yet protected by permissions lesser than the
>admins.
Yes, in theory you can deliberately screw up your security by granting
an untrustworthy person access to trusted objects like commands etc.
I think you can do this on any system, however.
>: The principle of objects from your own directory being considered
>: trustworthy in a call originated by you is a concession to
>: user friendliness. It's nice to be able to create your own tools
>: to do things.
>There is no need to create secure tools in your own directory. The
>most your own directory should ever need to do is write to your own
>directory.
However, in order for an admin to use a tool from his own directory
to write to his own directory that tool must be trusted. Otherwise
the write would be refused because an untrusted object may substitute
it's own operation for the requested one.
>For number 1 to be a catch-22, you have to say that there is no reason
>on earth for lesser trusted people to have access to an admin
>directory.
There is no reason on earth for lesser trusted people to have write access
to an admin's personal directory.
>On a mud that has aged for a while, being able to grant
>access to lesser truster people to the admin's directory is a
>necessity.
Why? An admin's personal directory is for that admin's personal files,
notes, code etc. Anything that is essential for the running of the
mud should be stored elsewhere.
>: To be honest, I'm becoming more and more convinced that this whole
>: disagreement is simply down to semantics since your system could
>: be described as raising stack permissions once to the highest level
>: and then lowering per each object on the stack. That's not so
>: different from mine except that my initial raise is smaller
>: than yours.
>That is almost true except for the fact that you have now placed a
>supremacy of the person into this environment. Given that, two things
>have followed from it:
>1. you have to work around the system for processing not related to the
>interests of a person
Nope, no work-around is needed. In those cases, the object that is
doing the processing can be granted the access needed.
>2. you give special meaning to home directories in the name of support
>for that person
>
>Now, you can accept the limits those two things place on your system.
>The most troublesome is how much care must be taken in guarding write
>access to an admin's directory.
Yes, care must be taken in guarding who writes to your directory. I'm
happy to accept that for now, though it may be something I withdraw
at some point if it becomes a problem.
--
Scatter ///\oo/\\\
George Reese
:>: George Reese intoned these words...
:>:>The security system itself has global access. You need global access
:>:>in order to be an arbiter of access.
:>: The only access the security handler needs is to the file that
:>: contains its saved data. Everything else is decided based on
:>: that security data.
:>
:>: To refute the statement that the security system has global access,
:>: I present a single example of something it doesn't have access to.
:>
:>: The following profile exists:
:>: ({ "/secure/security.c" : ([ default : NONE ]) })
:>
:>What prevents /secure/security.c from ignoring this?
: The same thing that prevents /secure/master from automatically
: allowing every valid_write() call. It's coded that way. It does
: not treat itself as a special case.
: Sure you could edit /secure/security.c so that it does automatically
: allow itself to write anywhere, but then you don't have my system
: anymore. My system has no global access.
If security.c is in fact an arbiter of access, it does have global
access since it decides whether or not to grant itself access.
:>: If the operation is not being triggered by a game user then there
:>: is a non-player-object that is triggering it. I don't believe in
:>: giving non-player-objects security permissions and I avoid it
:>: whenever possible but that doesn't mean I believe there are no
:>: circumstances where a non-player-object does need security permissions.
:>
:>: However, I can't think of an example that isn't a special case for
:>: one reason or another. Can you give an example of such a case?
:>
:>Off the top of my head, Nightmare's report generation facilities. The
:>mud generates reports hourly, daily, and weekly about things that have been
:>going on.
: The report object could be given access to write to specific files, or
: to a specific directory for reports. Not a problem there, such reports
: are unlikely to be sensitive data. Even if the report object is
: compromised, at best you could corrupt only a few reports.
: Perhaps better, the report object could be told to send the reports to
: someone via the mail system, or post them via the message board system.
: That way the report object needs no access permissions to any files
: and thus isn't a security risk at all.
Those are all hacks to get around the fundamental fact that it is the
reporting object that requires whatever access.
:>:>It is, IMHO, better because it is easier in your system to manipulate
:>:>the call stack. Specifically, all I need to do is manage to trick an
:>:>admin player object into doing something odd.
:>: You have to trick an admin player object into doing something in
:>: such a way that nothing appears on the call stack before the
:>: admin player object.
:>
:>: Simply talking an admin into issuing a command for you is a hole
:>: in every security system in existence, so that doesn't count IMO. :)
:>
:>No, that is not the issue. You could turn an otherwise innocuous
:>command into something serious because an object can get onto the call
:>stack that is trusted, yet protected by permissions lesser than the
:>admins.
: Yes, in theory you can deliberately screw up your security by granting
: an untrustworthy person access to trusted objects like commands etc.
: I think you can do this on any system, however.
The problem is that, with your system, objects to which untrustworthy
people need access are trusted. For example, game areas coded by admins.
:>: The principle of objects from your own directory being considered
:>: trustworthy in a call originated by you is a concession to
:>: user friendliness. It's nice to be able to create your own tools
:>: to do things.
:>There is no need to create secure tools in your own directory. The
:>most your own directory should ever need to do is write to your own
:>directory.
: However, in order for an admin to use a tool from his own directory
: to write to his own directory that tool must be trusted. Otherwise
: the write would be refused because an untrusted object may substitute
: it's own operation for the requested one.
The admin's directory does not need to be trusted. It just needs the
ability to write to the admin's directory on its own.
:>For number 1 to be a catch-22, you have to say that there is no reason
:>on earth for lesser trusted people to have access to an admin
:>directory.
: There is no reason on earth for lesser trusted people to have write access
: to an admin's personal directory.
Only if the admin has no areas in the game.
:>On a mud that has aged for a while, being able to grant
:>access to lesser truster people to the admin's directory is a
:>necessity.
: Why? An admin's personal directory is for that admin's personal files,
: notes, code etc. Anything that is essential for the running of the
: mud should be stored elsewhere.
If you store area files in other directories, then that is possibly
true. But you still have a problem with saving data from objects in areas.
:>2. you give special meaning to home directories in the name of support
:>for that person
:>
:>Now, you can accept the limits those two things place on your system.
:>The most troublesome is how much care must be taken in guarding write
:>access to an admin's directory.
: Yes, care must be taken in guarding who writes to your directory. I'm
: happy to accept that for now, though it may be something I withdraw
: at some point if it becomes a problem.
I cannot imagine having to be the only person on the mud that can
perform maintainence on my game areas.
Scatter ///oo/\
>Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
>: George Reese intoned these words...
>
>:>: ({ "/secure/security.c" : ([ default : NONE ]) })
>:>What prevents /secure/security.c from ignoring this?
>: The same thing that prevents /secure/master from automatically
>: allowing every valid_write() call. It's coded that way. It does
>: not treat itself as a special case.
>
>access since it decides whether or not to grant itself access.
It does not have global access. It has the potential for global
access, but the way it is coded means that it does not actually
have it.
>:>Off the top of my head, Nightmare's report generation facilities. The
>:>mud generates reports hourly, daily, and weekly about things that have been
>:>going on.
>: The report object could be given access to write to specific files, or
>: to a specific directory for reports. Not a problem there, such reports
>: are unlikely to be sensitive data. Even if the report object is
>: compromised, at best you could corrupt only a few reports.
>
>: Perhaps better, the report object could be told to send the reports to
>: someone via the mail system, or post them via the message board system.
>: That way the report object needs no access permissions to any files
>: and thus isn't a security risk at all.
>
>Those are all hacks to get around the fundamental fact that it is the
>reporting object that requires whatever access.
Huh? My first option, and the one I'd probably use, was to give the
report object the access it needed. How can that be a hack to get
around it needing access?
I went on to suggest a couple of ways the system could work without
it needing access. Actually I think posting the reports via the
message board system has a lot of potential because that way you
get visibility of the reports for those who need to see them
automatically and you get archiving and archive search facilities
all thrown in for free in addition to the report object not needing
any access permissions.
[snip]
>: Yes, in theory you can deliberately screw up your security by granting
>: an untrustworthy person access to trusted objects like commands etc.
>: I think you can do this on any system, however.
>The problem is that, with your system, objects to which untrustworthy
>people need access are trusted. For example, game areas coded by admins.
Game areas are not trusted files.
>:>There is no need to create secure tools in your own directory. The
>:>most your own directory should ever need to do is write to your own
>:>directory.
>: However, in order for an admin to use a tool from his own directory
>: to write to his own directory that tool must be trusted. Otherwise
>: the write would be refused because an untrusted object may substitute
>: it's own operation for the requested one.
>The admin's directory does not need to be trusted. It just needs the
>ability to write to the admin's directory on its own.
If it's given that access it becomes a security risk because people
other than the admin can use it in such a way that it appears first
on the call stack and thus does their dirty work for them.
>: There is no reason on earth for lesser trusted people to have write access
>: to an admin's personal directory.
>Only if the admin has no areas in the game.
Nothing that is in a personal directory is in the game. Game files
such as areas, rooms, monsters, weapons etc have their own directory
heirarchy. This heirarchy is not considered to be trusted by the
security handler.
>:>On a mud that has aged for a while, being able to grant
>:>access to lesser truster people to the admin's directory is a
>:>necessity.
>: Why? An admin's personal directory is for that admin's personal files,
>: notes, code etc. Anything that is essential for the running of the
>: mud should be stored elsewhere.
>If you store area files in other directories, then that is possibly
>true. But you still have a problem with saving data from objects in areas.
There is no problem. If it's data saved as a result of a player activity
in the game, then it's a special security context where the initial
part of the call stack needs to be ignored, so you give the object
"special" access to the file it needs to write to. If it's an
operation that is triggered by the object itself, you just give the
object access to the file it needs to write to.
Note that these access levels are specified to the individual files
whenever possible so that should the object become compromised for
any reason, potential damage is severely limited.
>: Yes, care must be taken in guarding who writes to your directory. I'm
>: happy to accept that for now, though it may be something I withdraw
>: at some point if it becomes a problem.
>I cannot imagine having to be the only person on the mud that can
>perform maintainence on my game areas.
I can't imagine I'd like that being forced on me, though I have in
the past deliberately chosen that scenario in order to avoid
incompetents breaking things. :)
--
Scatter ///\oo/\\\
John Adelsberger
: Even if an object only has normal access levels, if you can edit
: it then you can add code to do a call in such a way that you
: deliberately obscure the stack (e.g. call_out) and get access
Not that I imagine you care, but if you want to save the call stack in
call_out(), I am relatively certain it can be simul'ed:-)
Re: raising the permission of the stack:
: >Does it? I'm not sure, but if it does, that _is_ a problem.
: It's a matter of semantics. From another point of view, there is
: no "raise" or "lower" of permissions of the stack. The permissions
: are initially set as those of the originating object and are either
: used without modifcation or an untrustworthy object is present and
: the call is aborted regardless of the permissions.
What do you count as 'trustworthy?' If a trustworthy object could even
possibly be affected by any user other than yourself, you have a problem.
Re: the Voxter(my mudlib):
: Sounds like a fairly generic system - mine's a bit more firmly bolted
: to the character concept since I have no intention at this point of
: distributing the lib, or using it for more than one application.
Certainly. The Voxter's main goal is to be 'generic.'
: Trustworthy means "we trust this object to pass on a call as the
: caller intended".
So then no trustworthy object is writable by anyone save yourself and your
close friends?:)
: There are only two ways to be considered trustworthy - either
: (a) the object must be a member of the "trusted" security group or
This sounds ok...
: (b) the caller must be a player object, and the object must be
: loaded from the appropriate player's own directories.
This is a weakness. People copy others' code all the time without really
checking it.
: In the case of the former, membership of the "trusted" security
: group is restricted to certain parts of the mudlib. The latter
: exists purely to allow people to code their own tools to do things
: with.
You could improve the latter by having both 'author' and 'owner' on files
and disallowing trust to anything whose author != owner.
: This is a weak spot and I would remove it if doing so wasn't so
: user-unfriendly. Still, if you copy someone elses code into
: your directory and clone and use it without checking it through
: first, then you're a fool and probably deserve what you get. :)
Most security problems are due to fools - this is the point of a good
security system. People such as us, when hacked, find out who did it
and send large guys named Tiny and Guido to the offender's place of
business, and that's that:)
John Adelsberger
: Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: : To refute the statement that the security system has global access,
: : I present a single example of something it doesn't have access to.
: : The following profile exists:
: : ({ "/secure/security.c" : ([ default : NONE ]) })
: What prevents /secure/security.c from ignoring this?
Probably valid_write(). Granted, valid_write() can be considered a part
of the security system, and your claim that security systems must have
global access is probably true by definition rather than need, but there
is no need that /secure/security.c be able to write or read _anything._
: : However, I can't think of an example that isn't a special case for
: : one reason or another. Can you give an example of such a case?
: Off the top of my head, Nightmare's report generation facilities. The
: mud generates reports hourly, daily, and weekly about things that have been
: going on.
Why do these need special access to the filesystem? Sounds like something
that ought to be going through a smart log daemon to me.
: There is no need to create secure tools in your own directory. The
: most your own directory should ever need to do is write to your own
: directory.
Actually, this depends heavily on lib design, but hey, never let the
facts ruin a good generalization:)
: For number 1 to be a catch-22, you have to say that there is no reason
: on earth for lesser trusted people to have access to an admin
: directory. On a mud that has aged for a while, being able to grant
: access to lesser truster people to the admin's directory is a
: necessity.
Actually, I have to question why anyone but the admin needs anything
but read access to his own homedir.
John Adelsberger
Khall <jpr...@a.saner.side.of.neverland.gte.net> wrote:
: Admittedly I don't know anything about LPmuds I'm not even sure I've
: ever played one, but...from my experience...isn't someone hacking one
: of the trusted player objects from the login sequence a lot bigger
: risk than anything else? I've seen far more damage and problems caused
: by an IMM having a lousy password than I have from someone hacking the
: OLC (inna Diku) or shell. So I'm curious, is this not as much of a
: problem in an LP?
This is solved by beheading such imms. The problems being discussed here
are security issues related to the dynamic nature of LPC, which Dikus
and so forth simply don't face. You cannot possibly make a call which
replaces existing code during a run on a Diku, for instance:)
As for solutions to bad passwords, if you really care that much, implement
ssh for your mud and/or learn to make frequent backups to offline or RO
media:)
John Adelsberger
: Scatter ///\oo/\\\ <sca...@thevortex.com> wrote:
: : There is no reason on earth for lesser trusted people to have write access
: : to an admin's personal directory.
: Only if the admin has no areas in the game.
Please tell me NM is not so lame that areas stay in the creators' home
directories while in play?!
BTW, you can solve almost all problems w/ stack based security systems and
special access in a general way. A hint: my lib directory will shortly
have two subdirectories:
/src
/txt
And valid_object() will disallow loading from the latter. Reading of the
former is global access, whereas reading of the latter is carefully
protected. There are other details, but if you can't work them out for
yourself, you don't need to know that badly:)
Khall
>Distribution:
>
>Khall <jpr...@a.saner.side.of.neverland.gte.net> wrote:
>: Admittedly I don't know anything about LPmuds I'm not even sure I've
>: ever played one, but...from my experience...isn't someone hacking one
>: of the trusted player objects from the login sequence a lot bigger
>: risk than anything else? I've seen far more damage and problems caused
>: by an IMM having a lousy password than I have from someone hacking the
>: OLC (inna Diku) or shell. So I'm curious, is this not as much of a
>: problem in an LP?
>
>This is solved by beheading such imms. The problems being discussed here
>are security issues related to the dynamic nature of LPC, which Dikus
>and so forth simply don't face. You cannot possibly make a call which
>replaces existing code during a run on a Diku, for instance:)
>
>As for solutions to bad passwords, if you really care that much, implement
>ssh for your mud and/or learn to make frequent backups to offline or RO
>media:)
On 13 Jul 98 05:35:51 GMT, John Adelsberger <j...@umr.edu> wrote:
Most security problems are due to fools - this is the point of a good
security system. People such as us, when hacked, find out who did it
and send large guys named Tiny and Guido to the offender's place of
business, and that's that:)
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
K.
-- Did you call it depravity? I am much more depraved than you are:
you hold it as your guilt, and I-as my pride. --
Scatter ///oo/\
>: caller intended".
>So then no trustworthy object is writable by anyone save yourself and your
>close friends?:)
Scrap the "close friends" bit and you're accurate. :) Of course I'm
the only coder at present so it's a moot point.
>: There are only two ways to be considered trustworthy - either
>: (a) the object must be a member of the "trusted" security group or
>This sounds ok...
>: (b) the caller must be a player object, and the object must be
>: loaded from the appropriate player's own directories.
>This is a weakness. People copy others' code all the time without really
>checking it.
[snip]
>You could improve the latter by having both 'author' and 'owner' on files
>and disallowing trust to anything whose author != owner.
Interesting suggestion - it would certainly tighten things a bit.
It need only apply to files in user directories, but even then the
number of files you'd need to track could get huge. I'm not sure
how to implement that in an efficient way, possibly a file used to
keep track of authors/owners with frequently looked-up ones cached
in memory.
--
Scatter ///\oo/\\\
John Adelsberger
Khall <jpr...@a.saner.side.of.neverland.gte.net> wrote:
I wrote both of these at different times:
: This is solved by beheading such imms. The problems being discussed here
: are security issues related to the dynamic nature of LPC, which Dikus
: and so forth simply don't face. You cannot possibly make a call which
: replaces existing code during a run on a Diku, for instance:)
: Most security problems are due to fools - this is the point of a good
: security system. People such as us, when hacked, find out who did it
: and send large guys named Tiny and Guido to the offender's place of
: business, and that's that:)
And I think both are true. I'll do anything possible to secure my system,
but frankly, if some moron wants to spend enough time and use enough
firepower, he's GOING to find a hole, even if I run OpenBSD, keep current
with every security list on the planet, spend thousands of hours on mud
level security, and so forth.
: -- Did you call it depravity? I am much more depraved than you are:
: you hold it as your guilt, and I-as my pride. --
An excellent quote:)
Khall
>Distribution:
>
>Khall <jpr...@a.saner.side.of.neverland.gte.net> wrote:
>
>I wrote both of these at different times:
>
Sorry I included your attribution into the other one to make it clear
that I had pasted two of your posts together...I was hoping that would
work. I was just trying to say that since all of you seem to know what
you're doing....all of these security systems sound pretty good (as
much as I know:) I just thought I'd bring up something else, I mean
it's kinda silly to have a security system that's unhackable from the
inside, but that someone can just walk on as the IMP or an admin and
do anything they want. And you sorta jumped on me...so I used your
post to show that you'd agreed with me basically. *shrug*
[chop my post]
>
>And I think both are true. I'll do anything possible to secure my system,
>but frankly, if some moron wants to spend enough time and use enough
>firepower, he's GOING to find a hole, even if I run OpenBSD, keep current
>with every security list on the planet, spend thousands of hours on mud
>level security, and so forth.
>
>
>: -- Did you call it depravity? I am much more depraved than you are:
>: you hold it as your guilt, and I-as my pride. --
>
>An excellent quote:)
*grin* I thought you'd like it.
K.