Several components of the KOE use the access module to implement basic security measures. A service station, for example, can restrict the hosts it will accept KP submissions from. Additional information about Security Considerations is also available.
The access module implements a general framework for access control lists. It is modeled after the access configuration files used for several HTTP servers. The KOE configuration file is config/access.conf and the urllib proxy configuration file is config/access.http.conf.
The KOE uses the Limit directive to restrict which hosts can participate in an inter-component transaction such as submitting a KP or establishing a worldroot peer. Each entry in a limit clause grants or denies permission for hosts matching the specified pattern.
In addition to pattern matching on hostname tokens, the access
mechanism can also optionally match on a
specification. The port option is designed to further fine-tune
access granularity based on a particular IP port. The port
field is only checked for
allow to directives.
Placing the reserve word all in the port field position in an access.conf entry indicates that any port is considered a match when making the comparison on that host.
Leaving the port field unspecified in an access.conf entry, lets access assume the default port for the limit group in question when permission inquiries are made. Each limit group has a specific notion of default port. These are enumerated below for groups where default port has meaning:
Limit clauses begin with an open tag (a la HTML) of the form
<Limit name>, where name is one of GET,
POST, Submit, etc. Following the open tag is one or more lines
containing specific directives. The directives are:
Note on order The order directives, borrowed from the NCSA httpd configuration format, can be confusing.
order allow,denymeans that any host that matches an allow directive will be granted permission unless it also matches a deny directive. If the host doesn't match any pattern, it will be denied.
Think about the order directive as establishing three levels, each of which supercedes the level below it. For the directive
order deny, allow, the bottom level is allow, the middle level is deny, and the top level is allow. The top level is checked first: If an allow directive matches, access is allowed. Then the middle level is checked: If a deny directive matches, access is denied. The bottom level is used when the other two checks fail, and access is allowed.
Most of the KOS functions look for allow from or deny from limit directives (with the exception of worldrootpeer which looks at both from and to directives). The HTTP plugin looks for allow to and deny to directives within the Limit GET group in the HTTP access.conf file.
The access.conf file contains all the limit clauses for standard KSS and worldroot services. An example file is shown in Example 1.
Example 1. Example KOS access.conf file# # Top level permissions file to control access to KOS services # <Limit SUBMIT> order allow,deny allow from .cnri.reston.va.us allow from .trusted.domain </Limit> <Limit KPKILL> order allow,deny allow from .cnri.reston.va.us </Limit> <Limit WORLDROOTPEER> order allow,deny # allow connections from peers in CNRI on default port (7438) allow from .cnri.reston.va.us # allow connections to peers in CNRI on default port (7438) allow to .cnri.reston.va.us allow from .trusted.domain allow to .trusted.domain # allow connections to/from oddball on port 4242 allow to oddball.cnri.reston.va.us, 4242 allow from oddball.cnri.reston.va.us, 4242 </Limit> <Limit KOSSHUTDOWN> order allow,deny allow from .cnri.reston.va.us </Limit> <Limit VISUSHUTDOWN> order allow,deny allow from .cnri.reston.va.us </Limit> <Limit WORLDROOTSHUTDOWN> order allow,deny allow from .cnri.reston.va.us </Limit>
The Limit GET and POST directives only apply to the HTTP plugin and the urllib proxy, which share a separate configuration file in config/access.http.conf. Example 2 shows a configuration that denies GET access to internal Web servers and explicitly allows GET access to public Web servers. It allows POST access only to three specific Web servers.
Example 2. Example HTTP access.conf file# This access file used at CNRI denies access to CNRI's internal # servers but allows access to its public servers. Access to hosts # outside CNRI is unrestricted. # # Note: "order deny,allow" implies that the default is to allow. # This is the way we want it -- allow to the world, deny inside CNRI, # except allow to the public http and ftp servers. <Limit GET> order deny,allow deny to .cnri.reston.va.us, all # Public HTTP servers allow to www.cnri.reston.va.us, 80 allow to python.cnri.reston.va.us, 80 allow to grail.cnri.reston.va.us, 80 </Limit> <Limit POST> order allow,deny allow to www.cnri.reston.va.us, 80 allow to grail.cnri.reston.va.us, 80 allow to www.python.org, 80 </Limit>
The access module determines the host making a request using the ILU CallerIdentity() function, which returns the IP address of the caller. Since the access.conf files only support naming hosts by their names and networks by their domains (and sub-domains), the IP address is resolved to a fully qualified domain name. A reverse lookup is done on the name to verify that address provided by ILU is correct.