[ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

SE-PostgreSQL 8.2.3-1.0 alpha was released as follows.

The purpose of this version is to get any feedback from the open source
community like requirements, your opinion, bug reports and so on.
The developer welcomes anything to improve.

======================================================================
Security Enhanced PostgreSQL 8.2.3-1.0 alpha release
======================================================================

Security Enhanced PostgreSQL (SE-PostgreSQL) is an extension of PostgreSQL,
provides fine grained mandatory access control based on the interaction
with SELinux and its security policy.
Those facilities of SE-PostgreSQL enables to build RDBMS into information
flow control scheme integrated with operating system, and protects your
information asset from threats like leaking, defacing and so on.

* Fine grained access control
SE-PostgreSQL enables access control onto row and column level.
The native PostgreSQL access control list does not provide any access
control onto database objects less than table, so SE-PostgreSQL enables
DBA to setup finer-grained and flexible access control.

* Mandatory access control
An access control mechanism provided by SE-PostgreSQL is applied to any
SQL queries including the ones come from privileged database users.
So, SE-PostgreSQL works as a userspace reference monitor.

* Interaction between SELinux and SE-PostgreSQL
An access control mechanism provided by SE-PostgreSQL makes its decision
based on the security policy of SELinux. The database client's authority
is determined by the security context of the peer process.

(*) The purpose of this version of SE-PostgreSQL is to get any feedback
    from the open source community like requirements and bug-reports.
    Thus, you should pay attention about what we have not verified enough
    quality of the code yet.

(*) The development of this software is under the assist of Exploratory
    Software Project (second half of 2006), IPA Japan.


======================================================================
[Installation]
You can set up SE-PostgreSQL on Fedora Core 6 system, SELinux installed.
Get RPM packages from the following URL:
  http://code.google.com/p/sepgsql/downloads/list
    selinux-policy-2.4.6-40.sepgsql.noarch.rpm
    selinux-policy-targeted-2.4.6-40.sepgsql.noarch.rpm
    sepostgresql-8.2.3-0.206a.i386.rpm

Install the selinux-policy and the selinux-policy-targeted package at first,
and the sepostgresql package next.
The default security policy of SE-PostgreSQL is also installed when
the sepostgresql package is installed.
(*) If you use 'psql' as a front-end, postgresql and postgresql-libs packages
    are necessary.

Run the following script to initialize the database cluster:

  # /etc/init.d/sepostgresql initdb

The database cluster is generated under /var/lib/sepgsql/data .

Run the following script to start up SE-PostgreSQL server, after you
confirm the native PostgreSQL server is stopping.

  # /etc/init.d/sepostgresql start

The database cluster is initialized by 'sepgsql' user.
You can translate 'sepgsql' user via 'su' command to create database,
database role and so on.
  [example]
  # su - sepgsql
  $ createuser kaigai
  Shall the new role be a superuser? (y/n) y
  CREATE ROLE
  $ createdb kaigaidb
  CREATE DATABASE
  $

======================================================================
[A sample database for playing]

CREATE TABLE drink (
    did     integer primary key,
    dname   text,
    dprice  integer,
    dsoft   bool,
    dstock  integer
);

ALTER TABLE drink ALTER dstock
    context = 'user_u:object_r:sepgsql_secret_table_t';

INSERT INTO drink VALUES (1, 'juice', 110, true,  35);
INSERT INTO drink VALUES (2, 'coke',  110, true,  20);
INSERT INTO drink VALUES (3, 'milk',  130, true,   5);
INSERT INTO drink VALUES (4, 'water', 100, true,  10);
INSERT INTO drink VALUES (5, 'beer',  240, false, 15);
INSERT INTO drink VALUES (6, 'wine',  380, false,  0);

UPDATE drink SET security_context = 'user_u:object_r:sepgsql_table_t:SystemHigh'
    where dsoft = false;

create or replace function drink_stock_exist (integer)
    returns bool
    language 'sql'
    as 'select dstock > 0 from drink where did = $1';

ALTER FUNCTION drink_stock_exist(integer)
    context = 'user_u:object_r:sepgsql_trusted_proc_t';


======================================================================
[A example of SQL execution]

$ id -Z
root:system_r:unconfined_t:SystemLow-SystemHigh
$ psql -q
kaigai=# select sepgsql_getcon();
                 sepgsql_getcon
-------------------------------------------------
 root:system_r:unconfined_t:SystemLow-SystemHigh
(1 row)

kaigai=# select * from drink;
 did | dname | dprice | dsoft | dstock
-----+-------+--------+-------+--------
   1 | juice |    110 | t     |     35
   2 | coke  |    110 | t     |     20
   3 | milk  |    130 | t     |      5
   4 | water |    100 | t     |     10
   5 | beer  |    240 | f     |     15
   6 | wine  |    380 | f     |      0
(6 rows)

## The security context of each tuples are stored in 'security_context'
## system column.
kaigai=# select security_context,* from drink;
        security_context         | did | dname | dprice | dsoft | dstock
---------------------------------+-----+-------+--------+-------+--------
 user_u:object_r:sepgsql_table_t |   1 | juice |    110 | t     |     35
 user_u:object_r:sepgsql_table_t |   2 | coke  |    110 | t     |     20
 user_u:object_r:sepgsql_table_t |   3 | milk  |    130 | t     |      5
 user_u:object_r:sepgsql_table_t |   4 | water |    100 | t     |     10
 user_u:object_r:sepgsql_table_t |   5 | beer  |    240 | f     |     15
 user_u:object_r:sepgsql_table_t |   6 | wine  |    380 | f     |      0
(6 rows)

kaigai=#

## A example of execution under lower authority:
## The two tuples which have 'SystemHigh' were filtered.

$ runcon -l s0 -- bash
$ id -Z
root:system_r:unconfined_t
$ psql -q
kaigai=# select sepgsql_getcon();
       sepgsql_getcon
----------------------------
 root:system_r:unconfined_t
(1 row)

kaigai=# select * from drink;
NOTICE:  SELinux: denied { select } scontext=root:system_r:unconfined_t tcontext=user_u:object_r:sepgsql_table_t:SystemHigh tclass=tuple
NOTICE:  SELinux: denied { select } scontext=root:system_r:unconfined_t tcontext=user_u:object_r:sepgsql_table_t:SystemHigh tclass=tuple
 did | dname | dprice | dsoft | dstock
-----+-------+--------+-------+--------
   1 | juice |    110 | t     |     35
   2 | coke  |    110 | t     |     20
   3 | milk  |    130 | t     |      5
   4 | water |    100 | t     |     10
(4 rows)

kaigai=#
$ exit

## We tried to connect from a domain which cannot access 'sepgsql_secret_table_t'

$ runcon -t initrc_t -- bash
$ id -Z
root:system_r:initrc_t:SystemLow-SystemHigh
$ psql -q
kaigai=# select * from drink;
ERROR:  SELinux: denied { select } scontext=root:system_r:initrc_t:SystemLow-SystemHigh tcontext=user_u:object_r:sepgsql_secret_table_t tclass=column name=dstock

## The client in initrc_t domain cannot access dstock column which has
## sepgsql_table_t type, but we cann access the column via trusted
## procedure only.

kaigai=# select did, dname, dprice, drink_stock_exist(did) from drink;
 did | dname | dprice | drink_stock_exist
-----+-------+--------+-------------------
   1 | juice |    110 | t
   2 | coke  |    110 | t
   3 | milk  |    130 | t
   4 | water |    100 | t
   5 | beer  |    240 | t
   6 | wine  |    380 | f
(6 rows)

kaigai=#

======================================================================
[Hint]
* There is no compatibility between SE-PostgreSQL and PostgreSQL.
  You have to pay attention not to destroy your database files
  for native PostgreSQL.

* You can enable/disable access allowed/denied messages by using
  boolean stuff of SELinux. Set the following booleans by setsebool
  command.
      sepgsql_enable_auditallow
      sepgsql_enable_auditdeny
      sepgsql_enable_audittuple

* initrc_t is defined as a less power domain for test purpose.
  We cannot use DDL statement from initrc_t domain, and cannot
  access tables, columns and tuples with sepgsql_secret_table_t
  type.

* The security policy for SE-PostgreSQL under the strict policy is now
  under development. You have to switch to the targeted policy, if you
  try to use this version.

-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Hello,

The attached patch adds new object classes, access vectors and
booleans related to database.
SE-PostgreSQL uses them to manage the various kinds of database
objects such as tables, columns, tuples and so on.

The most of security policies are provided as a binary security
policy within RPM package. But it requires the definition of new
object classes, access vectors and booleans in the base policy.

Please apply it.

BTW, SE-PostgreSQL does 'semodule -i' in the %post section of RPM
installation script after a verification whether an older version
of sepostgresql.pp has been already installed, or not.
I think the description of script can become easier, if semodule
has 'install or upgrade if older version was installed' option.
How is the idea?
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

[-- Attachment #2: policy-sepgsql.patch --]
[-- Type: text/x-patch, Size: 3612 bytes --]

Index: refpolicy/policy/flask/security_classes
===================================================================
--- refpolicy/policy/flask/security_classes	(revision 2204)
+++ refpolicy/policy/flask/security_classes	(working copy)
@@ -97,4 +97,12 @@
 
 class dccp_socket
 
+# SE-PostgreSQL relation
+class database			# userspace
+class table			# userspace
+class procedure			# userspace
+class column			# userspace
+class tuple			# userspace
+class blob			# userspace
+
 # FLASK
Index: refpolicy/policy/flask/access_vectors
===================================================================
--- refpolicy/policy/flask/access_vectors	(revision 2204)
+++ refpolicy/policy/flask/access_vectors	(working copy)
@@ -80,6 +80,20 @@
 }
 
 #
+#  Define a common prefix for userspace database object access vectors.
+#
+
+common database
+{
+	create
+	drop
+	getattr
+	setattr
+	relabelfrom
+	relabelto
+}
+
+#
 # Define the access vectors.
 #
 # class class_name [ inherits common_name ] { permission_name ... }
@@ -648,3 +662,58 @@
 	node_bind
 	name_connect
 }
