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

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

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.