lkml.org 
[lkml]   [2000]   [Feb]   [23]   [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:
>...
>> 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/

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