Re: Adding support for SE-Linux security

All,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> If we design a security abstraction layer, the interfaces need to
> really be abstraction boundaries. Passing the table OID and then also
> the tablespace OID because PG DAC needs that to make its access
> control decision is crap.

Now, to address the small useful bit of this mail- I tend to agree with
this. I'm not convinced there's an alternative, but I'd like to throw
out a couple of my ideas on how it could be addressed. I'd like to
solicit for feedback on these.

First off, we have alot of the information available from the catalog.
Basically, given an OID, we should be able to find out the other
information associated with that OID (such as what kind of object it is,
what tablespace it resides in, etc). OID isn't sufficient, however, as
we know from the dependency system. To address this, we would need OID
and SubOID. Now, any information which we can derive from those should
not be included in the API. To be honest, I don't think we've actually
been all that bad about this, but I'll reserve any definitive answer
until I've gone back through the API we have specifically thinking about
this issue. On further thought, I'm probably wrong and should have
caught this during my review. Sorry.

Second, the information we *don't* have from above is generally
information about what the requesting action is. For example, when
changing ownership of an object, we can't possibly use introspection to
find out the role which is on the receiving end, since at that time
we've just learned it from the parser. Now, we might build an entire
new object, pass the "result of this action" OID to the security system
and ask it "can we change OID X into OID Y?", but I don't particularly
like it. We really don't want to do any *changes* to things until after
we've determined the permissions allow for it, and I'm not sure how to
get around that without building an independent introspection system for
"what might be". Perhaps we're comfortable enough saying "we'll just
rollback the command if it turns out to have not been allowed" but I
just don't like it. Feels like a higher risk solution to me.

I don't see a way to get around the second piece since what information
is needed about the action is typically action-specific. Perhaps we
could have an 'action-ID' (uh, we have an ID per command already, no?
Probably doesn't fit the mold close enough though), and then a way to
query information about "what is this action trying to do?". Doesn't
seem likely to be very clean though.

Other thoughts?

Thanks,

Stephen