On Fri, 25 Feb 2000, Alan Cox wrote:
>> > The catalog too - consider what happens when part numbers get scrambled -
>> > ordering an inexpensive video card could get switched for an entire PC.
>>
>> Yes, but that is far less damaging than compromising the credit card numbers
>> and whatnot of the entire customer base.
>
>Anyone directly exposing databases of credit information on their internet
>machines deserves a negligence suit.
>
>A proper setup looks like this
>
>
>--[firewall]---[Web box] -serialline- [backend]
>
>The serial line takes a fixed command set to a verified small code daemon on
>the backend side. It has commands for 'store credit details' it has NO
>command for 'retrieve credit card number'. You don't need that functionality
>on the front end boxes.
Actually the credit card info has to be passed to the backend for
storage/validation. It just doesn't need to be stored on the front end.
The front end might support the checkout procedures.
What I'm experimenting with is/would be setup as:
--[firewall]---{[Web server] -security interface- [backend] }
{ MLS + capability box }
where the [backend] may just be a distributed database front end (oracle
net interface type of thing... not intended as a plug for oracle). This allows
multiple servers to work in tandem where the browser may be bouncing among
them without the users knowlege. The first entry could generate a token via
generation by the -scurity interface-. The security interface can pass it
to to both the current web server, and the backend database. The token
may be passed back to the browser as a (or part of) a cookie. If the browser
connects to a different web server then the token can be used by the backend
to join transactions together into a session. The web server has no knowlege
of or needs to know what the private customer information is. It only has data
corresponding to the active transaction. Once the transaction is complete the
server has no data of it.
The -security interface- provides more active protection than just a serial
line. It also allows the use of larger single systems for higher throughput
and lower overall cost (support staff). The RSBAC project appears to have
the MLS - I just have to finish design, documentation, testing, documentation,
... The "active protection" involves detection of bad/out of date tokens
and the ability to generate phony data while the potentially penetrated
server is examined (usually automatic examination, but staff observation
would be possible). It also limits the failure mode, since only one server
out of several would have been broken into. At this point it depends on
how the server operates. If it is apache, with multiple "slave" servers, then
only the "slave" server would have been penetrated. Cleanup would just involve
killing the "slave" and the parent server would start a new "clean" slave.
This also implies that for each "slave" server, there exist a "-security
interface-" process. The same is implied for the serial line connection,
otherwise you end up with a protocol that becomes equivalent to PPP just
to share transactions with the [backend].
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.netAny 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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:15 EST