190 likes | 289 Views
Application Index/Framework Security. A. Petrov, 11/21/02. Obstacles. Various types of executable codes (Java classes, HTML, SVG, JScript, … ). Various code sources (shared drives, Apache and Tomcats). Various types of user authentication (via web browser, Kerberos, … ). Obstacles - II.
E N D
Application Index/Framework Security A. Petrov, 11/21/02
Obstacles • Various types of executable codes (Java classes, HTML, SVG, JScript, … ). • Various code sources (shared drives, Apache and Tomcats). • Various types of user authentication (via web browser, Kerberos, … )
Obstacles - II • It is seemed to be possible to create a manual bypass in almost every case. • System is under permanent change and is not understandable as a whole (at least, for me…)
Goals • Create a core application security system to distribute permissions on/for applications. • Implement several borders of protection, based on this core system.
Borders Of Protection • Application Index –list of available programs depends on actual user privileges. • Code sources –against unauthorized code download • Security check in App. Framework –against unauthorized launch
Borders Of Protection - II • DAE connection –against unauthorized data usage and modification
ApplicationBrowser DB Downloading Code From shared drive Static HTML, JARs, … JNLP Generator Launching Based on Framework Not based on Frwrk Isimplemented Servlets DAEConnection Based on Framework Will beimplemented Not based on Frwrk Servlets
Users • A generic VMS table of login names is used, dbo.console_user. • APPiX has an additional table with encripted passwords (for web access). • GUI to edit users is not provided.
User Privileges • VMS classes are used; they considered to be groups in Application Index. • Two pseudo-classes are added: PUBLIC and INSIDER; “dynamic” membership, depending on access mode. INSIDER is a subset of PUBLIC.
a dbo.console_user record: console_user_id name classes … 807 apetrov $800 … APPiX groups: 1. MCR 2. RemoteMCR 3. CHL … 11. AccelPrgrmmer … PUBLIC Depends on access mode INSIDER
Application Privileges • A special APPiX table is used; every application may have membership in several groups + is_writable flag. • Application privileges are used: • to define who can start an application • as service privileges for DAE • to define whether an app. is “writable”.
Application: AppFramework Test is_writable APPiX groups: 1. MCR 1 Service privileges: $802 3. CHL 0 11. AccelPrgrmmer 1 INSIDER 0 May start: MCR, CHL, AccelPrgrmmer, INSIDER May write: MCR, AccelPrgrmmer
Servlet Privileges • A special AppixRealm module is developed for Tomcat. • Privileges are checked: • by Tomcat itself (web.xml file) • by servlets
Servlet Privileges - II All interaction between Application Index database and Application Framework (and Console Application Launcher) takes place via servlets.
User Authentication • For servlets – through Tomcat’s AppixRealm. • For DAE – through Kerberos. • It still looks unclear how to implement Kerberos security when the web-client is a browser (but it’s probably possible for framework-based applications).
User Authentication - II • In general, user authentication is not required: a default user has some privileges (through PUBLIC and INSIDER pseudo-classes).
Secure Socket Layer (SSL) • DOE does not allow purchasing “real” SSL certificates. (?)… and so: • Entering password in Application Index is now forbidden for outside users (all outside users belong to PUBLIC pseudo-class).