[DGD] Kernerl security without guest programmers

[Raymond Jennings]

Bear in mind that humans may not be the only "users" or "administrators" in
the kernel security model.

On Mon, Jan 23, 2017 at 4:55 PM, Gary <gary at mups.co.uk> wrote:

> 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).
>

Resource quotas and separation of inheritables are both orthogonal concepts
that you can enable fairly well independently of each other was well as
security.

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

Bear in mind that only code in ~System is allowed to inherit LIB_USER,
which is the only object type that a kernel connection object will accept
for a "user".  If you don't export the ability to compile arbitrary LPC
code, then you won't have to worry about malicious code injected by guests
unless they find another way to do so.  In this case, you would need to
explicitly "opt in" to allow it.  The default user object provided by the
klib makes use of a wiztool that inherits /kernel/lib/wiztool, which itself
runs security checks based on the assigned *owner* of the wiztool (since
the creator is the kernel), and if you look at the code in
/kernel/lib/wiztool you'll see how the security works.


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

Just don't let guest programmers:

1.  Have the ability to compile scripts or whatnot, which is just a special
case of:
2.  Do not grant guest programmers write access to compilable objects, and
for this purpose that includes the ability to supply custom source code to
the compile_object() kfin

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

Personally, I use kernel security model on more than just users.  I also
use it to sandbox subsystems/modules, particularly those such as HTTP or
Intermud that are exposed to possibly malicious users.

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

I generally narrow such to the minimum required, at least for things that
"do" something.

However, public subroutines are open to all.


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

I personally would not allow guest programmers period, but I would still
use kernel security to sandbox sensitive or vulnerable modules.

Both SkotOS and my own Kotaka use separate klib "users" to quarantine
subsystems much the same way as microkernels do, and even modern linux/unix
systems use unique UIDs to sandbox server processes, particularly ones
exposed to the wilderness of interaction with possibly hostile agents
across the internet.

Personally, I think that using klib security to jail things like HTTP and
Intermud is a wise security precaution.  And this applies in my designs
even in cases where I do not allow guest programmers at all.

Regards,
>
> Gary
>
>
>
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd