Central Online Grading System COGS

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

oCannot display .c or .txt files

oDownloading, compiling, and running student codeis tedious

Solution Overview

The goal of COGS: Streamline the grading process

●Features

oIntuitive Assignment creation

oEasy student submission

oSecure compiler

oAutomatic testing

oCheating detection

oStreamlined grading

oBlackboard Integration

Conceptual Sketch

Resources and Risks

●Resources:

oVirtual Machine Server

●Risks:

oSecurity

oHosting student data

oBlackboard interfacing

Project Divisions

●Web Team

oZend Framework

oUser Interface

oBlackboard Interfacing

oDatabase Communication

oMembers

Forrest Scott

Katie Widen

Daniel McDonough

●Systems Team

oGrader

oAuthentication/Security

oCheating Detection

oMembers

Zachary Lones

Daniel Riechers

Detailed Design - Front End

●Zend Framework

oOpen Source

oObject Oriented

oMVC structure

oModular

oSecure

oHigh Performance

Detailed Design - Front End

Complex Diagram

Simplified

Detailed Design - Front End

●Zend Autoloader

oResource Loading

oObject Building

oSecurity

oConfigurable Routes

Detailed Design - Front End

●Zend Controllers

oM-V-C

oThe “Brains” of the Front End

oCommunicates with Back End

oForms, Plugins, Modules

Detailed Design - Front End

●Doctrine 2 Database

oM-V-C

oMySQL

oObject Oriented

oLazy loading

oCustom Macros

oAuto Hydration

Detailed Design - Front End

●ZendFramework Views

oM-V-C

oPHP + HTML

oFinal Stage

Detailed Design - Grading

Complex Diagram

Simplified

Detailed Design - Grading

●Student Submits

oCustom execution inputs

oBack end runs

oReturns errors, outputs

oLast submission is used

Detailed Design - Grading

●T.A. Grading

oStreamlined grading pages

oCan create new execution

oAlerts when cheatingdetected

oNotes viewable by students

oUpload to Blackboard via.csv file

Detailed Design - Security

●Prevents stalled code using timers

●All student code is run in a chrooted environment

oMinimal filesystem

●The system uses a Mandatory Access Control policy

oTransparent to administrators

Detailed Design - Chroot Filesystem

●Adds level of system protection

●Prevents student software frominteracting with the filesystem.

oChanging systemconfiguration

oInstalling Malware

oGathering systeminformation

Mandatory Access Control (MAC)

●Forces permissions

oPermissions limit user access to

Files

System Calls

●Devices

●Shared Resources

●Network

●We used SELinux for MAC

oSELinux is an implementation of MAC by NSA

Detailed Design - SELinux

●Policy is transparent to administrators.

oPolicy should not limitadministration

oPolicy should not needmodification

●Policy is extra strict on student codeexecutions.

oSystem calls are whitelisted

●SELinux Aware Firewall

oFurther limits network traffic

Front End Requirements

●Administration (Add/Remove/Edit)

oClasses

oInstructors

●Instructors (Add/Remove/Edit)

oAssignments

oStudents

oSubmission Scores

●Students

oUpload Assignments

oCheck Results

Back End: Grader Requirements

●Preliminary Report

oShows compiler errors and warnings

oIncludes students custom inputs and resulting outputs

oShows results of unit tests

●Final Report

oEverything in Preliminary Report of final submission

oInclude additional tests and static analysis

oReturned to student after Instructor has written gradesand comments

Back End: Cheating Detector Requirements

●Cheating Report

○Displays code similarities across submissions

○Generates a cheating confidence score

●Run cheating detection algorithm on students’ finalsubmissions

●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 networkcommunication

●The student code will be allowed to execute the followingsystem 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

oShibboleth

oZend plugins

oRuntime 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 singleinstructor

●Beta testing using a larger volume of students andmultiple instructors

Test Plan - Backend

●All backend modules (Grader, Cheating detection) areunit tested with Google Tests.

●The SELinux Policy and security encapsulation aretested manually.

Current status and Future Plans

Current Status

Questions?