DB design document

Derek Atkins warlord@MIT.EDU
22 Dec 2000 10:22:47 -0500


<linas@linas.org> writes:

> Hi Derek,
> 
> I want to say up front that I'm enjoying this conversation.  I say
> this because my response may seem like flame bait at times.  So
> please don't interpret any terseness or stridency below as an attack.

Thanks for the warning ;)

> It's been rumoured that Derek Atkins said:
> > 
> > <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
> > 
> > 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.
> 
> This is indeed the standard definition of a trusted network.

Right.  Unfortunately these assumptions can (almost) never hold true.
You can never be absolutely sure someone wont find yet another whole
in your perimiter.  The basic analogy is a "hard crunchy exterior is a
soft gooey interier."  If someone can get through the exterior, they
can do ANYTHING inside.  And if you have an insider attack, all is
lost.  You have no way to protect against it.

> DSL/cable modem is not a trusted network. Its open network.
> Yes, the kid down the block is probably snooping your packets.

Right, so you even want to encrrypt on your home LAN.

> > Also, how secure is your home machine?  
> 
> If your home machine is 0wn3d, then you can't trust it, and no amount
> of encryption can fix that, period.  If your 0wn3d, hacker can write
> a linux kernel extension to grab whatever data from wherever, and
> that's that, and yes, there have been cases of 'wild' kernel
> extensions (beleived to actually be authored by nsa, but that's
> another story...).

But let's continue with the Home LAN example.  You have MULTIPLE
machines in your house.  If one machine is 0wn3d, that does not
necessarily imply that other machines are 0wn3d as well.  You may be
able to verify that your machine is NOT 0wn3d, but your Spouse's may
be, and you're not sure.  This implies you cannot trust your spouse's
machine ;) Again, encryption would help (partially) in this scenario.
Perhaps this is a threat model that we just can't protect against?

(FTR: I have heard about these kernel extensions as well, although I
haven't actually seen any of them)

> > Let's take a small business example...
> 
> Normally, a machine with finacial data, esp. in a business, should
> not be connected to the net, period.   I'm sure there are mom&pop
> business that violate this.  

In today's world, you can't assume that.  Sure, we can stand on a high
horse and scream loudly "don't do that!" but all that will come from
that is that we'd quickly lose our voices.  Nobody these days has
special-use systems for data entry, even financial data.  Data entry
is done from the desktop, over the office network, using the same
computer that is used to read email or browse the web.  A company
president doesn't want to leave their office to "check the financials".

> There are ecommerce machines that need to shove order-processing
> thorugh various databases, these are usually protected with multiple
> layers of firewalls and audit proceedures.

But that's not enough.  A firewall really gives a false sense of
security.  See above on hard crunchy exteriors.  First, you never know
if you've got the firewall completely set.  Maybe there is a back
door?  Maybe there is a bug in one of the protocols that is behind the
firewall?

Also, even if you do have a firewall, an attacker can still intercept
and interrupt your data transmission.  They can grab your password off
the network and then replay it against an SQL server (or any other
server).  Or even worse, they can just sit there and read all your
data off the network.

> Finally, there are payroll machines, these should not be the same as
> the order/inventory machines, for the security reason.

See above about "don't do that" -- you can't assume that this is how
it actually works.  Yea, it _should_ work this way, and I'd bet that
ADP does it this way.  But I really don't see GnuCash entering the
ADPs of the world; it's more likely to replace QuickBooks.  And
QuickBooks users certainly don't follow this methodology.

> You are right, running encrypted data over 'trusted' network might 
> help discourage employee fraud.   As long as you've also taken
> measures to avoid clear-text passwords, etc. 

This is true.  One of my primary tenets when designing security for a
system is to state from the beginning that I don't trust the network.
Indeed, I don't trust _anything_.  Then I build up a reasonable trust
model from the ground up, explicitly stating the assumptions that must
hold for that model to remain valid.

If you want to get pedantic this list of assumptions might even start
at the PC hardware (motherboard, CPU, RAM, disk) and work up from
there! :)

I'm not completely convinced there can ever really be "too much
security."  Well, that's not true, you CAN have too much security.
Consider the model of security as risk assessment.  When the cost of
breaking a security system is multiple orders of magnitude greater
than the value of the information being protected, but using that
security system is a large performance hit, then yes, that might be
too much security ;)

> None of the people listed above should have either network or
> physical access to the machines containing financial data. 
> This is kind-of network admin 101 stuff, so I'm not sure why we
> discuss it.  

But that's not how it works.  I work for a 6000+ employee company
which is a subsidiary of a Fortune-500 company.  Employees are all
expected to run financial programs (purchasing, requisition, time
reporting, expense vouchering, etc.) over the corporate LAN from their
desktop PCs.  And no, as far as I can tell there is no encryption
protecting the data.

