A Simple Access Control Mechanism

Overview

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.

Default Port

In addition to pattern matching on hostname tokens, the access mechanism can also optionally match on a port 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 directives

Limit GET

Used for the HTTP plugin to limit which hosts a KP may request information from. (Default port: 80)

Limit POST

Currently not used in the KOS. Intended to restrict the HTTP plugin POST operations, which are not implemented. (Default port: 80)

Limit Submit

Limits which host an arriving KP may be submitted from.

Limit KpKill

Limits which host may call the Receiver's KillKP() method.

Limit WorldRootPeer

Limits peer connections between worldroot servers. Specifies (1) which hosts to accept peer requests from and (2) which hosts to make peer requests to. (Default port: 7438)

Limit WorldRootShutdown

Limits which hosts can request to shutdown the worldroot server.

Limit VisuShutdown

Limits which hosts can request to shutdown a visualizer.

Limit KosShutdown

Limits which hosts can request to shutdown the KOS kernel.

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:

order allow, deny

Specifies which order the allow and deny directives will be evaluated. In this case, the allow directives are the default and the deny directives override the defaults.

order deny, allow

Specifies which order the allow and deny directives will be evaluated. In this case, the deny directives are the default and the allow directives override the defaults.

Note on order The order directives, borrowed from the NCSA httpd configuration format, can be confusing. order allow,deny means 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.

allow to <FQDN> [, port]

Allow connections to the specified fully qualified domain name and port. If a port is specified, it overrides the default.

allow to .<Subdomain name> [, port]

Allow connections to all hosts that match the specified partial domain domain name and port. If a port is specified, it overrides the default.

allow from <FQDN> [, port]

Allow connections from the specified fully qualified domain name and port to the current KOS. If a port is specified, it overrides the default.

allow from .<Subdomain name> [, port]

Allow connections from all hosts that match the specified partial domain domain name and port. If a port is specified, it overrides the default.

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.

Example configuration files

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>

Determining caller identity

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.