DB design document

[Derek Atkins]

<linas@linas.org> writes:

> Lets reanalyse the requirements. You want security. Why? to run over
> the open internet?  If you're running over the open internet, then

Not exactly.  It's just that I don't trust the network I'm sitting on,
regardless of where I am.  Let's suffice it to say that there ain't no
such thing as a "trusted network."  The whole concept is flawed.  Let me
explain what I mean.

The whole concept of a trusted network assumes that you can trust
everyone who has access to that network.  It also assumes that you
trust every machine sitting on that network.  It also assumes that you
trust the people running the network.  It also assumes that none of
your machines can be turned against you.  It also assumes that none of
these assumptions can be broken.

So, you're sitting at home on your home LAN.  Let's assume you're
connected to the internet via DSL or CableModem.  Do you know how your
ISP has you configured?  Are you absolutely sure you're not bridged?
I have some friends who were able to see their neighbors' traffic
across their cablemodem, so it certainly is possible.  Would you trust
your neighbor to know your financial situation?

Also, how secure is your home machine?  Are you sure nobody broke in
and installed a sniffer on your (trusted) home network?  Hey, somebody
broke into _my_ Linux box a year ago, so don't quaff that it can't
happen to you :)

Let's take a small business example...

Remember that financial information is considered extremely private.
There are even special laws for protecting it!  Indeed, even when the
United States had export limits on cryptography, there were specific
exceptions for financial data.  If you could prove that your system
was just for financial data, you could export strong cryptography,
even when everyone else was limited to less-than-DES.

So, do you trust all your employees and co-workers?  How do you know
what the employee in the next office is doing or thinking?  Are they
disgruntled?  Maybe they want to know how much you're making?  Perhaps
they are being paid by a competitor?  Do you trust the people actually
running the network?  Who maintains your routers?

Of course, don't forget about those pesky crackers, who may be paid to
break in and get your financial information.  All it takes is a single
unprotected windows box and they now have all your network traffic
from your supposedly "trusted" network.

Obviously we still have to trust SOME people, such as the users who
need to access your financial data, and potentially the sysadmins and
DBAs who maintain your database.  But you can reasonably limit that to
a finite number of people, rather than everyone.

And yes, just using SSL would protect you from the casual snooper..
Except how do you prime the system?  How do you get your passwords
into the database?  Are you sure your sysadmins use SSH all the time?
And how do you know that your SSH wasn't attacked (there was an active
man-in-the-middle attack against SSH at the IETF last week, and yes, a
number of people were actually hit by this!)

The worst thing you can do is claim that someone else will provide you
your security and privacy.  If you still have doubts or concerns, I
can recommend some books or courses on basic network security.  The
reality is that it's scary out there, so we should be proactive in
protecting our "customers" and their data.

> If there are no public servers, then wouldn't encryption be better
> provided by a VPN or other tunneling mechanism?  Why reinvent?

See above.  A VPN provides you security across the core public
network, but it doesn't protect you from insiders.  Unfortunately,
most financial trouble is caused from insiders.

I'm not proposing that we re-invent, at least any more than we would
have to anyways.  We'd still have to invent the SQL queries, XML
Schema, CORBA interfaces, etc.  Indeed, my first approach would
investigate using ONC RPC as the marshalling system, which is much
less overhead than CORBA, IMHO, but would require the about same
amount of work.  Also, ONC RPC (aka SunRPC) is distributed on just
about every UNIX platform (I can't think of any platforms that DON'T
have ONC RPC available) so we wont have to worry about portability.

I've just grabbed a book on CORBA, and I'm looking at information on
ORBit.  I've certainly not bought into to one camp or another.

> > I've also volunteered to write the gnc_server/gnc_client code,
> 
> I suppose I shouldn't discourage, then.

:)

> > provided I am given help with providing the APIs that the engine will
> > need.
> 
> Hmmm. That's hard.

Actually, it's not that hard.  We've been working towards this on the
list.  For example, we've been discussing the Query API, which is one
such data-store API.  We would still need to discuss the APIs to
obtain the lists of accounts, groups, etc.  And we also need to
discuss the data write APIs, and data cache conherency (events &
notifications?)

I think as we discuss APIs this will "fall out" as we try to abstract
out the data store.  This will all be necessary if we modularlize the
SQL code anyways.  So we should get a lot of this discussion for free,
provided that we do limit the scope of where SQL enters the rest of
GnuCash.

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available