Messages in this thread | | | Date | Wed, 23 Feb 2000 12:56:30 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Capabilities |
| |
Horst von Brand <vonbrand@sleipnir.valparaiso.cl>: >Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said: >... >> There are other restrictions that can be applied by modifying the web >> server itself: >> >> 1. deny fork capability in children of the listening web server. > >No CGIs at all?
Sort of - the use of mod-perl is still available. The use of embeded Java is also possible.
This section was aimed at static pages though. I'm still working on data base support.
>> 2. deny any open for write capability. > >Can't write what the user entered for recording an order in e-commerce? > >> 3. deny listen, bind, connect... capability in children of the parent web >> server (no new network connections will be allowed after fork). > >No client/server database (or other stuff) either. > >Pretty boring website.
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. It is also usable for any read-only type of data. Several sites use a different server to recieve a post, process it, and have a staff member accept the result, which is then fed back to the original server. If (a big if) it is possible to use the embeded interpreters, then a checkout list could be done by using hidden variables to contain the reference list. This approach assumes that a limited size list is accepable (this should be able to hold 10-20 items). When it comes time to checkout then a pass to a different server would be used. All access to the data would be via a cgi embeded in the server, the browsers history list shouldn't be used. There may be some other restrictions I don't know about.
I am still exploring the use of MLS in web servers. In a MLS environment, it is possible to grant write access to an unreadable link to provide a connection to a separate database. The data base query may record data in a location the server can read (but not write). This can help separate the boundary between a penetrated web server, severly limit the amount of damage (other than DoS). The piece that I haven't yet examined is the interface between the server and database. There may not be a way to provably isolate the data base process other than by obscurity - (randomly generate a domain socket once per day - out of say 500? nah - to easy to try each one...). ------------------------------------------------------------------------- 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/
| |