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

1) Create a core application security system to distribute permissions on/for applications.

2) 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

Downloading Code

DB

From shared drive

Static HTML, JARs, …

JNLP Generator

Launching

Based on Framework

Not based on Frwrk

Servlets

Based on Framework

Not based on Frwrk

Servlets

DAEConnection

Isimplemented

Will beimplemented

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.

name classes …apetrov

console_user_id807 $800 …

a dbo.console_user record:

1. MCR

2. RemoteMCR

3. CHL

11. AccelPrgrmmer

…

…

INSIDER

PUBLIC

APPiX groups:

Depends on access mode

Application Privileges A special APPiX table is used; every

application may have membership in several groups + is_writable flag.

Application privileges are used:1) to define who can start an application2) as service privileges for DAE3) to define whether an app. is “writable”.

AppFramework Test

Application:

1. MCR

3. CHL

11. AccelPrgrmmerINSIDER

APPiX groups:

1

0

1

0

is_writable

Service privileges:

$802

May startMay start:

MCR, CHL, AccelPrgrmmer, INSIDER

May writeMay write:

MCR, AccelPrgrmmer

Servlet Privileges A special AppixRealm module is

developed for Tomcat. Privileges are checked:

1) by Tomcat itself (web.xml file)2) 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).