lkml.org 
[lkml]   [2000]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.744 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site