[DGD] Kernerl security without guest programmers

[bart at wotf.org]

When not having guest programmers at all, many of the direct reasons for
implementing a security model seem less important, but you correctly point out
how this can still be relevant for general users.

While I do not use the kernel lib security model, I do use something similar
and eventho I am currently the only user of that codebase, I do stick to the
security model for 3 reasons:

1. it also protects against my own mistakes

2. adding security checks later on if I somehow end up with another person
working on the codebase is a major pita, especially once security has not been
a design consideration for a while

3. even without guest coders, it is still possible to trigger execution of
code, any 'player' action will cause execution of code, and if that code
parses the player input and acts on it, the player very likely has an indirect
way of causing code to be called. If there are any bugs in that code, a player
might be able to call random code.

An example of the 1st and 3rd reason is something I ran into while playing an
ancient lpmud, which allowed callbacks from text strings (by interpreting the
string and looking for #function:arg substrings). The consequence was being
able to call any static function in the object parsing my input by correctly
crafting my input. Obviously the mudlib should have skipped looking for such
strings in user input, but a mistake like that is easily made.

So, even if you do not need security to guard against guest coders, as long as
your system allows for user input, it is very likely to benefit from strictly
using a good security model.

The security model I use protects any sensitive actions by verifying the
entire call path, and seeing if all code on the call path has the proper
permissions, or takes responsibility for the security of the action (which
means the call path is only verified upto and including that specific object).
Both object and program are checked for proper permissions. This model
implements an extended variation on the mudos stack based security model.

Bart.

On Tue, 24 Jan 2017 12:50:31 -0800, Raymond Jennings wrote
> 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
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/