From: | "David P(dot) Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SE-PostgreSQL/Lite Review |
Date: | 2009-12-11 17:44:26 |
Message-ID: | 1260553466.15974.65.camel@moss-terrapins.epoch.ncsc.mil |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2009-12-11 17:55:17 | Re: [PATCH] dtrace probes for memory manager |
Previous Message | David P. Quigley | 2009-12-11 17:25:19 | Re: Adding support for SE-Linux security |