From: ivang@cup.portal.com (Ivan - Godard)
Newsgroups: comp.databases
Subject: Re: Security standards & databases
Date: Wed, 30 Sep 92 04:08:46 PDT
Organization: The Portal System (TM)

>>I'm involved in an effort at my site to define a strategy for client-server
>>computing. Actually, I'm involved specifically in the security aspect,
>>where we're looking at three key areas for emerging standards:
>>authentication, authorization, and accounting (auditing, logging, etc.).
>>For the past couple years, I've been looking at potential solutions for
>>some of these problems. My intuition is that in the next 2-3 years OSF's
>>DCE, which includes a Kerberos-based authentication service, will become a
>>very component. But I don't follow the database scene too closely so I'd
>>really appreciate some input from this group. My assumption is that today
>>commercial database vendor employ their own proprietary security
>>mechanisms. Is that true? Does anyone believe vendors will actually migrate
>>to standard mechanisms such as those provided in OSF DCE? What are the
>>security standards that are likely to be winners in regards to commercial
>>database products over the next 5 years? Who are the key players? I've
>>heard of something called SQL2 and SQL3. Do these standards involve
>>security? Will they be winners?
>>
>>Your input will be appreciated. Please respond via e-mail (jnm@ornl.gov). I
>>will be happy to summarize if it appears there is broad interest.
>>
>>Thanks!
>>
>>--
>>Jamey Maze, Oak Ridge National Lab     
There are a lot of subissues in the general DB security mess. Here's a very
crude breakdown:
1) the terminal. If an intruder can masquerade as a valid user then the best
db security in the world is for naught. Usually addressed by password
authentication and/or physical locking.Issue ignored by DBS - you are
who you say you are if you can convince the hardware/OS that you are.
2) the wire. Similar problem, also ignored by DBS. Addressed by net
security mechanisms e.g. Kerberos.
3) the DB host. Similar problem - if an intruider can break the host OS
then the DB is in general wide open. This is a special problem in
distributed DBS where some hosts are not secure (e,.g. DOS).
4) The DB itself. The DB assumes that an incoming RPC is from a valid
user correctly identified, and the response will be sent correctly
to the identified user without interception. The internal security issues
are covered later.

In general, some DB products attempt to provide some sort of security
at each of levels 1-4, e.g. end to end encryption. However, these
efforts are uniformly penetrable because of one or another loophole,
usually in the underlying OS which the DB incorrectly assumes is secure. 
The onion model described above partitions the responsibility into
easily understood (and relatively easily verified) domains, and is
recomended. Your mileage may vary.
  

Within the OS there are also a number of subissues. The difference in
authority between a user acting as a DBA and the same user acting as
a query generator must be addressed, and such schemes as encryption
(even good encryption like Kerboros) don't even try. The milspec
guys have put a *lot* of thought into these issues. The military may
be crazy but they're not stupid, and there is good reason for
the bysantine complexity of a milspec security system. DB responses
to internal security requirements have generally followed one or
more of the following approaches:

1) internal encryption. With a decent algorithm, this works fairly
well for data which has been validly received by an unpenetrated
DB. However, it does nothing for imposter penetration and/or 
breaking the DB. It fails the requirements for a milspec system
(or even a reasonably secure commercial system) because it
provide no way to distinguish the capabilirties of different users. 
or the same user at different times or situations.
2) access permissions. Generally orthoganal to encryption. Works
fine when the catagories of access can be statically determined,
e.g. access permissioins in Unix. Totally unflexible.
3) Access control lists. A response to the inflexibility of 
permissions (2 above). Improves flexibility and control but scales
*very* badly. Performance intolerable in a system with granularity
finer than a file system, e.g. a db. Administrative nightmare
when used to do more than just model simple permissions.
4) Capabilities. This approach models security as an instance of
visibility control, as in block structured programming languages. 
Performance quite good with hardware help (e.g. Plessy 250, IBM
System38/S400). The administrative model must be aware of
the underlying capability architecture to make use of its
power, although it is easy to model e.g. permissions in a 
capability environment. (*NOT* vice versa). 


The best overall solution I know of  has the following
characteristics:

1) it abandons terminal, wire and host security as not being 
in the province of the DB. (Kerberos is a goid start but
not a finish for these issues).

2) it implements a quite general visibility (capability) mechanism
with the following characteristics:
	a) what you can see you can have
	b) you can only see what you have a capability for
	c) you cannot forge a capability
	d) capabilities are persistent data and can be stored
	on the DB itself, so if you have a capability for
	a capability, you can get at what the second capability
	controls, transitively.
	e) you have a capability for any datum you create
	f) you can pass any capability you possess to any other
	user for whom you also have a capability.
This is not sufficient to implement a full milspec syste (it
doesn't address promotion, for example) but is quite sufficient
for even sensitive commercial DB work. The remaining needs of
any other system are met by adding:
	g) Capabililities may be active data, so that reference
	to or use of an arbitrary capability may be intercepted by
	arbitrary code executed by the DB which replaces the 
	standard semantics of the capability.

With this extension, any security model at all is realizable in a 
capability-based system. If the mechanism is built into the DB
(using the capabilities as transaction controls, for example) such
a system can be done in siftware for zero additional cost
beyond what the DB has to do anyway. However, for most DBs,
security if addressed at all is an afterthought grafted onto
an underlying structure at considerable expense. Most users 
look at the costs of full security as implemented in conventional
DBS and decide they don't really need all that security after all.
I know of only one commercial DB environment which is A-level
qualifying and runs at speed.