Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Making all data read-only without a supersecret password
Mon, Jun 28 2010 12:57 AMPermanent Link

Jeff Dunlop

With regard to an enterprise class application that lives in a hostile environment with customers and vendors with no scruples: Assume a very clever 3rd party vendor with physical access to an elevate server.

What are the steps necessary to prevent write access to local table files?
Mon, Jun 28 2010 3:41 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jeff


I know you said without a supersecret password but my initial thoughts would be:

1. add encryption
2. add engine signature
3. remove all administrator users and lock users down to the lowest access level you can at each point eg Database & table (I think that's select)

I would then look at altering the server so that it only accepts connections from nominated IP addresses and alter your app so that these are passed through and checked.

Finally I'd step outside your app and look at what you can do with Windows security as well.

There was a bug in an earlier version  of ElevateDB which effectively turned the whole database read only, unfortunately the cure was simple if you had EDBManager; dump the catalog (or it might have been config I can't remember) and recreate.

Another thought just occurred. Make it a self healing database. The big problems I can see with that is the amount of processing power needed and storing the original in some way or another to allow the healing.

I'll be interested in Tim's advice.

Roy Lambert
Mon, Jun 28 2010 11:25 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jeff,

<< With regard to an enterprise class application that lives in a hostile
environment with customers and vendors with no scruples: Assume a very
clever 3rd party vendor with physical access to an elevate server.

What are the steps necessary to prevent write access to local table files?
>>

Well, the problem is that once a person has physical access to the server
machine hosting the ElevateDB Server, then all bets are off.  Do these
persons have administrator access to the Windows Server OS ?

--
Tim Young
Elevate Software
www.elevatesoft.com
Tue, Jun 29 2010 6:19 PMPermanent Link

Jeff Dunlop

Yes, physical admin access to the computer. Managing remote connections is easy enough, but how do I prevent using Manager locally? All I really want to prevent is a rogue script being run by anyone but us.
Sat, Jul 3 2010 9:57 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jeff,

<< Yes, physical admin access to the computer. Managing remote connections
is easy enough, but how do I prevent using Manager locally? All I really
want to prevent is a rogue script being run by anyone but us. >>

The easiest way is to use a custom engine signature.  That will prevent them
from using the EDB Manager with the EDB Server, or locally, if it is running
the default engine signature.

If you need to do this on an existing installation, let me know and I'll
work up a utility for changing the signatures.  I need to add such a utility
to EDB anyways, so it's not extra work.

--
Tim Young
Elevate Software
www.elevatesoft.com
Sat, Jul 3 2010 11:49 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jeff


Since Tim is also advocating a supersecret password (ie the engine signature) if you want a nifty way to hide it send me an email. For obvious reasons I'm not posting it in the open.

Roy Lambert
Image