Re: viewing source code

Jon(dot)Roberts(at)asurion(dot)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/>