Messages in this thread | | | Date | Thu, 24 Feb 2000 08:06:55 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Capabilities |
| |
Horst von Brand <vonbrand@sleipnir.valparaiso.cl>: >Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said: > >[...] > >> That depends on the purpose of the web site. It can be used as a >> catalog lookup (mod-perl or java module in the apache web server). It can >> also redirect the browser to another site for the busines applications. > >THOSE are the applications that merit a heavily secured machine, not the >catalog. Some solutions that doesn't impede functionality has to be found.
The catalog too - consider what happens when part numbers get scrambled - ordering an inexpensive video card could get switched for an entire PC.
I'm still working on the "another site for the business applications" bit. Right now it looks like a local domain socket provides the best isolation between a server (under the described controls) and a front end database.
Attacking the database requires penetrating the base web server, then capturing an encrypted token from a browser to then start attacking the database via the domain socket. If the server did not locally store the encrypted token, then the checkout session would have to be penetrated at the right time (or the token wouldn't be available). This approach may provide the penetration detection needed by the database engine to cause a shutdown before the customer database itself is damaged. It doesn't protect against a denial of service, but would protect privacy, and the integrity of the customer data.
At the moment I'm not considering a network socket because then there must be something to authenticate the host/server to the database server. Capturing that may open other windows of attack.
Now I'm not saying the real database server wouldn't be on another system. Just the communication from the web server to a "front end" database interface application would use the domain socket. The "front end" can then validate the token (which does nothing to protect against captured tickets, only remote unauthorized connections to a valid server).
The front end can gather the additional information needed by decrypting the token and using contained information to retrieve session information. The session data would be stored in a short-lifetime database used to track the customers current order set. Short being defined as until checkout time, or a predefined time interval (say 1 hour, for instance) of no activity. The collected data can then be packaged up for a database query/update.
Any generated responses would be fed back through the domain socket. If handling errors (invalid tokens, very old tokens that have expired, and front end transaction log analysis?) then a potential penetration of the web server may be detected. Reactions to a detected penetration would include notifying someone in authority, disconnecting from the server or falling into an avoidance behaviour, faking results, generating extensive activity logs, anything but modifying the customer database.
I'm hoping for a better security model than the normal UNIX one, including capabilities, ACLs, and multi-level security. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |