Application Index/Framework Security

1
Application Index/Framework Security

• A. Petrov, 11/21/02

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

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

4
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.

5
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

6
Borders Of Protection - II

• DAE connection against unauthorized data usage
  and modification

7
ApplicationBrowser
DB
Downloading Code
From shared drive
Static HTML, JARs,
JNLP Generator
Launching
Based on Framework
Not based on Frwrk
Isimplemented
Servlets
Based on Framework
DAEConnection
Will beimplemented
Not based on Frwrk
Servlets
8
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.

9
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.

10
a dbo.console_user record
name
classes

console_user_id
apetrov
807
800

APPiX groups
1. MCR
2. RemoteMCR
3. CHL

11. AccelPrgrmmer

PUBLIC
Depends on access mode
INSIDER
11
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.

12
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
13
Servlet Privileges

• A special AppixRealm module is developed for
  Tomcat.
• Privileges are checked
• by Tomcat itself (web.xml file)
• by servlets

14
Servlet Privileges - II

• All interaction between Application Index
  database and Application Framework (and Console
  Application Launcher) takes place via servlets.

15
User Authentication

• For servlets through Tomcats AppixRealm.
• For DAE through Kerberos.
• It still looks unclear how to implement Kerberos
  security when the web-client is a browser (but
  its probably possible for framework-based
  applications).

16
User Authentication - II

• In general, user authentication is not required
  a default user has some privileges (through
  PUBLIC and INSIDER pseudo-classes).

17
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).