+
+# definition for SE-PostgreSQL
+class database
+inherits database
+{
+	access
+	install_module
+	load_module
+	get_param
+	set_param
+}
+
+class table
+inherits database
+{
+	select
+	update
+	insert
+	delete
+	lock
+}
+
+class procedure
+inherits database
+{
+	execute
+	entrypoint
+}
+
+class column
+inherits database
+{
+	select
+	update
+	insert
+}
+
+class tuple
+{
+	relabelfrom
+	relabelto
+	select
+	update
+	insert
+	delete
+}
+
+class blob
+inherits database
+{
+	read
+	write
+	import
+	export
+}
Index: refpolicy/policy/mcs
===================================================================
--- refpolicy/policy/mcs	(revision 2204)
+++ refpolicy/policy/mcs	(working copy)
@@ -98,4 +98,28 @@
 mlsconstrain process { sigkill sigstop }
 	(( h1 dom h2 ) or ( t1 == mcskillall ));
 
+# MCS policy for SE-PostgreSQL
+#-------------------------------
+
+# Any database object must be dominated by the relabeling subject
+# clearance, also the objects are single-level.
+mlsconstrain { database table procedure column blob } { create relabelto }
+	((h1 dom h2) and ( l1 domby h2 ) and ( l2 eq h2 ));
+mlsconstrain tuple { insert relabelto }
+	(( h1 dom h2 ) and ( l1 domby h2 ) and ( l2 eq h2 ));
+
+# Access control for any database objects based on MCS rules.
+mlsconstrain database { drop setattr relabelfrom access install_module load_module get_param set_param }
+	( h1 dom h2 );
+mlsconstrain table { drop setattr relabelfrom select update insert delete }
+	( h1 dom h2 );
+mlsconstrain column { drop setattr relabelfrom select update insert }
+	( h1 dom h2 );
+mlsconstrain tuple { relabelfrom select update delete }
+	( h1 dom h2 );
+mlsconstrain procedure { execute }
+	( h1 dom h2 );
+mlsconstrain blob { drop setattr relabelfrom read write }
+	( h1 dom h2 );
+
 ') dnl end enable_mcs
Index: refpolicy/policy/global_tunables
===================================================================
--- refpolicy/policy/global_tunables	(revision 2204)
+++ refpolicy/policy/global_tunables	(working copy)
@@ -11,6 +11,27 @@
 
 ## <desc>
 ## <p>
+## Enable to output SE-PostgreSQL allowed audit message
+## </p>
+## </desc>
+gen_tunable(sepgsql_enable_auditallow, false)
+
+## <desc>
+## <p>
+## Disable to output SE-PostgreSQL denied audit messages
+## </p>
+## </desc>
+gen_tunable(sepgsql_enable_auditdeny, true)
+
+## <desc>
+## <p>
+## Disable to output SE-PostgreSQL audit message per tuple
+## </p>
+## </desc>
+gen_tunable(sepgsql_enable_audittuple, false)
+
+## <desc>
+## <p>
 ## Allow cvs daemon to read shadow
 ## </p>
 ## </desc>

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Russell Coker]

On Monday 05 March 2007 23:29, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> SE-PostgreSQL 8.2.3-1.0 alpha was released as follows.

Congratulations on making this release, this is great work and a significant 
milestone in SE Linux development!

> Get RPM packages from the following URL:
>   http://code.google.com/p/sepgsql/downloads/list
>     selinux-policy-2.4.6-40.sepgsql.noarch.rpm
>     selinux-policy-targeted-2.4.6-40.sepgsql.noarch.rpm
>     sepostgresql-8.2.3-0.206a.i386.rpm
>
> Run the following script to initialize the database cluster:
>
>   # /etc/init.d/sepostgresql initdb
>
> The database cluster is generated under /var/lib/sepgsql/data .

Why do you have a different name and different database location?  Why not 
just call it postgresql and have the same locations and script names?

When I make such releases I just use a newer package version.

> Run the following script to start up SE-PostgreSQL server, after you
> confirm the native PostgreSQL server is stopping.
>
>   # /etc/init.d/sepostgresql start

Why must you confirm that the native postgresql server is stopped?  Is it a 
matter of ports and named pipes for communication with clients?  If you can 
have both packages installed at the same time then some people will want to 
run them both at once.

> * There is no compatibility between SE-PostgreSQL and PostgreSQL.
>   You have to pay attention not to destroy your database files
>   for native PostgreSQL.

Have you considered enabling "permissive mode" for the database server such 
that it can run with unlabeled databases?

Why can't "native PostgreSQL" just ignore the labelling?

I think it would be good if all the compatibility options that are available 
for ext2/3 were available for databases.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

>> Run the following script to initialize the database cluster:
>>
>>   # /etc/init.d/sepostgresql initdb
>>
>> The database cluster is generated under /var/lib/sepgsql/data .
> 
> Why do you have a different name and different database location?  Why not 
> just call it postgresql and have the same locations and script names?
> 
> When I make such releases I just use a newer package version.

The same package name or the same database location means that users have
to uninstall the native PostgreSQL. I thought that users can avoid conflict
is better.

>> Run the following script to start up SE-PostgreSQL server, after you
>> confirm the native PostgreSQL server is stopping.
>>
>>   # /etc/init.d/sepostgresql start
> 
> Why must you confirm that the native postgresql server is stopped?  Is it a 
> matter of ports and named pipes for communication with clients?  If you can 
> have both packages installed at the same time then some people will want to 
> run them both at once.

The purpose is to avoid conflict of tcp/5432 port in the most simple way.
If you want to use both package at same time, alternative tcp port should be
written at /etc/sysconfig/sepostgresql .

>> * There is no compatibility between SE-PostgreSQL and PostgreSQL.
>>   You have to pay attention not to destroy your database files
>>   for native PostgreSQL.
> 
> Have you considered enabling "permissive mode" for the database server such 
> that it can run with unlabeled databases?
>
> Why can't "native PostgreSQL" just ignore the labelling?

We have to store a security context of tuple in anywhere, so modifying the file
format was not avoidable. The storage manager of PostgreSQL cannot handle different
file formats, so SE-PostgreSQL cannot run over the unlabeled databased generated
by native PostgreSQL.

It might be possible, but I expect more hooks to the PostgreSQL is necessary.
It will prevent to follow the version-up of native one.

Thanks,

> I think it would be good if all the compatibility options that are available 
> for ext2/3 were available for databases.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Wed, 2007-03-07 at 04:05 +0900, KaiGai Kohei wrote:
> >> * There is no compatibility between SE-PostgreSQL and PostgreSQL.
> >>   You have to pay attention not to destroy your database files
> >>   for native PostgreSQL.
> > 
> > Have you considered enabling "permissive mode" for the database server such 
> > that it can run with unlabeled databases?
> >
> > Why can't "native PostgreSQL" just ignore the labelling?
> 
> We have to store a security context of tuple in anywhere, so modifying the file
> format was not avoidable. The storage manager of PostgreSQL cannot handle different
> file formats, so SE-PostgreSQL cannot run over the unlabeled databased generated
> by native PostgreSQL.
> 
> It might be possible, but I expect more hooks to the PostgreSQL is necessary.
> It will prevent to follow the version-up of native one.

Do they provide any kind of attribute / metadata support at that
granularity?  Along the lines of filesystem xattrs?

Could you store the labels in a separate table?  Along the lines of the
old persistent label mapping in SELinux (issues for consistency and
performance, of course).

Could you split the storage from the presentation such that you only
store data of one context in a given underlying table and then compose a
set of single context tables to present a multi-context virtual table?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Russell Coker]

On Wednesday 07 March 2007 06:17, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > We have to store a security context of tuple in anywhere, so modifying
> > the file format was not avoidable. The storage manager of PostgreSQL
> > cannot handle different file formats, so SE-PostgreSQL cannot run over
> > the unlabeled databased generated by native PostgreSQL.
> >
> > It might be possible, but I expect more hooks to the PostgreSQL is
> > necessary. It will prevent to follow the version-up of native one.
>
> Do they provide any kind of attribute / metadata support at that
> granularity?  Along the lines of filesystem xattrs?
>
> Could you store the labels in a separate table?  Along the lines of the
> old persistent label mapping in SELinux (issues for consistency and
> performance, of course).

The labelling for tables and columns could be stored in a different table as 
they don't change much.

The labelling of rows could be stored in an extra column in the table.

Then if the non-SE version of PostgreSQL had some code to ignore the SE Linux 
column then we would have fairly good compatibility.

Kohei-san, is this a viable idea?

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Stephen Smalley wrote:
> On Wed, 2007-03-07 at 04:05 +0900, KaiGai Kohei wrote:
>>>> * There is no compatibility between SE-PostgreSQL and PostgreSQL.
>>>>   You have to pay attention not to destroy your database files
>>>>   for native PostgreSQL.
>>> Have you considered enabling "permissive mode" for the database server such 
>>> that it can run with unlabeled databases?
>>>
>>> Why can't "native PostgreSQL" just ignore the labelling?
>> We have to store a security context of tuple in anywhere, so modifying the file
>> format was not avoidable. The storage manager of PostgreSQL cannot handle different
>> file formats, so SE-PostgreSQL cannot run over the unlabeled databased generated
>> by native PostgreSQL.
>>
>> It might be possible, but I expect more hooks to the PostgreSQL is necessary.
>> It will prevent to follow the version-up of native one.
> 
> Do they provide any kind of attribute / metadata support at that
> granularity?  Along the lines of filesystem xattrs?

Any kind of database objects (like tables, columns) are stored as tuples within
special tables called as system catalog, so I think that associating a security
context with a tuple provides enough granularity.
# The meaning of your question was a bit unclear for me.
# If my response is miss the point, please tell me.

> Could you store the labels in a separate table?  Along the lines of the
> old persistent label mapping in SELinux (issues for consistency and
> performance, of course).

I think unique identification for all tuples are difficult, because we can
create a table without Oid (object id) or primary key to identify a tuple
from outside of the table...

BTW, the string representations of security contexts are stored in a separate
table named as 'pg_selinux', defined with Oid (which have 4-byte length).
In SE-PostgreSQL, any tuples have Oid of pg_selinux as a security context.
Thus, storage consumption is limited.

> Could you split the storage from the presentation such that you only
> store data of one context in a given underlying table and then compose a
> set of single context tables to present a multi-context virtual table?
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Russell Coker wrote:
> On Wednesday 07 March 2007 06:17, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> We have to store a security context of tuple in anywhere, so modifying
>>> the file format was not avoidable. The storage manager of PostgreSQL
>>> cannot handle different file formats, so SE-PostgreSQL cannot run over
>>> the unlabeled databased generated by native PostgreSQL.
>>>
>>> It might be possible, but I expect more hooks to the PostgreSQL is
>>> necessary. It will prevent to follow the version-up of native one.
>> Do they provide any kind of attribute / metadata support at that
>> granularity?  Along the lines of filesystem xattrs?
>>
>> Could you store the labels in a separate table?  Along the lines of the
>> old persistent label mapping in SELinux (issues for consistency and
>> performance, of course).
> 
> The labelling for tables and columns could be stored in a different table as 
> they don't change much.
> 
> The labelling of rows could be stored in an extra column in the table.
> 
> Then if the non-SE version of PostgreSQL had some code to ignore the SE Linux 
> column then we would have fairly good compatibility.
> 
> Kohei-san, is this a viable idea?

