[Security_sig] Application Life Cycle Roles for Integrity Protections

Ed Reed ereed at novell.com
Thu Sep 2 15:05:06 PDT 2004

I've been informally promoting the notion that there are 9 high level roles that are useful in thinking about application life cycles - in the deployment phase, anyway.

The 9 roles represent a natural integrity hierarchy, which may be useful when consider separation of duty requirements for some customers.

The presumed relationship of these is full containment, or encapsulation, but I don't have a good way to describe what I mean, yet.  I presume that each of the roles encapsulate some or all of the roles that are below it in the integrity hierarchy. I'll take a crack at describing it further later in this note.

Role / Integrity Hierarchy:

The nine roles, or processes, and their responsibilities, in order from highest integrity to lowest integrity, are these:

1) audit process - the recorder and preserver of security-relevant changes to the application / system, including the installation and configuration of its files; by virtue of it's position at the top of the integrity hierarchy, the events it receives are appended to its records, but those records themselves are required to be protected from corruption from any of the systems it audits or collects audit records from, whether OS, application, or otherwise

2) restore process - the restoration process has the ability to copy files from validated backup archives onto a production system, including the application sources and binaries, configuration files, application data, customizations, etc.  It may not modify the audit records of the audit system that audits the restoration operation, but may, in fact, restore audit information for a lower integrity audit system.  It's interesting to note that an off-line task is needed - the validation of the backup media to be restored - that effectively elevates the integrity of the backed up files from system low integrity to restore-integrity.

3) installation process - the installation process copies files for an application from distribution media after checking their integrity and authenticity, and as such, needs the ability to create files and directories on the system where the installation is being performed.  For Apache, for instance, this would involve laying down the executables, the loadable modules (mod_ssl, etc), and the default configuration files for Apache.

*- it's an interesting question, which I've not resolved in my own mind, as to whether the ownership of installed files should be set by the installation process, or by the succeeding configuration process - in most scenarios, the two roles are combined, anyway, but I suppose that in a data center environment, the permission to lay down files for a particular application needs to be separate from the application configuration role - consider the process of installing Oracle - they have a task that is part of the installation process that has to be run by root to set ownership of the just copied / installed files

4) configuration process - the configuration process for an application sets the environmental settings that constrain or define the running application, including it's disk space quotas or file/directories available for its use, memory and cpu resource constraints, runtime system and network identities for the runtime executable to use when its run, pointers to printers, infrastructure services (LDAP, DNS, http proxy, whatever), and so forth.  This configuration is really the mandatory policies governing the operation of the application, outside its ability to change on its own.  If multiple instances of the application will run with different environmental configurations, those configurations are defined and set, here.  Configuration generally involves modifying configuration files and registries for the application, but may not allow creation or deletion of files not created by the installation process, and certainly should not have the ability to modify execuables, except, perhaps, to provide digital signatures on configuration files and the executables they consume.  An example would be changes to the http.conf files for an Apache Server, creating virtual hosts with their document directories (may require system ability to create directories for assignment to the Apache virtual host).

5) operational processes - part of the installation involved laying down /etc/init.d/httpd, for instance, which is a script for starting and stopping the Apache server.  The configuration process is likely to have involved modifying files in places like /etc/apache and /etc/sysconfig/apache, to set things like run-time uid, which OUGHT to, perhaps, be different from the uid that owns the configuration and executable files.  wwwrun vs www for instance.  The operator, who can start and stop the service, shouldn't be able to modify executables nor configuration files.  Otherwise, you can't separate the operational staff privileges from the application configuration privs.

6) runtime process - the running service or application needs its own permissions to execute (but not write) its programs and scripts, read (but not modify) its configuration files, and read and modify its own data files (if a database), for instance.  But note - a running process, which might break, should NOT be allowed to corrupt its own configuration files nor executables.  This introduces a quandry for developers today - they're used to using program/service configuration operations to alter the runtime service configuration - and I would much prefer to treat those as two services.  For instance, if Apache had the ability to have one instance, on port 8100, for instance, that has the abililty to modify the configuration files for other Apache instances running on, say port 80 and 443, then the first instance would be running in a separate security domain, with configuration process roles with regard to the production servers run from those configuration files.  The configuration of the 8100 port service would be a separate matter, and it should NOT be able to modify its own configuration files.  This may require more discussion and a better use case to draw out the issues and opportunities.

7) application administration - the running process exports a service of some sort, and is likely to export some administration functions, and these are broken down, here - in Apache, for instance, a portal administrator would create portal users in the application (portal) administration environment.  Those users would not (necessarily) have any system uid, because the identity being created is a portal identity, not an OS identity.  Similarly, setting discretionary access controls is an application administration function.

8) application user - the users of the application have their own role and abilities, within the scope of the application (portal in the example above) to create and modify their application data as allowed by the application.  Using a portal to access a remote web site, if allowed by access controls enforce by the portal, is an example of a user permission.

9) backup process - the backup process has the ability to read everything within the scope of its backup authority - that is, you could think of there being an Apache instance backup process - that could take a snapshot of source, binaries, scripts, configurations and application data files.


As mentioned above, there are scoping assumptions around these.

Consider the widest scope to be defined by the audit scope of the application - in other words, the application deployment takes place entirely within the scope of some audit framework (else, aspects of the application would occur outside an audit framework that would allow review of application security-relevant activities).

So, within the scope of an audit framework,

An application may be restored from verified backup media to a previous state.

Also, an application may be installed, laying down files.

Within that installation, configuration of the application takes place - it doesn't take place outside the scope of the installation.  However, note that the configuration may specify access to and consumption of resources outside the area of the installation, but those resources should still be within the scope of the backup process (below) and restore process (above), and of the audit process (above).  If it crosses boundaries, the the scope of audit still needs to span the boundaries, or have a means to provide reconciliation and analysis of all relevant events.

Starting and stopping the process is straight forward, though it may appear murky when you consider remote administration - but remote administration is, itself, a separate application, much like the separate apache service described above used to configure other apache servers.  Understand the audit scope necessary to track the security-relevant actions of such a multi-system remote administration system, and then you're thinking about the appropriate scope for the audit framework into which its deployed.

Now, the fractal nature crops up.

The application runtime may be the apache server supporting port 80.  Or may be another apache instance running on port 8100.  Or it may be the Oracle Database instance running on that server over there.  Or, indeed, the operating system on that machine over there, or in this virtual machine.  Now, within the runtime identity of this application (or virtual machine instance), there's an audit scope for events generated within that application.  And that may be separate from the one recording the starting and stopping (or reconfiguration) of that application (operating system) before it starts.  

My notion, here, is that there are three or four distinct scopes that nest inside one another:

applications execute within the scope of an
operating system executes within the scope of an
enterprise infrastructure / middleware framework wthin the scope of the
enterprise security policy

Within the scope of the application (Oracle, Operating System, whatever), there may be another Audit scope (if Oracle has it's own audit system, or the OS does), in which restoration, installation, configuration, operation, execution, and backup etc. all may occur.  Etc.

This is too long already - hope someone finds it useful or amusing or not a complete waste of electrons...


More information about the security_sig mailing list