Central Online Grading System COGS Dec15-21 dec1521.sd.ece.iastate.edu

Problem Statement ●Cpr E 185 has weekly programming practices ●Blackboard is a frustrating interface o Cannot display.c or.txt files o Downloading, compiling, and running student code is tedious

Solution Overview The goal of COGS: Streamline the grading process ●Features o Intuitive Assignment creation o Easy student submission o Secure compiler o Automatic testing o Cheating detection o Streamlined grading o Blackboard Integration

Conceptual Sketch

Resources and Risks ●Resources: o Virtual Machine Server ●Risks: o Security o Hosting student data o Blackboard interfacing

Project Divisions ●Web Team o Zend Framework o User Interface o Blackboard Interfacing o Database Communication o Members  Forrest Scott  Katie Widen  Daniel McDonough ●Systems Team o Grader o Authentication/Security o Cheating Detection o Members  Zachary Lones  Daniel Riechers

Detailed Design - Front End ●Zend Framework o Open Source o Object Oriented o MVC structure o Modular o Secure o High Performance

Detailed Design - Front End Complex Diagram Simplified

Detailed Design - Front End ●Zend Autoloader o Resource Loading o Object Building o Security o Configurable Routes

Detailed Design - Front End ●Zend Controllers o M-V-C o The “Brains” of the Front End o Communicates with Back End o Forms, Plugins, Modules

Detailed Design - Front End ●Doctrine 2 Database o M-V-C o MySQL o Object Oriented o Lazy loading o Custom Macros o Auto Hydration

Detailed Design - Front End ●ZendFramework Views o M-V-C o PHP + HTML o Final Stage

Detailed Design - Grading Complex Diagram Simplified

Detailed Design - Grading ●Student Submits o Custom execution inputs o Back end runs o Returns errors, outputs o Last submission is used

Detailed Design - Grading ●T.A. Grading o Streamlined grading pages o Can create new execution o Alerts when cheating detected o Notes viewable by students o Upload to Blackboard via.csv file

Detailed Design - Security ●Prevents stalled code using timers ●All student code is run in a chrooted environment o Minimal filesystem ●The system uses a Mandatory Access Control policy o Transparent to administrators

Detailed Design - Chroot Filesystem ●Adds level of system protection ●Prevents student software from interacting with the filesystem. o Changing system configuration o Installing Malware o Gathering system information

Mandatory Access Control (MAC) ●Forces permissions o Permissions limit user access to  Files  System Calls ● Devices ● Shared Resources ● Network ●We used SELinux for MAC o SELinux is an implementation of MAC by NSA

Detailed Design - SELinux ●Policy is transparent to administrators. o Policy should not limit administration o Policy should not need modification ●Policy is extra strict on student code executions. o System calls are whitelisted ●SELinux Aware Firewall o Further limits network traffic

Front End Requirements ●Administration (Add/Remove/Edit) o Classes o Instructors ●Instructors (Add/Remove/Edit) o Assignments o Students o Submission Scores ●Students o Upload Assignments o Check Results

Back End: Grader Requirements ●Preliminary Report o Shows compiler errors and warnings o Includes students custom inputs and resulting outputs o Shows results of unit tests ●Final Report o Everything in Preliminary Report of final submission o Include additional tests and static analysis o Returned to student after Instructor has written grades and comments

Back End: Cheating Detector Requirements ●Cheating Report ○ Displays code similarities across submissions ○ Generates a cheating confidence score ●Run cheating detection algorithm on students’ final submissions ●Report is viewable by Instructors if cheating is detected.

Security Requirements ●Use Mandatory Access Control to encapsulate student code. ●Use a chroot environment to encapsulate student code. ●Use a firewall that restricts unauthorized network communication ●The student code will be allowed to execute the following system calls: ○read○ close ○write○ open ○create

Integration Requirements ●Web server executes the grader ●Grader returns its output to the web server via stdout ●Web server stores grader results in database ●Blackboard integration is handled manually via.csv

Non-functional Requirements ●Streamline the process: make grading as intuitive as possible ●Mandatory Access Control will be transparent to system administrators ●All external dependencies will be verified to be secure and reliable o Shibboleth o Zend plugins o Runtime libraries ●Maintainable ●Extreme care taken when handling student information

Test Plan - Front End ●Manual testing for individual components ●Alpha testing using a small group of students and single instructor ●Beta testing using a larger volume of students and multiple instructors

Test Plan - Backend ●All backend modules (Grader, Cheating detection) are unit tested with Google Tests. ●The SELinux Policy and security encapsulation are tested manually.

Current status and Future Plans Current Status

Questions?