[DGD] Kernerl security without guest programmers

[Gary]

As I make glacial progress on my mudlib I keep coming back to how I'm
attempting to stick to the kernel security model and questioning if i
really need to be so rigid.

There are aspects I want to stick with in order to benefit from resource
quotas and the ability to recompile everything (inheritable/clonable split).

However, when it comes to security it feels like I may not need to go
quite as far as the kernel does in my own code. Clearly I want to ensure
players/builders don't get to do anything they shouldn't which includes
not allowing them to run arbitrary code.

When it comes to programmers though, as appealing as having guest
programmers is and needing to protect against malicious ones, that's a
feature I'm not sure I want/need. Top level admins may retain the
ability to execute arbitrary code for emergencies, but since they'll
have disk level access, guarding against maliciousness within the
runtime code seems like a waste.

Given that I don't want guest programmers, that leads to the question of
do I really need to keep mudlib code guarding against programmers.


An contrived example of what I mean is a command like cmd_delete_room.
At some time during that call chain there'd be a check to ensure the
person who invoked the command actually has permission firstly to invoke
the command and secondly to delete that specific room.

What there doesn't seem to be a need for (when guest programmers are not
a concern) is delete room to care what code called it.

If a programmer decides to write a new object that calls delete_room,
then the room will be deleted. Even if the delete_room did
previous_program checks as would be needed to ensure a guest programmer
didn't compile some code in their usr dir that invokes delete_room.
Nothing stops programmers with full access augmenting those checks to
allow his object to also call it.

So imo the onus for security when your programmers can edit any code at
all, falls on firstly trusting those programmers (and your checkin code
review) to do no deliberate harm and hoping they don't provide code
users can call that do not perform sufficient security checks.


I keep going back and forth on this issue, even as I write this email.
Partly because I think what if anyone else ever used the mudlib, maybe
they'd want live coding or guest programmers. Or (more likely) myself or
another programmer could make a mistake and a regular user is able to
use that mistake to breach the security of the mud.

Maybe the checks that would have guarded against a malicious coder
would have limited the damage in that case. Or the act of having to
amend delete_room to now allow another previous_program to also invoke
it, would make the programmer think, hang on I'm introducing a flaw here.


As I've rambled a fair bit, I'll end with a few specific questions.

Those of you who have built your mudlibs off of the kernel lib and also
do not have guest programmers/untrusted programmers, how close do you
keep to the kernel model of security?

Do you religiously ensure all public methods do a security check to see
which program invoked them or the owner/creator and limit it to the
absolute minimum required at that time. Or, do you restrict those checks
to only code that users/builders can directly invoke (commands) to check
access/permissions with any subsequently called code assuming those
checks have taken place?

Am I wasting time coding as though runtime guest programmers are a thing
in my mudlib when they'll never exist?

Regards,

Gary