FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Status Log
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic     Forum Index -> DSP
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Aug 11, 2005 7:15 am    Post subject: Reply with quote

JJR wrote:
This does look exciting, Eric! Keep up the good work. You've been holding on longer than most! Wink

-JJR


Thanks for the encouragment! Laughing

I'm determined to get this working the way its supposed to. Wish me luck.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Fri Aug 12, 2005 5:36 am    Post subject: Reply with quote

DDL

Quick note, my DDL research notes will be posted from here on, in a separate thread:

http://www.dsource.org/forums/viewtopic.php?t=940
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Aug 22, 2005 5:45 pm    Post subject: Reply with quote

DDL

DDL has been moved to its own project!

http://www.dsource.org/forums/viewforum.php?f=70

DSP

As DDL progresses, I am managing to keep the implications for DSP within scope. DSP will remain silent until I can get DDL support up to what will work comfortably with DSP.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Sep 12, 2005 11:16 am    Post subject: Reply with quote

Progress

Over a week ago I jotted down some notes regarding the overall design of DSP, and how it will be impacted by DDL.

So far, I've determined that the library cache is going to go away. DDL will implement its own caching scheme in order to support its runtime linking capabilities. However, DSP will have some special classes that will mesh with DDL in order to give it the capabilities that are needed. So far, this line isn't clearly drawn, but it will become more so in the following months.

I also put some thought into code-behinds, and decided that there's a much better way to approach this: why not make .d files compilable in the same way as .dsp files? If a .d doesn't have the exports needed for handling a servlet request, then its simply not accessable via HTTP. However, in all cases, it will be available via 'import' or 'dsp:import' in the manner that one would expect.

This folds into the last major change: a better temp architecture. Much like Tomcat, future renditions of DSP will use a singular cache for all intermediate (.d) and dynamic libraries (.ddl). The cache will only be sub-divided by application namespaces, so that the file tree will be intact in order to facilitate library searching and imports.

That's all for now. I can't say when I'll be back to coding on DSP itself, but I may draw a line under the current (broken) implementation as Beta 2, so that Beta 3 will have all the radical architecture changes and improvements.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Oct 03, 2005 1:08 pm    Post subject: Reply with quote

Design Notes

A few notes about security in DSP.

My biggest concern for DSP, as of late, is: what kind of vulnerabilities is a DSP-based system exposed to within the server itself?

Certainly, scripted and VM-based platforms are naturally hardened to pointer manipulation and arbitrary code execution simply because they use neither. In contrast, DSP provides a mechanism by which a (trusted) user with an account, can code directly on your webserver if you were running a co-lo of some kind; so attacks of that nature are an immediate concern.

We can cry "obscurity isnt security" all you like; the other guys are just as vulnerable, right? The simple fact that its several orders of magnitude easier to write a buffer exploit or signal an interrupt in raw D code instead of PHP or Perl, warrants significant concern even if the reality is that all of the above are technically "vulnerable" (that is, its possible in Perl or PHP, just not easy to accomplish). So we are all in the same kind of leaky boat, only ours has bigger holes in its hull. Sad

So how do we handle all this and harden DSP? A short survey of solutions includes: page-level protection, link-level security, code filtering and good 'ol process-level security.

Page Level Protection

DDL is in an excellent position to provide page-level locking for all executable code placed on the heap. Combining this with a protection-aware GC, that would lock everything else as non-executable, would close the loop nicely.

The notion of a protection-aware GC should not be dismissed as trival. As protection is at the page-level only, we only get a very granular kind of protection. Depending on the page size, this may not be as implementable as it sounds.

Fortunately, this particular feature isn't as essential as the other (more tested) security solutions mentioned here.

Link-Level Securty

Another potential DDL security addon. This would keep "dangerous" API's out of reach of loaded code so that all the other security features remain intact. Things like kernel-level APIs, or even DDL itself, simply wouldn't be available to dynamically loaded modules.

Code Filtering

D provides us with a compiler front-end as a part of the SDK. It is not at all impossible to modify this to filter out certain kinds of operations that are deemed unsafe or violate the security model. Things like asm{} blocks or stack-based arrays could easily be caught at development time. All it costs is some additional compile time up front.

Process Level Security

Unix is better suited to task here than Windows. Basically, much in the same way as Apache, we give the developer access to filesystem manipulation functions and such and let the kernel's built-in security model do the rest. This applies for access to kernel-level function calls, file system access and access to system resources.

There is a set of best-practices that go hand-in-hand like this (e.g. dont' give your webserver's system account write access to your configuration files), so its not foolproof. But it is a proven technique nonetheless.

Final Thoughts

All-in-all, I think this model of software development and deployment has a bright and safe future. Outside of process level security, additional safeguards can be implemented depending on what an administrator deems necessary to create a suitable environment. Thankfully, these are all optional, which creates a nice spectrum of performance vs safety.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DSP All times are GMT - 6 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group