Corporations DO NOT run multiple LANs inside their network.  There is
this basic assumption that all employees are trusted to access the
network.  Sure, you might limit physical access to the machines
holding financial data, but you can't limit the "network access" to
such machines.  I mean yes, you can limit who has a passwd entry on
the machine, who can login.  But that is ___NOT___ limiting network
access.  If the coworker next door to me can login to that machine,
even if I cannot, I can get in off their coat-tails.

So sure, the machines may be firewalled.  But users (legitimate or
otherwise ;) of those machines are going to use them from their own
desktop machines.  And the network transit between those desktops and
the servers is still unprotected.

> Note also: if are a publically traded corporation, or a startup that 
> needs to be audited because the VC asks for it, the auditors will 
> review and question your firewall config, the network topology and
> the physical/network access thing.  You will fail the audit if you
> get this wrong.

But all they ever worry about is hacking from an outsider.  Can any
random schmo get to www.yourcompany.com and read your financial data?
Can they get to ftp.yousuck.com and download your intellectual
property?  I've been through these audits, and that's what they care
about.  They don't care that the company president's traffic crosses
the same LAN that the engineers use.

> On the other hand, chumps rule the world ...

Um, yea.  Succinctly put ;)

> > I'm not proposing that we re-invent, 
> 
> I'm just concerned abou building complex, hard-to-maintain systems
> that don't have a clear scope of requirements that are to be solved.

It's only "complex" because you don't understand it. ;) I think
GnuCash is complex, but that's because I don't understand it.  I've
never really taken any accounting classes, and I don't inherently know
the lingo.  I've picked a lot of it up over time, and it makes a lot
of _logical_ sense to me (unlike the law, but that's another story) so
I feel I can at least try to converse with others.  But honestly,
we're going to have to accept _some_ of the complexity in order to do
what we want.

As for the clear requirements, you are correct -- we do need a clear
set of requirements.  I've been trying to state what my requirements
are, in terms of security, and I've been trying to glom usability
requirements from other people.  But there isn't a requirements
docuement anywhere that really describes where GnuCash is heading.

> > investigate using ONC RPC as the marshalling system, which is much
> > less overhead than CORBA, 
> 
> Its not obvious to me that any RPC has lower overhead than corba.
> I'm tempted to beleive the opposite.

Then, unfortunately, you're tempted to be wrong.  RPC (I'm going to
presume RPC == SunRPC == ONC RPC from now on) tries to bite off a much
smaller problem space than CORBA does, so the required solution space
is also much smaller.  It also means that RPC is much more limited
tool, but I think it would suffice for our needs.  Indeed, all of the
RPC code is included in libc on most systems!

Basically, CORBA is RPC on steroids.  RPC is a pure remote procedure
call system where you have to pass state data back and forth.  A
particlar RPC call can execute exactly one piece of code.  CORBA, on
the other hand, is object based.  Objects reside across the net, and
you invoke methods in the objects (which may involve an RPC to the
method of the object on a remote machine).  This involves Object
Request Brokers, extra processes that are necessary on both client and
server to get CORBA calls to work.

> Besides, remember that corba was invented to solve many of the evils
> and lack of function that rpc didn't/couldn't do.

True, but do we actually NEED that extra functionality?  I'm not
convinced we do.  OTOH, as I've stated, I'm not tied to any particular
solution, either.  If we had a clear set of requirements then we might
better see the right way to do this, and I would certainly be willing
to use CORBA instead of RPC.  However, I'd rather use the smallest and
easiest (RPC is just as easy to use as Corba, honestly) tool necessary
to complete the job.  Why use a sledgehammer to nail a picture to the
wall?

> This is one reason I nominated corba.  Many (but not all) of the api 
> questions melt away, with an 'obvious' answer.   

The same is true for RPC.  Indeed, the CORBA IDL is derived from the
RPC IDL!  I was quite amazed when I found this out.  And for the
record, ORBit currently does not support any security.  There is an
ORBit-SSL project underway, but it's unclear how long that will take.
(OTOH, I must admit that RPC has limited security functionality as
well, but the source code for RPC is much smaller, and I've worked
with it before :)

> Note events & notifications should work in corba, & I don't know how
> to do them with RPC, except as polls.

They work exactly the same in RPC: you setup callback functions, and
the server calls back to the client.

> > provided that we do limit the scope of where SQL enters the rest of
> > GnuCash.
> 
> Yes, its important for me that we don't wake up one day and find 
> sql code scattered throughou the gnucash engine in some adhoc way.
> That would be fatal.

Agreed.  The same is true for network functions.  It would be just as
fatal to have the client-server pieces scattered throughout the
system.

> --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