Re: How to get SE-PostgreSQL acceptable

KaiGai Kohei wrote:
> Stephen Frost wrote:
>> * KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
>>> So, I cannot believe refactoring pg_xxx_aclcheck() is not acceptable.
>>> If vanilla PostgreSQL become to check ACLs on tables, independent
>>> from views, do you think it is acceptable?
>> Well, just to be clear, ACLs are checked on tables under views, but
>> they're checked using the privileges of the view owner rather than
>> the privileges of the current user. I've run into that empirically
>> because I've gotten 'permission denied' errors when using a view that
>> I've clearly got full rights on but was owned by someone else (who
>> didn't have rights on the table underneath).
>>
>> That being said, I'd think that if we do need different semantics from
>> that for SE-PostgreSQL, we could implement it using a GUC or similar to
>> keep the current behavior as well allow the SE-PostgreSQL behavior.
>
> I think it is not reasonable.
> If there are different philosophies, "one for one" seems to me
> straight forward approach, for security especially.
>

When we talk about mandatory access control we are generally very clear that for
it to be mandatory and for the policy to be analyzable you must identify objects
unambiguously. For SE-Postgres this is an absolute necessity.

At the same time, if view-based ACL's are there, and people want them and use
them then that doesn't affect us (the people that want to use sepostgres). They
must be orthogonal and sepostgres must have a way of unambiguously labeling objects.

>>> However, we have to make clear whether the PGACE architecture
>>> is incorrect, or not, at first.
>> It really bothers me that it seems like these kinds of reviews of the
>> larger patches don't happen until it's time to decide about the next
>> release. Perhaps these issues were all brought up seperately in prior
>> threads, or they weren't articulated as requirements or show-stoppers,
>> and if so then I apologize for not following those more closely.
>>

As a new-comer to this discussion (and indeed this list/community) I find it
baffling that a patchset that has been around this long is just now having basic
architectural questions asked about it.

>> If the approach Peter outlined is what core wants to see and is willing
>> to go along with to get SE-PostgreSQL included then let's please decide
>> that now and agree that unless some serious problem comes up we'll stick
>> to it and not require the whole thing be rewritten again later.
>
> As I noted, PGACE is not my goal.
> I don't tremble to integrate SELinux related code into the core.
>

Flask (from which SELinux is derived) has the basic architecture of separating
enforcement from policy. This generally means that a security server (or
backend) knows what the policy is and how to calculate access vectors and it
passes those answers to the enforcement points. Flask itself is a framework. In
Linux and Xorg a more general framework was built that interfaces to flask,
because the flask security server wasn't seen as something that could implement
any kind of security policy (whether that is correct or not is a point of
contention, as the selinux security server already implements a kind of RBAC,
type enforcement and multilevel security).

PCACE is, architecturally, similar to LSM in the linux kernel and XACE in in
Xorg but is not an absolute necessity for SELinux integration.

>> I'm not sure about KaiGai's feelings on this, but it strikes me that
>> adding SELinux support for the existing levels of access control in PG
>> might be straight-forward and small enough to include for 8.4 and would
>> show some commitment to this approach of "do it for PG, add SELinux
>> checks for it". Alternatively, maybe a progression-towards-SE-PostgreSQL
>> wiki/webpage that outlines the plan, current work, what's been
>> committed, etc, that everyone reviews and agrees to?
>

If you look at the patches you'll see that the bulk of them are adding the
SELinux infrastructure. An access vector cache, the label translation functions,
the libselinux interface and so on. Over 2/3's of the patch is in
src/backend/security.

I'm not sure how much it would cut to remove row level access controls, but I do
have some points here. To me, row level access controls are the most important
part, this is the feature that lets us put secret and top secret data in the
same table and use the clients selinux context to decide what they can see,
transparently and without modification to the application. Without it you have
to use seperate postgres instances, modify the application to select from
different sets of tables depending on their label and so on.

That said, SELinux didn't start out as fine grained as it is today. A fair
number of object classes were present back in '99 when it started but more have
been added over time, the policy infrastructure allows that to happen, in fact
the policy allows object class/permissions to be added, removed and modified if
the access controls were inadequate or unnecessary.

> Are you saying enlargement step-by-step, aren't you?
> At least, it is far preferable to a death punishment.
>
> I would like to here Joshua's opinion also.
>

namespace collision...

>> adding SELinux support for the existing levels of access control in PG
>
> is
>
> - table/column level access controls
> - permission checks on database login
> - permission checks on function invocation
> - they need a facility to manage security label
> - I want permission checks on loading a library,
> though existing PG checks superuser() only.
>
> and
> - removing PGACE, integrate SEPG code into core
> - permission checks on largeobjects is postponed
> - row level security is postponed (NOT REJECTED!)
> - so, writable system column is also postponed
>
> If summary is necessary, I'll post it tommorow JST.
>
> Because it is not a zero-based implementation, so I believe it can
> be minimized within acceptable timescale.
>
>> As a side-note, I've gotten some extremely positive feedback about
>> SE-PostgreSQL from folks in my organization who run systems where it
>> would be used. I'm going to be having a more detailed discussion later
>> today.
>

It's good to hear that, I hope you'll ask them how important row level access
controls are.