Trusted RUBIX was EAL-4 evaluated, according to
the common criteria, for the MLS, DAC, policies and others.
I lead that effort, so I am familiar with MLS evaluation
requirements. But, it was a number of years ago. Also, Oracle OLS is
eal-4 evaluated (as well as other security certifications).
Actually, just adding mls to a dbms does make it trusted from a
security architecture perspective, but it may or may not be trusted
(enough) by those who want to use it. That is, it is trusted to make
MLS decisions. The required assurance, and the functionality that
must be assured is, as you say, up to the requirements of
organization that deploys the DBMS.
As for where to get information about Trusted DBMS's, you could
start with the list of CC evaluated products. But, if you have a
specific certification or evaluation requirement, I suggest you
start with the websites for that particular certification. But, as I
said before, as far as I know, SEPG, Trusted RUBIX, and Oracle OLS
are the only active MLS DBMS products.
On 1/31/2011 1:18 PM, cto@xxxxxxxxxxxxxxxxxx wrote:
> Thanks. Where do I get info on DBMS’s that are
trusted?
Trusted DBMS depends on the practical use
There was an Orange book that has been canceled since 2002
http://www.dtic.mil/whs/directives/corres/pdf/850001p.pdf
You can consult with The Common Criteria for Information
technology Security Evaluation
http://www.commoncriteriaportal.org/
also each department may have is own regulatory requirements:
see section 2-5 on page 8 of this document:
http://www.fas.org/irp/doddir/army/r380_19.pdf
Just adding MLS does not make a DBMS, a trusted one.
Best
Patrick K.
On 1/31/2011 6:49 AM, Ger Lawlor (gelawlor) wrote:
Thanks. Where do I get info on DBMS’s that
are trusted? I have
considerations for Oracle Timesten, Informix IDS server and
PostgresSQL.
Are there specific projects for these?
*From:*Andy Warner [mailto:warner@xxxxxxxxx]
*Sent:* Monday, January 31, 2011 11:46 AM
*To:* cto@xxxxxxxxxxxxxxxxxx
*Cc:* Ger Lawlor (gelawlor); KaiGai Kohei; selinux@xxxxxxxxxxxxx
*Subject:* Re: Tiny version of SE-PostgreSQL got merged
I would add that using a partitioned architecture (e.g., "it is
possible
to achieve this by separation of databases and their storage
location")
is not the same as having an integrated MLS database. There are
certain
abilities that will not be nativly available, such as row based
polyinstantiation (I realize PG does not do this but others MLS
DBMS's
do), true multi-level table views, and intra-table, inter-level
key
uniqueness. There are other functionality that also would not be
possible with a partitioned approach. This is why, at least on
some
level, Trusted DBMS's (MLS and other policies) continue to
exist.
On 1/31/2011 12:23 PM, cto@xxxxxxxxxxxxxxxxxx
<mailto:cto@xxxxxxxxxxxxxxxxxx> wrote:
Hello Ger.
I actually asked this before from Mr. Kohei, and we had a hot
debate
here I refer you to this archive:
http://marc.info/?l=selinux&m=129178180819602&w=2
<http://marc.info/?l=selinux&m=129178180819602&w=2>
Also this is original proposal of the project from Mr. KaiGai
Kohei
http://sepgsql.googlecode.com/files/PGcon2010-KaiGai-LAPP_SELinux.pdf
In brief:
Since it is possible to use file labels and database locations
and have
multiple instances of Postgresql as it is process based daemon,
and just
separate classified and unclassified databases from each other
BUT:
the goal of Mr. KaiGai Kohei and se-postgresql project is to
introduce
MLS (Multilevel Security) to the structure of the database and
its ACL
model for each user of the database in example up to the rows
and
columns, so in practice THEORETICALLY it would be possible to
mix
classified or unclassified records within a single database and
have
various levels of users with different levels of access
(however in practice it may not be recommended)
Currently with PostgreSQL it is possible to achieve this by
separation
of databases and their storage location; you have to completely
separate
the datases, processes and daemons accessing such resources up
to
different classifications you want to serve records on an MLS
systems.
Best,
Patrick K.
On 1/31/2011 5:09 AM, Ger Lawlor (gelawlor) wrote:
I'm only new to SeLinux, but will have requirements around
PostgreSQL.
Can you give me some background and info on why
This SE-PostgresQL exists? Is it specific to this database, or
are there
similar projects for other database types?
Was it not possible to label files within a default
installation? Was
this insufficient for Postgres security?
Thanks,
Ger.
-----Original Message-----
From: owner-selinux@xxxxxxxxxxxxx
<mailto:owner-selinux@xxxxxxxxxxxxx>
[mailto:owner-selinux@xxxxxxxxxxxxx]
On Behalf Of KaiGai Kohei
Sent: Monday, January 31, 2011 8:14 AM
To: selinux@xxxxxxxxxxxxx <mailto:selinux@xxxxxxxxxxxxx>
Subject: Tiny version of SE-PostgreSQL got merged
A few days ago, a tiny initial version of SE-PostgreSQL got
merged
in the v9.1 development cycle at this commit:
http://bit.ly/gF2QPQ
Although it omits various features which I planned at first, it
seems to me an ambitious first step.
PostgreSQL has shifted to provide a set of facilities to
implement
label based mandatory access control, such as security label
support
on database objects or security hooks being available for
plug-in
modules.
The current version of SE-PostgreSQL is implemented as a plugin
module that utilizes these hooks (but only a limited places are
covered), then it asks SELinux in kernel whether the required
access shall be allowed, or not.
In the next development, I'd like to expand its access control
coverage
using more fine grained security hooks. Right now, DDL
permissions are
restrictions. Also, row-level security is in-progress feature.
I have much things to do for the v9.2 or v9.3, however, I'd like
to
appreciate people who have given me many feedbacks since 2006
Thanks,
--
This message was distributed to subscribers of the selinux
mailing list.
If you no longer wish to subscribe, send mail to
majordomo@xxxxxxxxxxxxx
<mailto:majordomo@xxxxxxxxxxxxx> with
the words "unsubscribe selinux" without quotes as the message.
--
This message was distributed to subscribers of the selinux mailing
list.
If you no longer wish to subscribe, send mail to
majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
|
