Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
>> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam@samason.me.uk> wrote:
>>> I thought the whole point of MAC was that superusers don't exist any
>>> more--at least not with the power they currently do.
>> It's been billed that way, but it's not really accurate.  A more
>> accurate statement would be that it's possible to create a system in
>> which there is no unconfined role.
> 
> Yes, that sounds more precise!

Yes, Rober's explanation is correct.

> I'm still unsure of terminology; what's a "unconfined role"?  I guess
> the layman's description is similar to a "superuser", but I'm sure
> there's a more refined definition somewhere.  Hum, I've just found
> Fedora's guide, is the following considered a reasonable picture:
> 
>   http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html

Please note that SELinux/SE-PgSQL checks all the requests from users
without any exceptions, even if he is a superusers.
It makes its access control decisions based on the security policy.

The default security policy (which is provided by SELinux's community)
allows anything on the unconfined ones. Thus, it is allowed anything
at the result.
(Needless to say, DAC permission checks are applied independent from
whether it is confined or unconfined in SELinux.)

It is important the decision is always according to the security policy.

>> And while I believe
>> SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
>> might want to think carefully before you decide to do so, and the
>> system certainly shouldn't (and can't) force you to set it up that
>> way.
> 
> I agree that this would seem to make the resulting system easier to
> manage, however I can also imagine scenarios where the converse would
> be true.  This is a fuzzy engineering decision of the sort that I don't
> like making without a use case---and it would be nice to have several
> here.

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.)

It is a separated issue whether the *default* security policy should
supports such an extreme protection, or not.

However, SELinux community shall provide its security policy to make
backup and restore them correctly, and suggest what privilege should
be assigned on the user sheel which launches backup and restore tools.
If it does not work correctly, it is a simply bug.

TODO: I've not provide a draft documentation for backup options to      pg_dump command, but it will be necessary to be
reviewed.     It should contains what security context should be assigned on      the user shell which launches the
pg_dumpalso.
 

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