Rough Draft of Proposal for review by Justin Harper

Justin L. Harper tuc40858 at temple.edu
Wed Apr 4 21:09:14 UTC 2012


Parrot Team,

Good afternoon members of Parrot. I have attached a second rough draft
of my proposal if anyone would like to view and I welcome any
suggestions and ideas you may have to help improve my proposal. Thank
you and have a nice day.

-- 
Justin L. Harper
Electrical Engineering
Peer Partner Mentor
IEEE
Society of Automotive Engineers
Temple Taekwondo
Email: tuc40858 at temple.edu
Cell: 215-866-6003
-------------- next part --------------
Project Summary

	Security is quickly becoming a number one priority among web designers and programmers in the digital age. Protecting vital bits of code from being tampered with has become a key to continued success in all fields of study and is no different for the Parrot Foundation.  You want Parrot to run executions from the outside without users being able to come in and alter files, which is where The Security Sandboxing project comes into play. The sandbox will be modular in design to allow for future development as Parrot grows and becomes more versatile. In the design it will set permission flags and have an interface that will ask ?Do I have permission? making this a high priority as Parrot becomes more modern in design.

Project Description

	Design will be based off of a Security Context Structure where a component can ask ?Do I have permission?. I will create an interface where a ?parent? can set permissions on the child, but the child cannot alter its own permissions. This security feature will be modular by design which will allow future implementations to be added on. This will give Parrot security in dealing with its growing versatility of communication with HLL?s. The Security Sandbox has two main restrictions/permissions that I want to implement. First is the ability to limit IO access such as limiting sockets and paths where file handles can access resources and secondly to limit certain capabilities such as loading dynamic libraries. The Security Context Structure will be able to attach to the Parrot_interp_new and allow you to set the context without allowing that interp to modify the context. Creating a set of rules for Parrot to follow and attaching limitations to those rules so Parrot will have a simple structure on which it runs.

Relation to Parrot

	Development of the security sandbox for Parrot will reverse its largely implicit contract nature by permitting a small set of allowed activities and making anything outside that set impossible. As Parrot progresses in its development added security is needed. Rather than building a completely new security sandbox each time a new version of Parrot is released, new modules can be created and implemented into the design of the core security sandbox. For this project I will be working on the core of the sandbox which will mostly be dependent on itself. Any interaction with Parrot will be the permissions/restrictions. 

Tools and Technologies Used

	The tools for this project will include the normal parrot build system and test suite. For this project I  will not need  to be create any specific tools.
 
Delivered Results

	The overall result we wish to achieve is a working security core module. Deliverance includes core module and test for correct implementation into parrot. Separate modules being implemented into core module for increased security along with debugging test and documented design process.

Project Timeline

	Before actual work on the project shall begin, I will find sources resources related to ptrace, security context structures and example codes of security sandboxing systems as a basis for my design.

May (Constructing the core)

Week 1 (5/21 ? 5/27)
	* Begin work on core design (interface)
		o A structure to hold  permission flags (maybe similar to ptrace)

Week 2 (5/28 ? 6/3)
	* Work on interface. Communicating with Parrot.
		o Continued construction of core. Begin implementation of conditions and permissions flags.

June

Week 3 (6/4 ? 6/10) 
	* Conditions and more permission flags that the structure will hold.

Week 4 (6/11 ? 6/17) (Adding permissions/restrictions)
	* Whitelist/blacklist file system restrictions for I/O operations

Week 5 (6/18 ? 6/24) 
	*  whitelist/blacklist paths for loading bytecode 
		o Sets framework for placing restrictions on other operations 

Week 6 (6/25 ? 7/1)
	* Restrictions on bytecode libraries, language libraries

July

Week 7 (7/2 ? 7/8) 
	* limiting access to parent interp data

Week 8 (7/9 ? 7/15)
	* Revisions and preparation of submission for mid-term evaluations of project.
		o (Have at least shell done with limitations started for mid-term evaluations)

Week 9 (7/16 ? 7/22)
	* limited ability to modify environmental variable

Week 10 (7/23 ? 7/29) 
	* limited ability to turn on debug and trace modes

Week 11 (7/30 ? 8/5) (Implementation)
	* limiting certain OS interactions

August

Week 12 (8/6 ? 8/12)
	* Begin work on sandbox call to feature from future privilege system.

Week 13 (8/13 ? 8/19)
	* Revision of project and related materials for preparation of submission.

Week 14(8/20 ? 8/24)
	* Final submission of project and all related documents and test.

    If at any time I am ahead of schedule I will begin work on the next phase of the project at once. That way if there is time left over then we can begin work on additional ideas.

Your Personal Schedule

	This summer I will be working as a student worker for Temple University. Most work days have a lot of down time which will be perfect for reading and working on code. I do not work a lot of hours so work will not get in the way of the project. I am taking a summer course during summer session I which last up until the beginning of July, afterwards I will just be working with the occasional trips to the beach for a day or so. No big vacation trips have been planned for my summer, but if something comes up I will check and modify my timeline accordingly to compensate for possible overnight vacation time.  

Allowances

	Above all else the security sandbox shell will be created so future features can be added. Making sure it correctly communicates with Parrot is also part of the shell design.  Highest priority is the construction of the whitelist/blacklist for I/O operations and paths for bytecode (restrictions on bytecode libraries and language libraries, etc?). The objective is to let Parrot know what it can and cannot do to prevent errors. Limitations placed on certain OS operations, debug and traces modes and modified environmental variables can be omitted because the system ideally would only produce warnings about those instantiations.  Having parrot slowly transition from allowing all operations to a strict set of rules followed by creation of limits on those rules is the best course of action for such a short project.   

Additional Ideas

	Once the main objectives are complete we want to implement more security modules into the core. Additional security features that can be implemented are security modules design for the PL/Parrot project and subclassing NameSpace.  Limiting classes that can be instantiated is a big aspect I want to add if possible. This will limit the effect of changes an object would have on the rest of the system and allow the program to be less responsible for other parts of the system. Limiting memory consumed if time allows would work help parrot run more smoothly and would provide a challenge.

Student Information

	My name is Justin Harper and I am a junior in the Electrical Engineering Department at Temple University. Aside from programming classes taken towards my degree, my coding experience is minimal. However, everyone has to start somewhere and Google?s Summer of Code 2012 program is a great way to start. The opportunity to learn techniques programmers use to solve challenging problems and develop useful skills will allow me to further develop as both a student and a future employee at a company.  Being able to identify the problem, developing a method to solve a particular problem and refining that same method is the process I follow to achieve a particular goal. I preform research on the topic at hand and often change my approach to gain a better understanding of what needs to be done. Often I seek advice and the opinions of those around me in case there is something I miss. Most of all I communicate what needs to be done and what I plan on doing to those involved with whatever I am working on. 



More information about the parrot-dev mailing list