Re: Adding support for SE-Linux security

On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
> 2009/12/11 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> > It tried to provide a set of comprehensive entry points to replace existing
> > PG checks at once.
> > However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
> > tables and columns. Is it necessary to be comprehensive from the beginning?
> > It might be too aggressive changes at once.
> >
> > Frankly, I hesitate to salvage the patch once rejected, as is.
> >
> > If we implement a set of security hooks, It seems to me the following approach
> > is reasonable:
> >
> > * It does not touch the existing PG default checks.
> > The purpose of security hooks are to host "enhanced" security features.
> >
> > * It does not deploy hooks on which no security provider is now proposed.
> > It is important to reduce unnecessary changeset.
>
> I think that we should try to move the PG default checks inside the
> hook functions. If we can't do that cleanly, it's a good sign that
> the hook functions are not correctly placed to enforce arbitrary
> security policy. Furthermore, it defeats what I think would be a good
> side goal here, which is to better modularize the existing code.

So from the meeting on Wednesday I got the impression that Steve already
did this. However it was rejected because too much information was need
to be passed around. I gathered and I could be wrong but the reason for
this is that instead of developing proper abstractions for the security
code people made use of whatever local stuff was available to them at
that location. With the X-ACE work that Eamon Walsh did he did exactly
what you're saying. He figured out the object model for the X-Server and
created the hook framework. In the merge of the hook framework he also
moved the existing X server security model into the framework.

>
> What I would suggest is that you develop a version of that patch that
> is stripped down to apply to only a single object type (databases?
> tables and columns - these might have to be together??) and which
> addresses Tom's criticisms from the last time around, and post that
> (on a new thread) for discussion. That will be much easier to review
> (and I will personally commit to reviewing it) but should allow us to
> flush out some of the design issues. If we can get agreement on that
> as a concept patch, we can move on to talking about which object types
> should be included in a committable version of that patch.

They may have been said before but what exactly are the design issues?
The main concern I hear is that people are worried that this is an
SELinux specific design. I heard at the meeting on Wednesday that the
Trusted Extensions people looked at the framework and said it meets
their needs as well. If thats the case where does the concept that the
design is SELinux specific stem from? We've asked Casey Schaufler the
developer of another label based MAC system for Linux to look at the
hooks as well and make a statement about their usability.

Dave