Russell,

Actually, I tried to use an extra (hidden) column to store a security context,
but gave up this approach.
# The following branch is the one just before I gave up:
#   http://sepgsql.googlecode.com/svn/branches/sepgsql_070210/

It did not resolve file format issue, because we have to add an extra column
into system catalog to associate a security context with table, column and so on.

(*) system catalog is a table to store the meta-information
     like the definition of the table.

The definition of system catalogs are hard-coded in the header files, so adding
an extra column could not avoid to break the database file format compatibility....

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Casey Schaufler]

--- KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:

 
> I think unique identification for all tuples are
> difficult, because we can
> create a table without Oid (object id) or primary
> key to identify a tuple
> from outside of the table...
> 
> BTW, the string representations of security contexts
> are stored in a separate
> table named as 'pg_selinux', defined with Oid (which
> have 4-byte length).
> In SE-PostgreSQL, any tuples have Oid of pg_selinux
> as a security context.
> Thus, storage consumption is limited.

How does this method compare to the schemes
used in the Oracle evaluated MLS DBMS?


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[James W. Hoeft]

Casey Schaufler wrote:
> --- KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> 
>  
>> I think unique identification for all tuples are
>> difficult, because we can
>> create a table without Oid (object id) or primary
>> key to identify a tuple
>> from outside of the table...
>>
>> BTW, the string representations of security contexts
>> are stored in a separate
>> table named as 'pg_selinux', defined with Oid (which
>> have 4-byte length).
>> In SE-PostgreSQL, any tuples have Oid of pg_selinux
>> as a security context.
>> Thus, storage consumption is limited.
> 
> How does this method compare to the schemes
> used in the Oracle evaluated MLS DBMS?

MLS ("Trusted Oracle", rev 9 was last one produced and is no longer 
supported) or current OLS? The mechanisms and level of certification are 
different.

Jim

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Joshua Brindle]

Casey Schaufler wrote:
> --- KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>
>  
>   
>> I think unique identification for all tuples are
>> difficult, because we can
>> create a table without Oid (object id) or primary
>> key to identify a tuple
>> from outside of the table...
>>
>> BTW, the string representations of security contexts
>> are stored in a separate
>> table named as 'pg_selinux', defined with Oid (which
>> have 4-byte length).
>> In SE-PostgreSQL, any tuples have Oid of pg_selinux
>> as a security context.
>> Thus, storage consumption is limited.
>>     
>
> How does this method compare to the schemes
> used in the Oracle evaluated MLS DBMS?
>
>   
IIRC Oracle basically has polyinstanciated tables (using views) to 
implement MLS, which gives far less granularity and doesn't allow for 
labeled rows or columns. KaiGai's work leverages all the security models 
SELinux can use to allow for flexible policies. The technical decision 
to use another table to store the oid of the context seems appropriate, 
since that is how rdbms's operate in general.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Christopher J. PeBenito]

On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
> The attached patch adds new object classes, access vectors and
> booleans related to database.
> SE-PostgreSQL uses them to manage the various kinds of database
> objects such as tables, columns, tuples and so on.
> 
> The most of security policies are provided as a binary security
> policy within RPM package. But it requires the definition of new
> object classes, access vectors and booleans in the base policy.
> 
> Please apply it.

Is the code on a path to being merged upstream?  I'm hesitant to apply
class changes until the code is on a plan to be merged.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Joshua Brindle wrote:
> Casey Schaufler wrote:
>> --- KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>>
>>  
>>  
>>> I think unique identification for all tuples are
>>> difficult, because we can
>>> create a table without Oid (object id) or primary
>>> key to identify a tuple
>>> from outside of the table...
>>>
>>> BTW, the string representations of security contexts
>>> are stored in a separate
>>> table named as 'pg_selinux', defined with Oid (which
>>> have 4-byte length).
>>> In SE-PostgreSQL, any tuples have Oid of pg_selinux
>>> as a security context.
>>> Thus, storage consumption is limited.
>>>     
>>
>> How does this method compare to the schemes
>> used in the Oracle evaluated MLS DBMS?
>>
>>   
> IIRC Oracle basically has polyinstanciated tables (using views) to 
> implement MLS, which gives far less granularity and doesn't allow for 
> labeled rows or columns. KaiGai's work leverages all the security models 
> SELinux can use to allow for flexible policies. The technical decision 
> to use another table to store the oid of the context seems appropriate, 
> since that is how rdbms's operate in general.

I think the biggest difference is whether RDBMS utilizes the security
functionalities of operating system, or not.

For example, SE-PostgreSQL obtains the security context of the client via
getpeercon(), and makes a decision with the security policy.
It enables to ensure a process with lower clearance cannot access secret
data, even if it is stored in database.

In my understanding, Oracle pay no attention for the peer's clearance.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Thu, 2007-03-08 at 22:12 +0900, KaiGai Kohei wrote:
> Joshua Brindle wrote:
> > Casey Schaufler wrote:
> >> --- KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> >>
> >>  
> >>  
> >>> I think unique identification for all tuples are
> >>> difficult, because we can
> >>> create a table without Oid (object id) or primary
> >>> key to identify a tuple
> >>> from outside of the table...
> >>>
> >>> BTW, the string representations of security contexts
> >>> are stored in a separate
> >>> table named as 'pg_selinux', defined with Oid (which
> >>> have 4-byte length).
> >>> In SE-PostgreSQL, any tuples have Oid of pg_selinux
> >>> as a security context.
> >>> Thus, storage consumption is limited.
> >>>     
> >>
> >> How does this method compare to the schemes
> >> used in the Oracle evaluated MLS DBMS?
> >>
> >>   
> > IIRC Oracle basically has polyinstanciated tables (using views) to 
> > implement MLS, which gives far less granularity and doesn't allow for 
> > labeled rows or columns. KaiGai's work leverages all the security models 
> > SELinux can use to allow for flexible policies. The technical decision 
> > to use another table to store the oid of the context seems appropriate, 
> > since that is how rdbms's operate in general.
> 
> I think the biggest difference is whether RDBMS utilizes the security
> functionalities of operating system, or not.
> 
> For example, SE-PostgreSQL obtains the security context of the client via
> getpeercon(), and makes a decision with the security policy.
> It enables to ensure a process with lower clearance cannot access secret
> data, even if it is stored in database.

You also should be leveraging the OS in protecting SE-PostgreSQL from
interference by the client and ensuring that it is unbypassable for
accessing the database.  Are you just using the stock postgresql domain
in the refpolicy at present?  Any analysis of that domain and whether it
meets your needs adequately?  (side bar:  it seems to have a lot of
capabilities presently)

> In my understanding, Oracle pay no attention for the peer's clearance.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
>> The attached patch adds new object classes, access vectors and
>> booleans related to database.
>> SE-PostgreSQL uses them to manage the various kinds of database
>> objects such as tables, columns, tuples and so on.
>>
>> The most of security policies are provided as a binary security
>> policy within RPM package. But it requires the definition of new
>> object classes, access vectors and booleans in the base policy.
>>
>> Please apply it.
> 
> Is the code on a path to being merged upstream?  I'm hesitant to apply
> class changes until the code is on a plan to be merged.

Pushing to the upstreamed PostgreSQL is one of the next activities.
No need to say, I'm targeting it to be merged as a part of PostgreSQL.

I'll submit a patch to add new object classes again after discussion
in the pgsql-hackers list. But I'm desiring the object class numbers
are fixed earlier. (currently, I uses 60 - 65 to represent them)

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Thu, 2007-03-08 at 22:33 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
> >> The attached patch adds new object classes, access vectors and
> >> booleans related to database.
> >> SE-PostgreSQL uses them to manage the various kinds of database
> >> objects such as tables, columns, tuples and so on.
> >>
> >> The most of security policies are provided as a binary security
> >> policy within RPM package. But it requires the definition of new
> >> object classes, access vectors and booleans in the base policy.
> >>
> >> Please apply it.
> > 
> > Is the code on a path to being merged upstream?  I'm hesitant to apply
> > class changes until the code is on a plan to be merged.
> 
> Pushing to the upstreamed PostgreSQL is one of the next activities.
> No need to say, I'm targeting it to be merged as a part of PostgreSQL.
> 
> I'll submit a patch to add new object classes again after discussion
> in the pgsql-hackers list. But I'm desiring the object class numbers
> are fixed earlier. (currently, I uses 60 - 65 to represent them)

Where do things stand wrt dynamic userspace object class and permission
discovery?  It would be nice to avoid further spread of hardcoded
classes and permissions in applications if we can avoid it.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2007-03-08 at 22:12 +0900, KaiGai Kohei wrote:
>> Joshua Brindle wrote:
>>> Casey Schaufler wrote:
>>>> --- KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>>>>
>>>>  
>>>>  
>>>>> I think unique identification for all tuples are
>>>>> difficult, because we can
>>>>> create a table without Oid (object id) or primary
>>>>> key to identify a tuple
>>>>> from outside of the table...
>>>>>
>>>>> BTW, the string representations of security contexts
>>>>> are stored in a separate
>>>>> table named as 'pg_selinux', defined with Oid (which
>>>>> have 4-byte length).
>>>>> In SE-PostgreSQL, any tuples have Oid of pg_selinux
>>>>> as a security context.
>>>>> Thus, storage consumption is limited.
>>>>>     
>>>> How does this method compare to the schemes
>>>> used in the Oracle evaluated MLS DBMS?
>>>>
>>>>   
>>> IIRC Oracle basically has polyinstanciated tables (using views) to 
>>> implement MLS, which gives far less granularity and doesn't allow for 
>>> labeled rows or columns. KaiGai's work leverages all the security models 
>>> SELinux can use to allow for flexible policies. The technical decision 
>>> to use another table to store the oid of the context seems appropriate, 
>>> since that is how rdbms's operate in general.
>> I think the biggest difference is whether RDBMS utilizes the security
>> functionalities of operating system, or not.
>>
>> For example, SE-PostgreSQL obtains the security context of the client via
>> getpeercon(), and makes a decision with the security policy.
>> It enables to ensure a process with lower clearance cannot access secret
>> data, even if it is stored in database.
> 
> You also should be leveraging the OS in protecting SE-PostgreSQL from
> interference by the client and ensuring that it is unbypassable for
> accessing the database.  Are you just using the stock postgresql domain
> in the refpolicy at present?  Any analysis of that domain and whether it
> meets your needs adequately?  (side bar:  it seems to have a lot of
> capabilities presently)

The security policy included in sepostgresql rpm package uses stock
postgresql_t domin in the refpolicy, almost as is.

I have not analyzed them yet.
Indeed, we should pay more attention for accessing the database
files directly.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2007-03-08 at 22:33 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
>>>> The attached patch adds new object classes, access vectors and
>>>> booleans related to database.
>>>> SE-PostgreSQL uses them to manage the various kinds of database
>>>> objects such as tables, columns, tuples and so on.
>>>>
>>>> The most of security policies are provided as a binary security
>>>> policy within RPM package. But it requires the definition of new
>>>> object classes, access vectors and booleans in the base policy.
>>>>
>>>> Please apply it.
>>> Is the code on a path to being merged upstream?  I'm hesitant to apply
>>> class changes until the code is on a plan to be merged.
>> Pushing to the upstreamed PostgreSQL is one of the next activities.
>> No need to say, I'm targeting it to be merged as a part of PostgreSQL.
>>
>> I'll submit a patch to add new object classes again after discussion
>> in the pgsql-hackers list. But I'm desiring the object class numbers
>> are fixed earlier. (currently, I uses 60 - 65 to represent them)
> 
> Where do things stand wrt dynamic userspace object class and permission
> discovery?  It would be nice to avoid further spread of hardcoded
> classes and permissions in applications if we can avoid it.

See, http://sepgsql.googlecode.com/svn/trunk/src/include/security/sepgsql_internal.h
When I started to develop, 'context' class has the maximum number of object
class, so I defined 'SECCLASS_DATABASE' next to it.
# But it will conflict with 'dccp_socket' class now... :-(

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Thu, 2007-03-08 at 23:50 +0900, KaiGai Kohei wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-03-08 at 22:33 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>> On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
> >>>> The attached patch adds new object classes, access vectors and
> >>>> booleans related to database.
> >>>> SE-PostgreSQL uses them to manage the various kinds of database
> >>>> objects such as tables, columns, tuples and so on.
> >>>>
> >>>> The most of security policies are provided as a binary security
> >>>> policy within RPM package. But it requires the definition of new
> >>>> object classes, access vectors and booleans in the base policy.
> >>>>
> >>>> Please apply it.
> >>> Is the code on a path to being merged upstream?  I'm hesitant to apply
> >>> class changes until the code is on a plan to be merged.
> >> Pushing to the upstreamed PostgreSQL is one of the next activities.
> >> No need to say, I'm targeting it to be merged as a part of PostgreSQL.
> >>
> >> I'll submit a patch to add new object classes again after discussion
> >> in the pgsql-hackers list. But I'm desiring the object class numbers
> >> are fixed earlier. (currently, I uses 60 - 65 to represent them)
> > 
> > Where do things stand wrt dynamic userspace object class and permission
> > discovery?  It would be nice to avoid further spread of hardcoded
> > classes and permissions in applications if we can avoid it.
> 
> See, http://sepgsql.googlecode.com/svn/trunk/src/include/security/sepgsql_internal.h
> When I started to develop, 'context' class has the maximum number of object
> class, so I defined 'SECCLASS_DATABASE' next to it.
> # But it will conflict with 'dccp_socket' class now... :-(

Yes, you'll have to re-base.  Of course, you should be using the
libselinux headers instead of your own private definitions, i.e.
	cd refpolicy/policy/flask
	(update security_classes and access_vectors to add your defs)
	make
	make LIBSEL=/path/to/libselinux tolib
	cd /path/to/libselinux
	make install relabel

Then just #include <selinux/flask.h> and #include
<selinux/av_permissions.h> in your SE-PostgreSQL code.  Don't duplicate
the definitions there - that makes it even worse.

But in the long term, we want to move away from using #define's
altogether and have the object managers dynamically map the class and
permission string names during startup to values via libselinux
functions (which in turn can use a selinuxfs node or an auxiliary policy
file to get the information).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2007-03-08 at 23:50 +0900, KaiGai Kohei wrote:
>> Stephen Smalley wrote:
>>> On Thu, 2007-03-08 at 22:33 +0900, KaiGai Kohei wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
>>>>>> The attached patch adds new object classes, access vectors and
>>>>>> booleans related to database.
>>>>>> SE-PostgreSQL uses them to manage the various kinds of database
>>>>>> objects such as tables, columns, tuples and so on.
>>>>>>
>>>>>> The most of security policies are provided as a binary security
>>>>>> policy within RPM package. But it requires the definition of new
>>>>>> object classes, access vectors and booleans in the base policy.
>>>>>>
>>>>>> Please apply it.
>>>>> Is the code on a path to being merged upstream?  I'm hesitant to apply
>>>>> class changes until the code is on a plan to be merged.
>>>> Pushing to the upstreamed PostgreSQL is one of the next activities.
>>>> No need to say, I'm targeting it to be merged as a part of PostgreSQL.
>>>>
>>>> I'll submit a patch to add new object classes again after discussion
>>>> in the pgsql-hackers list. But I'm desiring the object class numbers
>>>> are fixed earlier. (currently, I uses 60 - 65 to represent them)
>>> Where do things stand wrt dynamic userspace object class and permission
>>> discovery?  It would be nice to avoid further spread of hardcoded
>>> classes and permissions in applications if we can avoid it.
>> See, http://sepgsql.googlecode.com/svn/trunk/src/include/security/sepgsql_internal.h
>> When I started to develop, 'context' class has the maximum number of object
>> class, so I defined 'SECCLASS_DATABASE' next to it.
>> # But it will conflict with 'dccp_socket' class now... :-(
> 
> Yes, you'll have to re-base.  Of course, you should be using the
> libselinux headers instead of your own private definitions, i.e.
> 	cd refpolicy/policy/flask
> 	(update security_classes and access_vectors to add your defs)
> 	make
> 	make LIBSEL=/path/to/libselinux tolib
> 	cd /path/to/libselinux
> 	make install relabel
> 
> Then just #include <selinux/flask.h> and #include
> <selinux/av_permissions.h> in your SE-PostgreSQL code.  Don't duplicate
> the definitions there - that makes it even worse.
> 
> But in the long term, we want to move away from using #define's
> altogether and have the object managers dynamically map the class and
> permission string names during startup to values via libselinux
> functions (which in turn can use a selinuxfs node or an auxiliary policy
> file to get the information).
> 

We'll be resuming work on dynamic object class discovery soon, 
unfortunately the SELinux Symposium interferes with real work. IIRC the 
current decision was to use an selinuxfs node to get values to avoid 
desynchronization of class numbers in the kernel and on disk.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Joshua Brindle]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> On Thu, 2007-03-08 at 23:50 +0900, KaiGai Kohei wrote:
>>> Stephen Smalley wrote:
>>>> On Thu, 2007-03-08 at 22:33 +0900, KaiGai Kohei wrote:
>>>>> Christopher J. PeBenito wrote:
>>>>>> On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
>>>>>>> The attached patch adds new object classes, access vectors and
>>>>>>> booleans related to database.
>>>>>>> SE-PostgreSQL uses them to manage the various kinds of database
>>>>>>> objects such as tables, columns, tuples and so on.
>>>>>>>
>>>>>>> The most of security policies are provided as a binary security
>>>>>>> policy within RPM package. But it requires the definition of new
>>>>>>> object classes, access vectors and booleans in the base policy.
>>>>>>>
>>>>>>> Please apply it.
>>>>>> Is the code on a path to being merged upstream?  I'm hesitant to 
>>>>>> apply
>>>>>> class changes until the code is on a plan to be merged.
>>>>> Pushing to the upstreamed PostgreSQL is one of the next activities.
>>>>> No need to say, I'm targeting it to be merged as a part of PostgreSQL.
>>>>>
>>>>> I'll submit a patch to add new object classes again after discussion
>>>>> in the pgsql-hackers list. But I'm desiring the object class numbers
>>>>> are fixed earlier. (currently, I uses 60 - 65 to represent them)
>>>> Where do things stand wrt dynamic userspace object class and permission
>>>> discovery?  It would be nice to avoid further spread of hardcoded
>>>> classes and permissions in applications if we can avoid it.
>>> See, 
>>> http://sepgsql.googlecode.com/svn/trunk/src/include/security/sepgsql_internal.h 
>>>
>>> When I started to develop, 'context' class has the maximum number of 
>>> object
>>> class, so I defined 'SECCLASS_DATABASE' next to it.
>>> # But it will conflict with 'dccp_socket' class now... :-(
>>
>> Yes, you'll have to re-base.  Of course, you should be using the
>> libselinux headers instead of your own private definitions, i.e.
>>     cd refpolicy/policy/flask
>>     (update security_classes and access_vectors to add your defs)
>>     make
>>     make LIBSEL=/path/to/libselinux tolib
>>     cd /path/to/libselinux
>>     make install relabel
>>
>> Then just #include <selinux/flask.h> and #include
>> <selinux/av_permissions.h> in your SE-PostgreSQL code.  Don't duplicate
>> the definitions there - that makes it even worse.
>>
>> But in the long term, we want to move away from using #define's
>> altogether and have the object managers dynamically map the class and
>> permission string names during startup to values via libselinux
>> functions (which in turn can use a selinuxfs node or an auxiliary policy
>> file to get the information).
>>
> 
> We'll be resuming work on dynamic object class discovery soon, 
> unfortunately the SELinux Symposium interferes with real work. IIRC the 
> current decision was to use an selinuxfs node to get values to avoid 
> desynchronization of class numbers in the kernel and on disk.
> 

