Re: Adding support for SE-Linux security

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: "David P(dot) Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov>, KaiGai Kohhookei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Chad Sellers <csellers(at)tresys(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, jd <jd(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Adding support for SE-Linux security
Date: 2009-12-11 20:14:36
Message-ID: 603c8f070912111214m4a0028b1ta266371c2d6f3e6d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-11 20:20:58 Re: thread safety on clients
Previous Message Stephen Frost 2009-12-11 20:13:10 Re: SE-PostgreSQL/Lite Review