Re: Adding support for SE-Linux security

I could not find the message from David P. Quigley in the list,
although pgsql-hackers(at)postgresql(dot)org was Cc:'ed.
(something troubled?)

So, I'll send it again for your information.

-------- Original Message --------
Subject: Re: [HACKERS] Adding support for SE-Linux security
Date: Mon, 07 Dec 2009 14:53:03 -0500
From: David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov>
Organization: National Security Agency
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
CC: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, 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(at)postgresql(dot)org
References: <200912071800(dot)nB7I0KB01863(at)momjian(dot)us> <21873(dot)1260209825(at)sss(dot)pgh(dot)pa(dot)us>

On Mon, 2009-12-07 at 13:17 -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Robert Haas wrote:
> >> Yes, I think that's the right way to think about it. At a guess, it's
> >> two man-months of work to get it in, and ripping it out is likely
> >> technically fairly simple but will probably be politically impossible.
>
> > I figure if there is sufficient usage, we will not need to remove it,
> > and if there isn't, we will have no objections to removing it.
>
> That leaves a wide gray area where there are a few people using it but
> not really enough to justify the support effort. Even if there are
> demonstrably no users (which can never be demonstrated in practice),
> politically it's very hard to rip out a "major feature" --- it makes the
> project look bad. So I think the above is Pollyanna-ish nonsense.
> Once we ship a release with SEPostgres in it, we're committed.
>
> > As Alvaro mentioned, the original patch used ACE but it added too much
> > code so the community requested its removal from the patch. It could be
> > re-added if we have a need.
>
> The main problem I saw with ACE was that it didn't appear to actually
> add any flexibility --- it was just an extra layer of function calls
> in an entirely SELinux-centric design. In order to have a "pluggable
> interface" layer that is worth the electrons it's written on, you need
> to start out with more than one target system in mind to be plugged in.
> So that would mean, at minimum, investigating something like AppArmor or
> TrustedSolaris to see what its needs are before we sit down to design
> the plugin layer. (Which, of course, nobody here is actually interested
> enough to do. But without that research there is no point in demanding
> a plugin layer.)
>
> regards, tom lane
>

Not to start a flame war here about access control models but you gave 3
different examples one of which I don't think has any means to do
anything productive here. Looking at the 3 examples you gave and what
SEPostgres is trying to accomplish here is what I see.

The point of SEPostgres is to do object labeling in a database. Two of
the three examples you gave are label based security mechanisms.
AppArmor while it might be able to have a scheme to mediate access to
database/table doesn't seem to have a reasonable way to write policy to
individual records. Since AppArmor is path name based you need an
identifiable path to whatever you want to write access control rules
for. With something like a database where data dynamically comes and
goes and changes doing rules on individual records seems difficult. I
also can't find any information about AppArmor being used as a
user-space object manager. If someone wants to prove me wrong I'm
willing to listen to their argument.

Lets look at the remaining two. Do you really mean TrustedSolaris(TSOL)
or do you mean Solaris with Trusted Extensions(TX). There is a big
difference here. From my understanding Sun no longer supports TSOL and
moved on to TX. The difference here is that they moved from fine grained
object labeling to zone based labeling. There is a project currently in
development (although moving a bit slow) called FMAC which will bring
SELinux style MAC to Solaris which will reintroduce fine grained
labeling. You will still be able to use zones however process and object
labels will not be based on zone in FMAC.

I understand the concerns with a generic framework introducing a lot of
code. The Linux Kernel LSM Framework seems to grow as more models are
introduced but if you want to support various models you have to live
with the fact that there is no common interface for all of these
systems. It has been tried numerous times in the past and has failed.
>From what I've seen I think that will be less of a concern with Postgres
since the objects that Kaigai wants to mediate is a much smaller set
than the kernel. If you want to see another instance of where work
similar to this was done you should look at the X-Access Control
eXtensions (X-ACE) found in the X server. Eamon Walsh designed this
framework based not on anything SELinux specific but through an analysis
of the X Server which yielded a list of object he though needed
mediating. There are two modules for X-ACE now the FLASK module
(SELinux) and a module put forth by Casey Schaufler for his SMACK work.
>From what I've seen on the SELinux list Kaigai's design of SEPostgres
was conducted in a similar way.

I'll be willing to answer any questions you have for me in order to help
Kaigai's work along. Normally another member of our team would be
participating in this but he is unavailable at the moment. When he is
available again I'm sure he will participate in the discussion.

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>