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

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

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.