Re: Adding support for SE-Linux security - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Adding support for SE-Linux security
Date
Msg-id 603c8f070912110632r5a526332jf21b602513c95e6f@mail.gmail.com
Whole thread Raw
In response to Re: Adding support for SE-Linux security  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: Adding support for SE-Linux security  ("David P. Quigley" <dpquigl@tycho.nsa.gov>)
List pgsql-hackers
2009/12/11 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> It tried to provide a set of comprehensive entry points to replace existing
> PG checks at once.
> However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
> tables and columns. Is it necessary to be comprehensive from the beginning?
> It might be too aggressive changes at once.
>
> Frankly, I hesitate to salvage the patch once rejected, as is.
>
> If we implement a set of security hooks, It seems to me the following approach
> is reasonable:
>
> * It does not touch the existing PG default checks.
>  The purpose of security hooks are to host "enhanced" security features.
>
> * It does not deploy hooks on which no security provider is now proposed.
>  It is important to reduce unnecessary changeset.

I think that we should try to move the PG default checks inside the
hook functions.  If we can't do that cleanly, it's a good sign that
the hook functions are not correctly placed to enforce arbitrary
security policy.  Furthermore, it defeats what I think would be a good
side goal here, which is to better modularize the existing code.

What I would suggest is that you develop a version of that patch that
is stripped down to apply to only a single object type (databases?
tables and columns - these might have to be together??) and which
addresses Tom's criticisms from the last time around, and post that
(on a new thread) for discussion.  That will be much easier to review
(and I will personally commit to reviewing it) but should allow us to
flush out some of the design issues.  If we can get agreement on that
as a concept patch, we can move on to talking about which object types
should be included in a committable version of that patch.

...Robert


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] dtrace probes for memory manager
Next
From: Alvaro Herrera
Date:
Subject: Re: thread safety on clients