From: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PostgreSQL Specifications |
Date: | 2009-07-26 21:30:25 |
Message-ID: | 4A6CCAF1.7010202@kaigai.gr.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
>
> KaiGai Kohei wrote:
>> Andrew Dunstan wrote:
>>>
>>>
>>> KaiGai Kohei wrote:
>>>>
>>>> The SELinux provides a certain process privilege to make backups and
>>>> restore them. In the (currect) default policy, it is called
>>>> "unconfined".
>>>>
>>>> However, it is also *possible* to define a new special process
>>>> privilege
>>>> for backup and restore tools. For example, it can access all the
>>>> databse
>>>> objects and can make backups, but any other process cannot touch the
>>>> backup files. It means that DBA can launch a backup tool and it creates
>>>> a black-boxed file, then he cal also lauch a restore tool to restore
>>>> the black-boxed backup, but he cannot see the contents of the backup.
>>>> (It might be a similar idea of "sudo" mechanism.)
>>>>
>>>>
>>>
>>> Really? How you enforce this black box rule for a backup made across
>>> the network? From the server's POV there is no such thing as a
>>> backup. All it sees is a set of SQL statements all of which it might
>>> see in some other context.
>>
>> The recent SELinux provide a feature to exchange the security context of
>> peer process over the network connection.
>> It allows to control a certain process to send/receive packets to/from
>> only a certain process, even if they communicate using remote connection.
>>
>> This feature is named "Labeled IPsec". The key exchange daemon (racoon)
>> was enhanced to exchange the security context of peer processes also,
>> prior to the actual communications.
>>
>>
>
> Interesting, I can see this having some use in quite a number of areas.
> Of course, in the end, it still comes down to this issue, which is as
> old as Plato: "Quis custodiet ipsos custodes?" (see
> <http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F> )
The administrator needs to set up and manage both of the hosts to
keep consistent security policy, but it is not a technical issue.
We have security issues broader than what technical feature can solve,
and the technical security feature is a piece of them.
(Needless to say, it is an important piece.)
For example, any kind of access controls are ineffective to phisical
attacks, so we need to place the server in data centers with physical
controls on entering or leaving a room.
Referring any ISO/IEC15408 certifications, they defines a certain
environment in which the certified products to be used.
It means the certification is valid on the required environments.
The technical security feature is an important piece, but not all.
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-07-26 21:57:26 | Re: When is a record NULL? |
Previous Message | Heikki Linnakangas | 2009-07-26 20:39:20 | Re: CommitFest Status Summary - 2009-07-25 |