[DGD] Kernel LIB's Invis...{Design Considerations}

[Michael McKiel]

 --- Stephen Schmidt <schmidsj at union.edu> wrote: 
> > I was about to start in on bringing my rewritten security code from
> > Melville,
> 
> It is probably unwise to do that. The kernel security and the
> Melville security are, I am pretty sure, not mutually compatible.

Yeah they aren't, not really. Though I did rewrite /system/auto/secure.c, 
and its much more robust/clean. It does suffer from not being called in
places that it should be, like the fact that a mere Wizard can
"update/compile" a file in a path that he has no 'read or write' access
so long as he knows the ending objectname.c

> If you are using the kernel lib, then I think (I have little
> experience with it) then you should leave all security issues
> to the kernel, except insofar as you want to add additional
> restrictions to those of the kernel. (Melville code might be

1/ Yeah it wont be compatible to patches of the lib. They Could be 
done by hand I if the nonSource patches were crucial.

2/ Can't really leave 'all' security issues to the kernel, I don't
like 'all' the restrictions it requires or implies. 
    a/ NonWizards being in "/usr";
    b/ The limits of what is in effect one lib working amongst itself.
ie when game/nonWiz written/ code sits in multiple usr/ dirs & kernel/
doesn't interact very well together. Nor have permissions to do things 
(I believe) they should due to KLib's hard-code on non"System" files.
    c/ The absolute limits of code that doesn't reside in a:
sys,obj,lib directory, and the enforced use of that dir structure.

> useful for that.) Trying to change the security code in the
> kernel lib would break compatability for upgrades and be a
> very risky thing to do. The kernel lib is, I think, more

Not so risky, almost all of it is directory checks of sys/obj/lib
or checks on whether something IS kernel || IS "System".

> secure than Melville (Melville is designed to be easy to use
> rather than to be extremely secure, for reasons I've posted
> in the recent past) and if tight security is a concern, you
> are better off with the kernel code.


I did make more than a few attempts of bringing the Kernel into 
Melville in pieces, after doing extensive fixes in a number of
places, fixing some bugs, and bringing Melville up to typecheck 2.
    That proved to be an abysmal failure hehe. The kernel is so 
interrelated and woven that pieces of it cannot be taken at a time.
And to do it otherwise would make the task of debugging how Melville
and the kernel work together impossible.
    Thus I am starting with the Kernel, removing its enforced named
dir structure, though leaving it in essence, there are still the
checks for /lib/sys/obj, but within the .h's you can rename what you'd
like those dir names to be. We went with /inherit, /system, /object.
    Removing non-Wizards from the /usr (renamed /home) dir.  And plan to
skip most of the 'access' related code, though will leave it in place.
"Access" will be checked when the new security code returns a failure.
Thus it will allow for me to define how I want the lib to work amongst
itself, and to use the added functionality of giving access to dirs 
that for security reasons aren't going to be hardCoded.


> Melville security is based on fairly similar principles as
> kernel security, which someone described recently. In Melville
> all objects have a privileges string which describes their
> level of privilege, and a creator string which describes the
> user responsible for their existence. The privileges string
> is based solely on the object's file name, and the creator
> is usually whoever was this_player() at the time the object
> was loaded. Of course, how these are assigned and how they
> are checked differs considerably between Melville and the
> kernel.
> 
> Steve

*grin* I'll assume thats for the rest that don't use melville 
I know how it works, I've rewritten it. And fixed one of the
glaring bugs (player files don't have permission to save_object()
due to the save_object() call being done after their perms are 
reset from "login" to "player").

I'm not sure if this is of interest to the list or not, suppose 
click/delete will work instead of crawling through this scrawl.

As a final aside, I believe in a significant number of places in
the Kernel LIB felix does things that requires a much more intimate
knowledge of DGD than most of us will attain. Thus making the Kernel
a wiser choice to start from than not.  But as Mr.Crowes himself said
there could be use of a lib that isn't so paranoid hehe.
So thats what I plan I suppose, to use a very large amount of the
Kernel, redo in places I'd like different functionality, use my own
directory structure, and for the most part my own defined security
which Klib's 'access/accessd' can supplement.

And much thanks to everyone for helping point out things that perhaps 
one believes should be obvious, intelligent discussion and help.

Zam.


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd