[RFC] Security design of SE-PostgreSQL (2/3)

[RFC] Security design of SE-PostgreSQL (2/3)

[KaiGai Kohei]

Hi,

In recent days, I'm making progress in development of SE-PostgreSQL.
I found some issues on the work.
The followings are the issues and solutions which I planed to take.
I want any comment, idea and suggestion.


2. about Loadable module

PostgreSQL allowed to load dynamic link library.
It has a possibility to mess up the access control of SE-PostgreSQL no need
to say, so we have to restrict loading them by the security policy.

I have an idea to add the following access vector for the purpose.
  1. allow (context of client)   (context of database)   database:load_module;
  2. allow (context of database) (context of shlib file) database:associate;

The second is a mimic of 'filesystem:associate'.

You can obtain the latest SE-PostgreSQL source code from:
    http://code.google.com/p/sepgsql/source
and the sample security policy is here:
    http://www.kaigai.gr.jp/pub/selinux-policy-2.5.2-5.sepgsql.src.rpm

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: [RFC] Security design of SE-PostgreSQL (2/3)

[Russell Coker]

On Friday 16 February 2007 16:35, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> 2. about Loadable module
>
> PostgreSQL allowed to load dynamic link library.
> It has a possibility to mess up the access control of SE-PostgreSQL no need
> to say, so we have to restrict loading them by the security policy.
>
> I have an idea to add the following access vector for the purpose.
>   1. allow (context of client)   (context of database)  
> database:load_module;
> 2. allow (context of database) (context of shlib 
> file) database:associate;

Who will be loading such modules?  Only the DBA or regular users too?

In the above access control design you control which databases a user may load 
modules for and which modules may be associated with a given database.  But 
you don't control which modules a user may load.  Is it possible that modules 
A and B may be loaded into a database but only user C will be permitted to 
load module A?

Do modules have parameters?  Or is there only one way that a module can be 
used?

-- 
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: [RFC] Security design of SE-PostgreSQL (2/3)

[KaiGai Kohei]

Hi, Russell

Russell Coker wrote:
> On Friday 16 February 2007 16:35, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>> 2. about Loadable module
>>
>> PostgreSQL allowed to load dynamic link library.
>> It has a possibility to mess up the access control of SE-PostgreSQL no need
>> to say, so we have to restrict loading them by the security policy.
>>
>> I have an idea to add the following access vector for the purpose.
>>   1. allow (context of client)   (context of database)  
>> database:load_module;
>> 2. allow (context of database) (context of shlib 
>> file) database:associate;
> 
> Who will be loading such modules?  Only the DBA or regular users too?

A regular user also can load shared library modules, but it is limited
to be placed under '$libdir/plugins/' directory.
The DBA can do any files, if PostgreSQL can access.

> In the above access control design you control which databases a user may load 
> modules for and which modules may be associated with a given database.  But 
> you don't control which modules a user may load.  Is it possible that modules 
> A and B may be loaded into a database but only user C will be permitted to 
> load module A?

Your indication is correct. The above design can describe the relationship
between the client and the database, or between the database and the shared
library file.
It doesn't describe who can load which modules.

We have to describe the relationship between the client, the database
and shared library files to block a malicious modules.

How do you think the following design to allow to load a module, for example?
   allow db_client_t sepgsql_db_t : database { load_module };
   allow sepgsql_db_t dhlib_file_t : database { associate };
   allow db_client_t shlib_file_t : database { load_module };
                     ^^^^^^^^^^^^
> Do modules have parameters?  Or is there only one way that a module can be 
> used?

It didn't have any parameters.
It is simply linked, and called as an implementation of the stored procedure.

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: [RFC] Security design of SE-PostgreSQL (2/3)

[Russell Coker]

On Monday 19 February 2007 03:15, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> >> I have an idea to add the following access vector for the purpose.
> >>   1. allow (context of client)   (context of database)
> >> database:load_module;
> >> 2. allow (context of database) (context of shlib
> >> file) database:associate;
> >
> > Who will be loading such modules?  Only the DBA or regular users too?
>
> A regular user also can load shared library modules, but it is limited
> to be placed under '$libdir/plugins/' directory.
> The DBA can do any files, if PostgreSQL can access.

What Unix access controls are applied?  I guess that as PostgreSQL users don't 
have a direct relationship with Unix users it can't check the UID so it's 
just a matter of what files the database server has read and execute to which 
are in that directory.

Does it just check to make sure that the file isn't a sym-link and isn't 
world-writable.

> > In the above access control design you control which databases a user may
> > load modules for and which modules may be associated with a given
> > database.  But you don't control which modules a user may load.  Is it
> > possible that modules A and B may be loaded into a database but only user
> > C will be permitted to load module A?
>
> Your indication is correct. The above design can describe the relationship
> between the client and the database, or between the database and the shared
> library file.
> It doesn't describe who can load which modules.
>
> We have to describe the relationship between the client, the database
> and shared library files to block a malicious modules.
>
> How do you think the following design to allow to load a module, for
> example?
>    allow db_client_t sepgsql_db_t : database { load_module }; 
>    allow sepgsql_db_t shlib_file_t : database { associate };
>    allow db_client_t shlib_file_t : database { load_module };

That would work.

We already have triples in the policy language for type_transition, I wonder 
whether we could do something similar for this.  Having three rules when one 
might do is not easy to understand.

Other programs might need such triples in the policy, I wonder if it would be 
possible to make this a generic language feature.  Some sort of policy class 
which instead of actions takes another type as the third parameter.

-- 
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: [RFC] Security design of SE-PostgreSQL (2/3)

[KaiGai Kohei]

Russell Coker wrote:
> On Monday 19 February 2007 03:15, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>>>> I have an idea to add the following access vector for the purpose.
>>>>   1. allow (context of client)   (context of database)
>>>> database:load_module;
>>>> 2. allow (context of database) (context of shlib
>>>> file) database:associate;
>>> Who will be loading such modules?  Only the DBA or regular users too?
>> A regular user also can load shared library modules, but it is limited
>> to be placed under '$libdir/plugins/' directory.
>> The DBA can do any files, if PostgreSQL can access.
> 
> What Unix access controls are applied?  I guess that as PostgreSQL users don't 
> have a direct relationship with Unix users it can't check the UID so it's 
> just a matter of what files the database server has read and execute to which 
> are in that directory.
> 
> Does it just check to make sure that the file isn't a sym-link and isn't 
> world-writable.

UNIX access controls are applied between the PostgreSQL server process UID
and shared library files, independent from client process's UID.
A sym-link checking is done, but its purpose is to avoid to load a same
shared library file twice or more.

PostgreSQL documentation says as follows:
|Non-superusers may only apply LOAD to library files located in $libdir/plugins/
| — the specified filename must begin with exactly that string. (It is the database
|   administrator's responsibility to ensure that only "safe" libraries are
|   installed there.)
http://www.postgresql.org/docs/8.2/static/sql-load.html

>>> In the above access control design you control which databases a user may
>>> load modules for and which modules may be associated with a given
>>> database.  But you don't control which modules a user may load.  Is it
>>> possible that modules A and B may be loaded into a database but only user
>>> C will be permitted to load module A?
>> Your indication is correct. The above design can describe the relationship
>> between the client and the database, or between the database and the shared
>> library file.
>> It doesn't describe who can load which modules.
>>
>> We have to describe the relationship between the client, the database
>> and shared library files to block a malicious modules.
>>
>> How do you think the following design to allow to load a module, for
>> example?
>>    allow db_client_t sepgsql_db_t : database { load_module }; 
>>    allow sepgsql_db_t shlib_file_t : database { associate };
>>    allow db_client_t shlib_file_t : database { load_module };
> 
> That would work.
> 
> We already have triples in the policy language for type_transition, I wonder 
> whether we could do something similar for this.  Having three rules when one 
> might do is not easy to understand.
> 
> Other programs might need such triples in the policy, I wonder if it would be 
> possible to make this a generic language feature.  Some sort of policy class 
> which instead of actions takes another type as the third parameter.

I think it should be resolved by macros in the reference policy period.

e.g)
   sepgsql_enable_load_shlib(db_client_t, sepgsql_t, shlib_t)
     =>  allow db_client_t sepgsql_db_t : database { load_module };
         allow sepgsql_db_t shlib_file_t : database { associate };
         allow db_client_t shlib_file_t : database { load_module };

Thanks,
-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.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: [RFC] Security design of SE-PostgreSQL (2/3)

[Russell Coker]

On Tuesday 20 February 2007 13:08, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
> > What Unix access controls are applied?  I guess that as PostgreSQL users
> > don't have a direct relationship with Unix users it can't check the UID
> > so it's just a matter of what files the database server has read and
> > execute to which are in that directory.
> >
> > Does it just check to make sure that the file isn't a sym-link and isn't
> > world-writable.
>
> UNIX access controls are applied between the PostgreSQL server process UID
> and shared library files, independent from client process's UID.

Do you mean that it just opens the file and relies on Unix permissions to 
determine whether the open succeeds?

> A sym-link checking is done, but its purpose is to avoid to load a same
> shared library file twice or more.

That's not going to work very well.  Checking st_ino and st_dev is the only 
reliable way of doing it.  But I guess if they are only dealing with mistakes 
and not malicious actions then it's OK (of course it's easier to check two 
integers than multiple sym-links).

> > Other programs might need such triples in the policy, I wonder if it
> > would be possible to make this a generic language feature.  Some sort of
> > policy class which instead of actions takes another type as the third
> > parameter.
>
> I think it should be resolved by macros in the reference policy period.
>
> e.g)
>    sepgsql_enable_load_shlib(db_client_t, sepgsql_t, shlib_t)
>      =>  allow db_client_t sepgsql_db_t : database { load_module };
>          allow sepgsql_db_t shlib_file_t : database { associate };
>          allow db_client_t shlib_file_t : database { load_module };

Yes, that will work.  However there might be benefits in other situations as 
well for extending the policy language...

-- 
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: [RFC] Security design of SE-PostgreSQL (2/3)

[KaiGai Kohei]

Russell Coker wrote:
> On Tuesday 20 February 2007 13:08, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
>>> What Unix access controls are applied?  I guess that as PostgreSQL users
>>> don't have a direct relationship with Unix users it can't check the UID
>>> so it's just a matter of what files the database server has read and
>>> execute to which are in that directory.
>>>
>>> Does it just check to make sure that the file isn't a sym-link and isn't
>>> world-writable.
>> UNIX access controls are applied between the PostgreSQL server process UID
>> and shared library files, independent from client process's UID.
> 
> Do you mean that it just opens the file and relies on Unix permissions to 
> determine whether the open succeeds?

Yes,
The only limitation is that shared library files loaded by non-privileged
database user must be deployed under "$libdir/plugins/".

>> A sym-link checking is done, but its purpose is to avoid to load a same
>> shared library file twice or more.
> 
> That's not going to work very well.  Checking st_ino and st_dev is the only 
> reliable way of doing it.  But I guess if they are only dealing with mistakes 
> and not malicious actions then it's OK (of course it's easier to check two 
> integers than multiple sym-links).

Ahh, I'm sorry for misunderstanding.
I wanted to say that PostgreSQL allows to deploy a symlink-file under the plugins
directory. It uses st_ino and st_dev from star() to check duplication.

>>> Other programs might need such triples in the policy, I wonder if it
>>> would be possible to make this a generic language feature.  Some sort of
>>> policy class which instead of actions takes another type as the third
>>> parameter.
>> I think it should be resolved by macros in the reference policy period.
>>
>> e.g)
>>    sepgsql_enable_load_shlib(db_client_t, sepgsql_t, shlib_t)
>>      =>  allow db_client_t sepgsql_db_t : database { load_module };
>>          allow sepgsql_db_t shlib_file_t : database { associate };
>>          allow db_client_t shlib_file_t : database { load_module };
> 
> Yes, that will work.  However there might be benefits in other situations as 
> well for extending the policy language...

It might give us benefits, but I like to focus SE-PostgreSQL works now...

So, I like to make it progress with the following design:
     client  <--> database   requires 'database:install_module'
     client  <--> shlib file requires 'database:install_module'
    database <--> shlib file requires 'database:load_module'

The name of access vector was changed. Maybe, the aboves are more suitable.

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.