It might be nice to get an API nailed down and put it in immediately so 
that sepostgres can start using it and put in functions that use the 
static numbers.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Thu, 2007-03-08 at 10:23 -0500, Joshua Brindle wrote:
> Joshua Brindle wrote:
> > Stephen Smalley wrote:
> >> On Thu, 2007-03-08 at 23:50 +0900, KaiGai Kohei wrote:
> >>> Stephen Smalley wrote:
> >>>> On Thu, 2007-03-08 at 22:33 +0900, KaiGai Kohei wrote:
> >>>>> Christopher J. PeBenito wrote:
> >>>>>> On Mon, 2007-03-05 at 23:41 +0900, KaiGai Kohei wrote:
> >>>>>>> The attached patch adds new object classes, access vectors and
> >>>>>>> booleans related to database.
> >>>>>>> SE-PostgreSQL uses them to manage the various kinds of database
> >>>>>>> objects such as tables, columns, tuples and so on.
> >>>>>>>
> >>>>>>> The most of security policies are provided as a binary security
> >>>>>>> policy within RPM package. But it requires the definition of new
> >>>>>>> object classes, access vectors and booleans in the base policy.
> >>>>>>>
> >>>>>>> Please apply it.
> >>>>>> Is the code on a path to being merged upstream?  I'm hesitant to 
> >>>>>> apply
> >>>>>> class changes until the code is on a plan to be merged.
> >>>>> Pushing to the upstreamed PostgreSQL is one of the next activities.
> >>>>> No need to say, I'm targeting it to be merged as a part of PostgreSQL.
> >>>>>
> >>>>> I'll submit a patch to add new object classes again after discussion
> >>>>> in the pgsql-hackers list. But I'm desiring the object class numbers
> >>>>> are fixed earlier. (currently, I uses 60 - 65 to represent them)
> >>>> Where do things stand wrt dynamic userspace object class and permission
> >>>> discovery?  It would be nice to avoid further spread of hardcoded
> >>>> classes and permissions in applications if we can avoid it.
> >>> See, 
> >>> http://sepgsql.googlecode.com/svn/trunk/src/include/security/sepgsql_internal.h 
> >>>
> >>> When I started to develop, 'context' class has the maximum number of 
> >>> object
> >>> class, so I defined 'SECCLASS_DATABASE' next to it.
> >>> # But it will conflict with 'dccp_socket' class now... :-(
> >>
> >> Yes, you'll have to re-base.  Of course, you should be using the
> >> libselinux headers instead of your own private definitions, i.e.
> >>     cd refpolicy/policy/flask
> >>     (update security_classes and access_vectors to add your defs)
> >>     make
> >>     make LIBSEL=/path/to/libselinux tolib
> >>     cd /path/to/libselinux
> >>     make install relabel
> >>
> >> Then just #include <selinux/flask.h> and #include
> >> <selinux/av_permissions.h> in your SE-PostgreSQL code.  Don't duplicate
> >> the definitions there - that makes it even worse.
> >>
> >> But in the long term, we want to move away from using #define's
> >> altogether and have the object managers dynamically map the class and
> >> permission string names during startup to values via libselinux
> >> functions (which in turn can use a selinuxfs node or an auxiliary policy
> >> file to get the information).
> >>
> > 
> > We'll be resuming work on dynamic object class discovery soon, 
> > unfortunately the SELinux Symposium interferes with real work. IIRC the 
> > current decision was to use an selinuxfs node to get values to avoid 
> > desynchronization of class numbers in the kernel and on disk.
> > 
> 
> It might be nice to get an API nailed down and put it in immediately so 
> that sepostgres can start using it and put in functions that use the 
> static numbers.

There are already string_to_security_class() and string_to_av_perm()
functions provided by libselinux, although they should likely have
properly namespaced versions (selinux_ prefix).

We'd also likely want a callback of some sort for revalidating any
cached mappings upon a policy reload.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Eamon Walsh]

Stephen Smalley wrote:

> There are already string_to_security_class() and string_to_av_perm()
> functions provided by libselinux, although they should likely have
> properly namespaced versions (selinux_ prefix).

If we're talking about the API in this area: I had a request for 
security_class_to_string and av_perm_to_string functions, I believe from 
KaiGai.  The patch in the below e-mail adds them; this could be applied 
as an independent patch.

http://marc.theaimsgroup.com/?l=selinux&m=116486019626891&w=2

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Solaris 10 w/ Trusted Extensions vs SE Linux Comparison

[Fletcher, Boyd C. CIV US USJFCOM JFL J9935]

just got this in an email this morning...

http://www.sun.com/bigadmin/features/hub_articles/mls_trusted_exts_table.jsp




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Solaris 10 w/ Trusted Extensions vs SE Linux Comparison

[Fletcher, Boyd C. CIV US USJFCOM JFL J9935]

inaccuracies should be posted to http://blogs.sun.com/gfaden/


-----Original Message-----
From: owner-selinux@tycho.nsa.gov on behalf of Fletcher, Boyd C. CIV US USJFCOM JFL J9935
Sent: Thu 3/8/07 12:30 PM
To: selinux@tycho.nsa.gov
Subject: Solaris 10 w/ Trusted Extensions vs SE Linux Comparison
 

just got this in an email this morning...

http://www.sun.com/bigadmin/features/hub_articles/mls_trusted_exts_table.jsp




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Thu, 2007-03-08 at 11:24 -0500, Eamon Walsh wrote:
> Stephen Smalley wrote:
> 
> > There are already string_to_security_class() and string_to_av_perm()
> > functions provided by libselinux, although they should likely have
> > properly namespaced versions (selinux_ prefix).
> 
> If we're talking about the API in this area: I had a request for 
> security_class_to_string and av_perm_to_string functions, I believe from 
> KaiGai.  The patch in the below e-mail adds them; this could be applied 
> as an independent patch.
> 
> http://marc.theaimsgroup.com/?l=selinux&m=116486019626891&w=2

