Re: SE-PostgreSQL/Lite Review - Mailing list pgsql-hackers

From David P. Quigley
Subject Re: SE-PostgreSQL/Lite Review
Date
Msg-id 1260553466.15974.65.camel@moss-terrapins.epoch.ncsc.mil
Whole thread Raw
In response to Re: SE-PostgreSQL/Lite Review  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Fri, 2009-12-11 at 11:36 -0500, Stephen Frost wrote:
[Snip...]
> 
> > In addition, OS allows to choose one enhanced security at most eventually.
> > 
> > In my image, the hook should be as:
> > 
> >   Value *
> >   ac_database_create([arguments ...])
> >   {
> >       /*
> >        * The default PG checks here.
> >        * It is never disabled
> >        */
> > 
> >       /* "enhanced" security as follows */
> >   #if defined(HAVE_SELINUX)
> >       if (sepgsql_is_enabled())
> >           return sepgsql_database_create(...);
> >   #elif defined(HAVE_SMACK)
> >       if (smack_is_enabled())
> >           return smack_database_create(...);
> >   #elif defined(HAVE_SOLARISTX)
> >       if (soltx_is_enabled())
> >           return soltx_database_create(...);
> >   #endif
> >       return NULL;
> >   }
> > 
> > We can share a common image image?
> 
> If all of these security modules make sense as "only-more-restrictive",
> then I have no problem with this approach.  Honestly, I'm fine with the
> initial hooks looking as above in any case, since it provides a clear
> way to deal with switching out the 'default PG checks' if someone
> desires it- you could #if around that block as well.  As it's the
> principle/primary, and I could see "only-more-restrictive" being more
> popular, I don't mind having that code in-line in the hook.  The check
> itself is still being brought out and into the security/ framework.
> 
> I do think that, technically, there's no reason we couldn't allow for
> multiple "only-more-restrictive" models to be enabled and built in a
> single binary for systems which support it.  As such, I would make those
> just "#if defined()" rather than "#elif".  Let it be decided at runtime
> which are actually used, otherwise it becomes a much bigger problem for
> packagers too.
> 

So when Eamon did the XACE work he allowed for stackable security
modules. We do not allow for this in the Linux kernel but we can still
figure out whether we want to support it for now. I'm not convinced that
the ifdef model is the right way to go. There should be a security
structure where pointers to the appropriate functions reside (like we
have in linux) so this way you have a register_module call which takes
the mac model and puts all the necessary function pointers into the
structure and the hook is just a call to security->create_db. If you
want to make it stackable you make security->create_db a list of
function pointers that get executed in turn. I'll ask Eamon when I see
him next how he handled deregistration of a particular model.

Dave



pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: [PATCH] dtrace probes for memory manager
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] dtrace probes for memory manager