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 603c8f070912111214m4a0028b1ta266371c2d6f3e6d@mail.gmail.com
Whole thread Raw
In response to Re: Adding support for SE-Linux security  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Adding support for SE-Linux security  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfrost@snowman.net> wrote:
> 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.

I'm not sure that I follow what you're saying here.  I think maybe it
would help to discuss a concrete example, which is why I proposed a
concept patch.  Or perhaps you'd like just to pick out a specific case
to discuss.

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

Yeah, that seems like a non-starter.

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

Object creation seems to be one of the tougher cases here.  When
you're altering or dropping an existing object, the decision is likely
to be based (in any system) on the properties of that object.  When
you're creating an object, the decision will of course have to be
based on the properties of something else, but different access
control models might not agree on the value of "something else".  It's
not immediately clear to me how to deal with that, but again it's hard
for me to discuss it in the abstract.

...Robert


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: SE-PostgreSQL/Lite Review
Next
From: Zdenek Kotala
Date:
Subject: Re: [PATCH] dtrace probes for memory manager