Ok, so we could:
- introduce new versions of the existing string_to_* functions with a
security_ or selinux_ prefix for namespace cleanliness,
- merge that patch, using the same convention for naming (either as is
with security_ or replacing with selinux_,
- have KaiGai rewrite his code to use these functions to map class and
permission strings to policy values during startup of SEPostgreSQL,
generating lookup tables for later use by the actual permission checks
(where the lookup tables would map internal indices private to
SEPostgreSQL to the policy-defined values obtained from libselinux).
The tables would need to be revalidated and potentially refreshed upon a
policy reload, which could be done from an AVC callback.

Then SEPostgreSQL no longer needs to be compile-time bound to specific
policy values for its classes and permissions.

Same could be done for XSELinux, right?

Then when we have the dynamic discovery mechanism implemented, it can
just be used by those libselinux functions internally, with no further
change to the object managers.
  
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[KaiGai Kohei]

Stephen Smalley wrote:
> On Thu, 2007-03-08 at 11:24 -0500, Eamon Walsh wrote:
>> Stephen Smalley wrote:
>>
>>> There are already string_to_security_class() and string_to_av_perm()
>>> functions provided by libselinux, although they should likely have
>>> properly namespaced versions (selinux_ prefix).
>> If we're talking about the API in this area: I had a request for 
>> security_class_to_string and av_perm_to_string functions, I believe from 
>> KaiGai.  The patch in the below e-mail adds them; this could be applied 
>> as an independent patch.
>>
>> http://marc.theaimsgroup.com/?l=selinux&m=116486019626891&w=2
> 
> Ok, so we could:
> - introduce new versions of the existing string_to_* functions with a
> security_ or selinux_ prefix for namespace cleanliness,
> - merge that patch, using the same convention for naming (either as is
> with security_ or replacing with selinux_,
> - have KaiGai rewrite his code to use these functions to map class and
> permission strings to policy values during startup of SEPostgreSQL,
> generating lookup tables for later use by the actual permission checks
> (where the lookup tables would map internal indices private to
> SEPostgreSQL to the policy-defined values obtained from libselinux).
> The tables would need to be revalidated and potentially refreshed upon a
> policy reload, which could be done from an AVC callback.
> 
> Then SEPostgreSQL no longer needs to be compile-time bound to specific
> policy values for its classes and permissions.

I also think it's an excellent idea!
I'll rewrite a part of implementation to generate classes/access vectors
lookup table and to use them.


> Same could be done for XSELinux, right?
> 
> Then when we have the dynamic discovery mechanism implemented, it can
> just be used by those libselinux functions internally, with no further
> change to the object managers.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Sat, 2007-03-10 at 00:25 +0900, KaiGai Kohei wrote:
> Stephen Smalley wrote:
> > On Thu, 2007-03-08 at 11:24 -0500, Eamon Walsh wrote:
> >> Stephen Smalley wrote:
> >>
> >>> There are already string_to_security_class() and string_to_av_perm()
> >>> functions provided by libselinux, although they should likely have
> >>> properly namespaced versions (selinux_ prefix).
> >> If we're talking about the API in this area: I had a request for 
> >> security_class_to_string and av_perm_to_string functions, I believe from 
> >> KaiGai.  The patch in the below e-mail adds them; this could be applied 
> >> as an independent patch.
> >>
> >> http://marc.theaimsgroup.com/?l=selinux&m=116486019626891&w=2
> > 
> > Ok, so we could:
> > - introduce new versions of the existing string_to_* functions with a
> > security_ or selinux_ prefix for namespace cleanliness,
> > - merge that patch, using the same convention for naming (either as is
> > with security_ or replacing with selinux_,
> > - have KaiGai rewrite his code to use these functions to map class and
> > permission strings to policy values during startup of SEPostgreSQL,
> > generating lookup tables for later use by the actual permission checks
> > (where the lookup tables would map internal indices private to
> > SEPostgreSQL to the policy-defined values obtained from libselinux).
> > The tables would need to be revalidated and potentially refreshed upon a
> > policy reload, which could be done from an AVC callback.
> > 
> > Then SEPostgreSQL no longer needs to be compile-time bound to specific
> > policy values for its classes and permissions.
> 
> I also think it's an excellent idea!
> I'll rewrite a part of implementation to generate classes/access vectors
> lookup table and to use them.

Ok, you'll need to figure out the optimal approach there, as you need
low runtime overhead for the actual permission checks.  They would be
changing from having the form:
	rc = avc_has_perm(ssid, tsid, SECCLASS_DATABASE,
DATABASE__ACCESS, ...);
to having a form like:
	rc = pgres_has_perm(ssid, tsid, PGRES_DATABASE_ACCESS, ...);
where pgres_has_perm() could do something like:
	rc = index2policy(PGRES_DATABASE_ACCESS, &tclass, &perms);
	if (rc) return rc;
	rc = avc_has_perm(ssid, tsid, tclass, perms, ...);

So you'd have a postgres-private index value for each distinct
permission check it performs, mapped to a (class, perms) pair by the
index2policy() function, using a lookup table generated once during
startup from the string names using the libselinux functions (and
revalidated upon policy reload notification).

> > Same could be done for XSELinux, right?
> > 
> > Then when we have the dynamic discovery mechanism implemented, it can
> > just be used by those libselinux functions internally, with no further
> > change to the object managers.
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Eamon Walsh]

Stephen Smalley wrote:
> Ok, you'll need to figure out the optimal approach there, as you need
> low runtime overhead for the actual permission checks.  They would be
> changing from having the form:
> 	rc = avc_has_perm(ssid, tsid, SECCLASS_DATABASE,
> DATABASE__ACCESS, ...);
> to having a form like:
> 	rc = pgres_has_perm(ssid, tsid, PGRES_DATABASE_ACCESS, ...);
> where pgres_has_perm() could do something like:
> 	rc = index2policy(PGRES_DATABASE_ACCESS, &tclass, &perms);
> 	if (rc) return rc;
> 	rc = avc_has_perm(ssid, tsid, tclass, perms, ...);
> 
> So you'd have a postgres-private index value for each distinct
> permission check it performs, mapped to a (class, perms) pair by the
> index2policy() function, using a lookup table generated once during
> startup from the string names using the libselinux functions (and
> revalidated upon policy reload notification).

If having an index2policy table is going to be a common usage model for 
userspace object managers then perhaps support for it should be included 
in libselinux.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [ANN] SE-PostgreSQL 8.2.3-1.0 alpha release

[Stephen Smalley]

On Mon, 2007-03-12 at 13:10 -0400, Eamon Walsh wrote:
> Stephen Smalley wrote:
> > Ok, you'll need to figure out the optimal approach there, as you need
> > low runtime overhead for the actual permission checks.  They would be
> > changing from having the form:
> > 	rc = avc_has_perm(ssid, tsid, SECCLASS_DATABASE,
> > DATABASE__ACCESS, ...);
> > to having a form like:
> > 	rc = pgres_has_perm(ssid, tsid, PGRES_DATABASE_ACCESS, ...);
> > where pgres_has_perm() could do something like:
> > 	rc = index2policy(PGRES_DATABASE_ACCESS, &tclass, &perms);
> > 	if (rc) return rc;
> > 	rc = avc_has_perm(ssid, tsid, tclass, perms, ...);
> > 
> > So you'd have a postgres-private index value for each distinct
> > permission check it performs, mapped to a (class, perms) pair by the
> > index2policy() function, using a lookup table generated once during
> > startup from the string names using the libselinux functions (and
> > revalidated upon policy reload notification).
> 
> If having an index2policy table is going to be a common usage model for 
> userspace object managers then perhaps support for it should be included 
> in libselinux.

Hmmm..well, the userspace object manager knows the number of discrete
permission checks it performs, and it knows the (class, permission)
string pairs involved, so it should be able to allocate and generate an
optimal table for mapping its own permission checks to (class,
permission) value pairs using only libselinux functions for mapping
class and permission strings to policy values to populate the table at
startup.  Not sure what the tradeoffs would be in abstracting that table
generation behind a libselinux interface.

Of course, one would also have to deal with the situation where a given
permission check passes a computed permission set value instead of a
fixed permission set, like selinux_inode_permission or selinux_capable
in the kernel.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Solaris 10 w/ Trusted Extensions vs SE Linux Comparison

[Karl MacMillan]

On Thu, 2007-03-08 at 12:30 -0500, Fletcher, Boyd C. CIV US USJFCOM JFL
J9935 wrote:
> just got this in an email this morning...
> 
> http://www.sun.com/bigadmin/features/hub_articles/mls_trusted_exts_table.jsp
> 
> 

I responded at http://mentalrootkit.org/?p=16 and James Morris added
some additional thoughts at http://james-morris.livejournal.com/.

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.