> -----Original Message-----
> From: Joshua D. Drake [mailto:jd@commandprompt.com]
> Sent: Thursday, December 20, 2007 10:40 AM
> To: Roberts, Jon
> Cc: 'Trevor Talbot'; Kris Jurka; Merlin Moncure; Jonah H. Harris; Bill
> Moran; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] viewing source code
>
> Roberts, Jon wrote:
> >
> >
> > This really is a needed feature to make PostgreSQL more attractive to
> > businesses. A more robust security model that better follows commercial
> > products is needed for adoption.
> >
>
> I would argue that commercial products need to get a clue and stop
> playing bondage with their users to help stop their imminent and frankly
> obvious downfall from the Open Source competition.
>
> This "feature" as it is called can be developed externally and has zero
> reason to exist within PostgreSQL. If the feature has the level of
> demand that people think that it does, then the external project will be
> very successful and that's cool.
>

I am obviously hitting on the nerve of the open source community because it
contradicts the notion that all source code should be open. However, data
needs to be protected. I don't want to share with the world my social
security number. I also don't want to share with the world my code I use to
manipulate data. My code is an extension of the data and is useless without
data.

Businesses use databases like crazy. Non-technical people write their own
code to analyze data. The stuff they write many times is as valuable as the
data itself and should be protected like the data. They don't need or want
many times to go through a middle tier to analyze data or through the hassle
to obfuscate the code.

I think it is foolish to not make PostgreSQL as feature rich when it comes
to security as the competition because you are idealistic when it comes to
the concept of source code. PostgreSQL is better in many ways to MS SQL
Server and equal to many features of Oracle but when it comes to security,
it is closer to MS Access.


Jon

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Jon.Roberts@asurion.com ("Roberts, Jon") writes:
> I think it is foolish to not make PostgreSQL as feature rich when it
> comes to security as the competition because you are idealistic when
> it comes to the concept of source code. PostgreSQL is better in
> many ways to MS SQL Server and equal to many features of Oracle but
> when it comes to security, it is closer to MS Access.

I don't think that's quite fair.

There most certainly *is* a rich set of security features in
PostgreSQL, with some not-unreasonable defaults, to the point that it
has been pointed at as being 'more secure out of the box' than pretty
well any DBMS.

When people try to put security measures into the database that are
intended to secure it from, yea, verily, even the DBAs, it often
appears that once the feature list gets long enough, the critical
faculties of peoples' brains seem to shut off. They seem to imagine
that since there's a named set of features, that:
a) They are actually usable, and
b) They actually accomplish what they claim to be intended for.

Frequently, neither condition is true.

We've run into cases where attempts to manage fairly complex sets of
role-based security pretty much falls apart (e.g. - "they are not
usable") because for it to work, it's necessary that too many people
understand and follow the security design.

When *reality* is that the developers build things in an ad-hoc
fashion without regard to security, then you've got a ball of mud,
from a security standpoint, that no amount of pounding will force into
the rigidly-defined "security hole."

Note that ad-hoc reporting and analysis will always tend to fall into
this "ball of mud" category. They don't know what data they need
until they start exploring the problem they're given, and that tends
to fit Really Badly with any attempt to strictly define security
access.

Usability (item a) is troublesome :-(.

When you write about trying to hide source code and the likes, we
start thinking of item b), the matter of whether it actually
accomplishes what is claimed.

------------------------------
[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up]
Vizzini: HE DIDN'T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what
you think it means.
------------------------------

People seem to think that adding passwords, encrypting things, whether
via private or public key encryption, or other obfuscation "provides
security."

Rephrasing Inigo Montoy, I am not so sure that "provides security"
means what you think it means.

I worked one place where I heard a tale of "Payroll of Years Past."
They used to manage executive payroll (for a Fortune 500 company,
hence with some multi-million dollar paycheques!) via temporarily
adding the data into the "peons' system."

They had this clever idea:

- We want to keep the execs' numbers secret from the peons who run the
system.

- Ergo, we'll load the data in, temporarily, run the cheques, whilst
having someone watch that the peons aren't reading anything they
shouldn't.

- Then we'll reverse that data out, and the peons won't know what
they shouldn't know.

Unfortunately, the joker that thought this up didn't realize that the
transactional system would record those sets of changes multiple
times. So anyone looking over the audit logs would see the Secret
Values listed, not once, but twice. And they couldn't purge those
audit logs without bringing down the wrath of the auditors; to do so
would be to invalidate internal controls that they spent more money
than those executive salaries on. Duh.

They quickly shifted Executive Payroll to be managed, by hand, by
certain members of the executives' administrative staff.

That's much the same kind of problem that pops up here. You may
*imagine* that you're hiding the stored procedures, but if they're
sufficiently there that they can be run, they obviously aren't hidden
as far as the DBMS is concerned, and there can't be *too* much of a
veil between DBA and DBMS, otherwise you have to accept that the
system is not intended to be manageable.

We've done some thinking about how to try to hide this information;
unfortunately, a whole lot of the mechanisms people think of simply
don't work. Vendors may *claim* that their products are "secure," but
that may be because they know their customers neither know nor truly
care what the word means; they merely feel reassured because it's
"inconceivable" (in roughly the _Princess Bride_ sense!) to break the
security of the product.
--
let name="cbbrowne" and tld="linuxfinances.info" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/spreadsheets.html
Rules of the Evil Overlord #109. "I will see to it that plucky young
lads/lasses in strange clothes and with the accent of an outlander
shall REGULARLY climb some monument in the main square of my capital
and denounce me, claim to know the secret of my power, rally the
masses to rebellion, etc. That way, the citizens will be jaded in case
the real thing ever comes along." <http://www.eviloverlord.com/>

On Thu, Dec 20, 2007 at 01:45:08PM -0600, Roberts, Jon wrote:
> Businesses use databases like crazy. Non-technical people write their own
> code to analyze data. The stuff they write many times is as valuable as the
> data itself and should be protected like the data. They don't need or want
> many times to go through a middle tier to analyze data or through the hassle
> to obfuscate the code.

I'm not opposed to this goal, I should note. I just think that any proposal
that is going to go anywhere may need to be better than the one you seem to
have made.

I think column-level permissions is probably something that is needed.

a


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings