[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working on a security best practices document

On Thu, Jan 28, 2010 at 3:39 AM, Michael Richardson <..hidden..> wrote:

>>>>> "Chris" == Chris Travers <..hidden..> writes:
   Chris> so we can check to see that the user on the cert is the same
   Chris> user as the provided credentials.  LDAP might be needed to
   Chris> make that work cleanly though....

LDAP is not necessary or important.
Apache will provide a DN, etc. to the script.
see http://httpd.apache.org/docs/2.2/mod/mod_ssl.html, and the
SSL_CLIENT_* variables.

I was thinking more along the lines of authenticating that the certificate maps to a specific user, short of requiring the username in the cert.  LDAP might make it easier to avoid problems.

   >> What do you have in mind here?

   Chris> This:  https://wiki.mozilla.org/Security/CSP/Spec

I see...very interesting. This is useful, particularly because it kills
eval() in the _javascript_.

   Chris> I see SSL as a critical tool for solving certain kinds of
   Chris> problems.  It is hardly a panacea but it solves certain
   Chris> specific problems quite well despite being somewhat clumsy
   Chris> because it is a partial port of an OSI protocol to TCP/IP
   Chris> (and OSI protocols ported to TCP/IP generally suck from a
   Chris> TCP/IP standpoint).

The SSL certainly provides privacy, and combined with client side
certificates provides useful authentication.  No question about that.

But, in the situation where the browser is on the corporate intranet,
one hop from the server, or in my personal company case, where the whole
thing is "localhost", it wasn't privacy that was the problem.

Ok, there is a specific issue with 1.3 that I think requires SSL on the corporate intranet in order to be effective.

The basic issue is that we use internal db accounts so we have to obtain credentials from the web browser we can use to authenticate against the db.  Currently the only way supported to do this is via HTTP Basic Auth, though Kerberos could be supported for intranet environments with a little effort.

For an intranet environment really you need to either have Kerberos support (which doesn't exist yet but could be developed without too much effort) OR use SSL.  For mixed intranet/VPN access, you might want to use both (to allow for someone logging into the db with a TGT created from credentials obtained via http basic auth).

The problem is inappropriate disclosure of data :-)

   >> I'd rather we spent time on:
   >> a) a good dump/restore/"fsck" program that can be used to
   >> validate that data is still good.

   Chris> This will become less important as the data integrity
   Chris> controls become more
   Chris> robust as they do in each version.

hmm. I'm not sure I agree.
I think the proposals to rename the 1.2 tables, and then do INSERTs from
the into the 1.3 tables are good.  What I want to do is to extend this
to support saving to a 2nd-normal-form representation such that a human
can more easily inspect what is going on....

What about a new schema with VIEWs that are in 2nf?

This is as much about producing good audit records as it is to permit
recovery from data corruption that may have occured in the past...

Has anyone considered having an ledgersmb mini-conference either
independently, or as a summit of another conference... e.g. PGcon,
OLS, onlinux, OScon, ???

Not yet.  Maybe we will get there though :-)  Efforts in helping with such things is appreciated.

Best Wishes,
Chris Travers