Re: Adding support for SE-Linux security

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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 21:26:24
Message-ID: 20091211212624.GE17756@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> 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.

Hrm, I thought I had given a specific example. Didn't do a good job of
it, apparently. Let me try to be a bit more clear:

ALTER TABLE x OWNER TO y;

If given the table OID, there's a ton of information we can then pull
about the table- the tablespace, the owner, the schema, the columns, the
privileges, etc, etc.

What we can't possibly figure out from the OID is the value of y. Yet,
in the PG security model, the value of y matters! You have to know what
y is to check if y has 'create' rights on the schema. If it doesn't
(and the user executing the command isn't the superuser) then the
request (under the PG model) is denied.

Does that help clarify my example case?

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

That sounds like a pretty good example to me too, to be honest. It goes
back to the same issue though- that's information you get from the
command that's trying to be run and isn't available from existing
objects. Using structures to track this information, allowing the
function arguments to remain identical, is certainly something which can
be done, and probably done with a minimal amount of fuss.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2009-12-11 21:27:28 Re: SE-PostgreSQL/Lite Review
Previous Message Tom Lane 2009-12-11 21:08:27 Re: random() in multi-threaded pgbench