Prothon announces new "Landmine" security model
<[email protected]> Sun, 11 Apr 2004 12:07:30 -0700
| Newsgroups | gmane.comp.lang.prothon.announce |
|---|---|
| Message-ID | <000501c41ff8$3cef6950$0b01a8c0@mark> |
This is a multi-part message in MIME format. --===============1744362453== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C41FBD.90909150" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C41FBD.90909150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Prothon's latest release (http://prothon.org) introduces a new security model that allows full airtight control of access to data and other resources based on a the running code's given permission level. Unlike the Java security model and Python's deprecated security model that are based on a sandbox scheme, Prothon's model is based on a new "landmine" scheme built into the object locking mechanism. Where the sandbox scheme falls apart once any security is breached, the landmine scheme continues to protect after minor breaching since protection is pervasive across all objects, not just at sandbox borders. Each and every object has a read level and a write level that specifies what permission level a thread must have in order to read lock or write lock that object. Since Prothon already has the read and write locking mechanics built into every access, the overhead for this checking is minimal. As objects are created these permission levels are set by default logic based on the access rights of the creating thread that in most cases is the correct value. In some cases the code must fine-tune the values to accomplish certain security goals. The current implementation has four security levels for threads: Guest, User1, User2, and System. For example, Guest users have no access to File objects and therefore cannot access files. As another example, User2 threads can modify Sys.path which directs Prothon's search for executables, but User1 threads cannot. System threads can do anything of course. This security model is fully functional in the current release but some fine-tuning will be required of the object settings as Prothon matures. We will have a web-based site on-the-air in the near future with console interpreter access to allow people to attempt to hack the site and defeat the scheme while still using the site for useful work. We hope this demonstration will prove the validity and power of our new "landmine" approach. ------=_NextPart_000_0006_01C41FBD.90909150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2>Prothon's latest release <SPAN=20 class=3D227030619-11042004>(<A = href=3D"http://prothon.org">http://prothon.org</A>)=20 </SPAN>introduces a new security model that allows full airtight control = of=20 access to data and other resources based on a the running code's given=20 permission level. </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Unlike the Java security model and = Python's=20 deprecated security model that are based on a sandbox scheme, Prothon's = model is=20 based on a new "landmine" scheme built into the object locking = mechanism. =20 Where the sandbox scheme falls apart once any security is breached, the = landmine=20 scheme continues to protect after minor breaching since protection is = pervasive=20 across all objects, not just at sandbox borders.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Each and every object has a read level = and a write=20 level that specifies what permission level a thread must have in order = to read=20 lock or write lock that object. Since Prothon already has the read = and=20 write locking mechanics built into every access, the overhead for this = checking=20 is minimal. </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>As objects are created these permission = levels are=20 set by default logic based on the access rights of the creating thread = that in=20 most cases is the correct value. In some cases the code must = fine-tune the=20 values to accomplish certain security goals.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>The current implementation has four = security levels=20 for threads: Guest, User1, User2, and System. For example, = Guest=20 users have no access to File objects and therefore cannot access = files. As=20 another example, User2 threads can modify Sys.path which directs = Prothon's=20 search for executables, but User1 threads cannot. System threads = can do=20 anything of course.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>This security model is fully functional = in the=20 current release but some fine-tuning will be required of the object = settings as=20 Prothon matures. We will have a web-based site on-the-air in the = near=20 future with console interpreter access to allow people to attempt to = hack the=20 site and defeat the scheme while still using the site for useful work. = We hope=20 this demonstration will prove the validity and power of our new = "landmine"=20 approach.</FONT></DIV></BODY></HTML> ------=_NextPart_000_0006_01C41FBD.90909150-- --===============1744362453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline