Previous section.

Distributed Software Administration - DCE Interoperability (XDSA-DCE)

Distributed Software Administration - DCE Interoperability (XDSA-DCE)
Copyright © 1997 The Open Group

XDSA-DCE Security

This chapter presents an overview of Access Control Lists (ACLs) for XDSA-DCE objects, the definition of the distributed utility for managing ACLs, and associated the RPC interface definitions used to implement the utility. It contains the following sections:

XDSA-DCE Security Model Overview

Along with the traditional POSIX standard file access permissions, certain XDSA-DCE software objects are protected by ACLs. When any management task attempts to create, read or write these objects, the principal (user) executing that task is checked against the ACL protecting that object.

In the distributed model defined by XDSA-DCE, the daemon and agent processes perform these checks using the principal, group, and realm information passed with each RPC. It is possible for each implementation to have its own implementation of access control (enforced by the daemon and agent). However, by supporting XDSA-DCE ACLs, interoperable distributed management of ACLs is possible.

Object Types

ACLs are supported on hosts, installed software collections, distributions and products in distributions.
Figure: ACL Object Types

The host ACL protects the host object, primarily for registering and listing registered distributions and installed software collections.

The root ACL protects the installed software collection objects, for installing, listing and otherwise managing installed software.

The depot ACL protects the distribution objects, for creating new products in the distribution, as well as listing the products in the distribution.

The product ACL protects individual products in the distribution, for serving those products to target agent copy and install tasks, as well as managing those products within the distribution.

There are also template ACLs used for the initial ACLs when creating new distributions, products within distributions and installed software collections

Figure: Template ACLs
The global_soc_template ACL is used as the initial root or depot ACL when a new installed software collection or distribution is created.

The global_product_template ACL is used for the initial product_template ACL when a new distribution is created.

The product_template ACL is used for the initial product ACL when a new product in a distribution is created.

ACL Entries

Each entry in an ACL has the following form:

entry_type[:key]:permissions

For example:

user:steve@newdist:crwit

An ACL can contain multiple entries. The output of a list operation for an ACL (using swacl) is in the following format:

#
# swacl <object_type> Access Control List
#
# For <host|depot>: [<host>][:][<directory>]
#
# Date: <date_string>
#
# Object Ownership:  User=  <user_name>
#		     Group= <group_name>
#		     Realm= <host_name>
#
# default_realm=<host_name>
<entry_type>:[<key>:]<permissions>
<entry_type>:[<key>:]<permissions>
<entry_type>:[<key>:]<permissions>

This output can be saved into a file, modified, and then used as input to redefine an ACL using the swacl -F option.

Object Ownership

An owner is also associated with every object, as defined by the user name, group and hostname. The owner is the user who created the object. When using swacl to list an ACL, the owner is printed as a comment in the header.

Default Realm

An ACL defines a default realm for an object. The realm is currently defined as the name of the host system on which the object resides. When using swacl to view an ACL, the default realm is printed as a comment in the header.

When DCE Security Services are used (set by the authentication_service option), the realm is the DCE cell.

Entry Types

The following entry_types are supported:

object_owner

Permissions for the object's owner, who's identity is listed in the comment header.

Example:

object_owner:crwit.

object_group

Permissions for members of the object's group, who's identity is listed in the comment header.

Example:

object_group:crwit.

user

Permissions for a named user. This type of ACL entry must include a key that identifies that user. The format for user can be:

user:user_name:permissions

or:

user:user_name@hostname:permissions

Example:

user:rml:crwit.

group

Permissions for a named group. This type of ACL entry must include a key that identifies that group. The format for group can be:

group:group_name:permissions

or:

group:group_name@hostname:permissions.

Example:

group:adm:crwit.

host

Permissions for a target agent from the specified host system. Agents require product level read access via either a host, other, or any_other entry type in order to copy or install products from distributions. This type of ACL entry must include a key containing a hostname of a system.

Example:

host:newdist:-r--t.

other

Permissions for others who are not otherwise named by a more specific entry type. The format for other can be:

other:permissions

for others on the local host (only one such entry allowed) or:

other:@hostname:permissions

for others at remote hosts (only one such entry per remote host allowed).

Example:

other:@newdist:-r--t.

any_other

Permissions for all other users and hosts that do not match a more specific entry in the ACL.

Example:

any_other:-r--t.

The order of the above entry types is significant. Except for group entry types, permissions to an object for a user or host are determined by a match to a single ACL.

The user or host is checked against entries of each type in the order shown in the above list until the match is found. If a match is found with an entry type of group, then a union of permissions for all group entries that match the users primary and secondary groups are included.

Keys

A key is required for user, group and host entry types. A key is optional for other entry types, and specifies the hostname to which the entry applies. Only one other entry type may exist without a key, and this entry applies to users at the default realm (host) of the ACL.

A hostname in a key will be listed in its Internet address format (dot notation) if swacl cannot resolve the address using the local lookup mechanism (for example DNS, NIS, or /etc/hosts). A hostname within an ACL entry must be resolvable when used with the swacl -M and -D options. Unresolvable hostname values are accepted in files provided with the swacl -F option.

Permissions

Permissions are represented as the single character abbreviations indicated below. Some permissions either apply only to, or have different meaning for, certain types of objects, as detailed below.

The following permissions may be granted:

c(ontrol)

Grants permission to modify the ACL using swacl.

r(ead)

Grants permission to read this object.

On host, distribution, or installed software collection objects, read permission allows swlist operations. On products within distributions, read permission allows product files to be read for swinstall, swcopy and swlist operations.

w(rite)

Grants permission to modify the object.

On a installed software collection object (for example, installed installed software collection filesystem), this grants permission to modify the products and product files installed into the installed software collection object. On a distribution object, this grants permission to remove an empty distribution. It does not grant permission to modify the products contained within it; write permission is required on each product object in the distribution. On a host object, write permission grants permission to unregister distributions.

i(nsert)

Grants permission to insert objects into this object.

On a host object, grants permission to create (insert) a new software distribution or installed software collection object, and to register these objects. On a distribution object, grants permission to create (insert) a new product object.

t(est)

Grants permission to list the ACL.

a(ll)

A wildcard which grants all of the above permissions.

It is expanded by swacl to crwit.

Depot Registration and Access Control

Because the distribution can be stored on a file system, anyone could build something which included a "Trojan Horse" (that is, something unrecognized as a threat but which could inflict damage), thereby exposing any system that installed products from it to a security breach. To protect systems from such a situation, a distribution must be registered (either through swcopy or swreg) before software may be installed or copied from it.

Secrets File

If the authentication_service option is set to internal (DCE Security Services are not being used), an encrypted secret password is sent with each RPC call as a proof of trustworthyness in place of authentication.
Note:
This proof does not provide the level of DCE Security Service authentication, but does provide an additional level of trust.

Each manager and daemon host maintains a secrets file that contains a set of realm/secret pairs. The realm can be the NIS domain name, internet name, or network address of a manager host, and the secret is the unencrypted password associated with that realm.

The manager searches the secrets file for its realm, and encrypts the secret associated with that realm using crypt(3), prepending the salt used to the encrypted secret. It communicates that encrypted secret to the daemon or agent in the internal_authn_secret option for XDSA-DCE RPC calls. The daemon or agent serving the RPC call then searches its secrets file for an entry for the manager realm communicated via the internal_authn_realm option, encrypts the secret associated with that realm. If the encrypted secrets do not match, the call is not authenticated and it fails.

Each host can define a "default" secret that is used if there is not an entry specific to the realm requested, as shown in the following example implementation secrets file:

default			quicksilver
argo.finesoft.com	zztop!
15.25.34.122		soundgarden

Access Control Checks by RPC Call

Access to software objects is protected as part of various RPC calls. These checks are as follows:

As a special case, the local super-user is granted access to any local object and is granted access to modify any local ACL. DCE-RPC Interoperability (XDSA-DCE) - swacl

Previous section.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

NAME

swacl - view or modify software Access Control Lists (ACLs)

SYNOPSIS

swacl -l level [-D acl_entry | -F acl_entry | -M acl_file] [-f
software_file] [-t target_file] [-x option=value] [-X option_file]
[software_selections] [@ target_selections]

DESCRIPTION

The swacl command displays or modifies the Access Control Lists (ACLs) which:

All installed software collections, software distributions, and products in software distributions are protected by ACLs. The commands permit or prevent specific operations based on whether the ACLs on these objects permit the operation. The swacl command is used to view, edit, and manage these ACLs. The ACL must exist and the user must have the appropriate permission (granted by the ACL itself) in order to modify it.

ACLs offer a greater degree of selectivity than standard file permissions. ACLs allow an object's owner (that is, the user who created the object) or the local superuser to define specific read, write, or modify permissions to a specific list of users, groups, or combinations thereof.

OPTIONS

When none of the -M, -D, or -F options are specified, swacl prints the requested ACLs to the standard output.

The swacl command supports the following options:

-D acl_entry

Deletes an existing entry from the ACL associated with the specified objects. (For this option, the permission field of the ACL entry is not required.) Multiple -D options can be specified.

-f software_file

Read the list of software_selections from software_file instead of (or in addition to) the command line.

-F acl_file

Assigns the ACL contained in acl_file to the object. All existing entries are removed and replaced by the entries in the file. Only the ACL's entries are replaced; none of the information contained in the comment portion (lines with the prefix "#") of an ACL listing is modified with this option. The acl_file is usually the edited output of a swacl list operation.

If the replacement ACL contains no syntax errors and the user has control permission on the ACL (or is the local super user), the replacement succeeds.

-l level

Defines which level of ACLs to view/modify. The supported levels are:

host

View/modify the ACL protecting the host systems identified by the target_selections.

depot

View/modify the ACL protecting the software distributions identified by the target_selections.

root

View/modify the ACL protecting the installed software collection filesystems identified by the target_selections.

product

View/modify the ACL protecting the software product identified by he software_selection. Applies only to products in distributions, not installed products in installed software collections.

product_template

View/modify the template ACL used to initialize the ACLs of future products added to the software distributions identified by the target_selections.

global_soc_template

View/modify the template ACL used to initialize the ACLs of future software distributions or installed software collections added to the hosts identified by the target_selections.

global_product_template

View/modify the template ACL used to initialize the product_template ACLs of future software distributions added to the hosts identified by the target_selections.

-M acl_entry

Adds a new ACL entry or changes the permissions of an existing entry. Multiple -M options can be specified.

-x option=value

Set the session option to value and override the default value (or a value in an alternate option_file specified with the -X option). Multiple -x options can be specified.

-X option_file

Read the session options and behaviors from option_file.

-t target_file

Read the list of target_selections from file instead of (or in addition to) the command line.

Only one of the -M, -D, or -F options can be specified for an invocation of swacl. For example, the -M and -D options cannot be specified together.

OPERANDS

When used with the -l product level, the swacl command allows the POSIX 1387.2 standard software specification syntax for each software_selection in order to specify one or more products. If the software selection refers to a bundle, then all products contained in that bundle are included. If the software selection refers to a subproduct or fileset, then the containing product is included.

The swacl command supports the following syntax for each target_selection:

[host][:][/directory]

The ":" (colon) is required if both a host and directory are specified.

EXTERNAL INFLUENCES

The swacl utility supports the following extended options:

distribution_target_directory=implementation_defined_value

Defines the default location of the target distribution.

level=

Defines the level of ACLs to view/modify. The supported levels are: host, depot, root, product, product_template, global_soc_template or global_product_template. See also the discussion of the -l option above.

rpc_binding_info=ncadg_ip_udp:[2121]

Defines the protocol sequence and endpoint which will be used to contact swagentd.

rpc_timeout=5

Relative length of the communications timeout.

select_local=true

If no target_selections are specified, select the local host (if the level is host, global_soc_template or global_product_template), the target directory "/" on the local host (if the level is root), or the default distribution_target_directory of the local host (if the level is depot, product or product_template) as the target_selection for the command.

software=

Defines the default of software_selections. There is no supplied default.

targets=

Defines the default target_selections. There is no supplied default (see select_local above). If there is more than target selection, they must be separated by spaces.

EXTERNAL EFFECTS

stdout

The swacl command prints ACL information to stdout when the user requests an ACL listing.

stderr

The swacl command writes events with a status of SW_WARNING or SW_ERROR to stderr.

logging

The swacl command does not log summary events. The daemon managing the ACLs logs events about each ACL which is modified, as well as any events associated with looking up an ACL, to the daemon logfile on each target host.

EXTENDED DESCRIPTION

The swacl utility contacts the daemon on the host targets specified. This is done using the DCE Security Service interfaces which interact indirectly with the RDACL interfaces served by the daemon.

In order to lookup an ACL or ACL entry, the full ACL is retrieved from the daemon. In order to replace a full ACL with the -F option, the new ACL is sent. In order to modify (change or add) and ACL entry, the full ACL is retrieved, the ACL is modified, then the full ACL is replaced.

When modifying a product ACL specified by a software_selection, the target distribution containing the product is opened as is done for other POSIX 1387.2 standard commands. The software_selections are then resolved against the distribution. Any problems resolving the software_selection generate the same events as other POSIX 1387.2 standard management commands:

EXIT VALUES

The swacl command returns:

0
The software_selections and/or target_selections were successfully displayed or modified.

1
The display or modify operation failed on all target_selections.

2
The display or modify operation failed on some target_selections.

CONSEQUENCES OF ERRORS

If there are any errors, then the display or modification of ACLs fails.

DCE Security Service RPC use for XDSA-DCE

XDSA-DCE implements the distributed interface to ACL management by:

DCE Security Service RPC Server Interfaces

When implementing an ACL manager, the program needs to implement the entire RDACL interface.

The definition of each of these calls can be found in DCE Security Service documentation.

void rdacl_lookup(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	uuid_t *manager_type,
	[in]	sec_acl_type_t sec_acl_type,
	[out]	error_status_t *st
);

void rdacl_replace(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	uuid_t *manager_type,
	[in]	sec_acl_type_t sec_acl_type,
	[in]	sec_acl_list_t *sec_acl_list,
	[out]	error_status_t *st
);

boolean32 rdacl_test_access(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	uuid_t *manager_type,
	[in]	sec_acl_permset_t desired_permset,
	[out]	error_status_t *st
);

boolean32 rdacl_test_access_on_behalf(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	uuid_t *manager_type,
	[in]	sec_id_pac_t *subject,
	[in]	sec_acl_permset_t desired_permset,
	[out]	error_status_t *st
);

void rdacl_get_manager_types(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	sec_acl_type_t sec_acl_type,
	[in]	unsigned32 size_avail,
	[out]	unsigned32 *size_used,
	[out]	unsigned32 *num_types,
	[out]	uuid_t manager_types[],
	[out]	error_status_t *st
);

void rdacl_get_mgr_types_semantics(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	sec_acl_type_t sec_acl_type,
	[in]	unsigned32 size_avail,
	[out]	unsigned32 *size_used,
	[out]	unsigned32 *num_types,
	[out]	uuid_t manager_types[],
	[out]	sec_acl_posix_semantics_t posix_semantics[],
	[out]	error_status_t *st
);

void rdacl_get_printstring(
	[in]	handle_t h,
	[in]	uuid_t *manager_type,
	[in]	unsigned32 size_avail,
	[out]	uuid_t *manager_type_chain,
	[out]	sec_acl_printstring_t *manager_info,
	[out]	boolean32 *tokenize,
	[out]	unsigned32 *total_num_printstrings,
	[out]	unsigned32 *size_used,
	[out]	sec_acl_printstring_t printstrings[],
	[out]	error_status_t *st
);

void rdacl_get_referral(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	uuid_t *manager_type,
	[in]	sec_acl_type_t sec_acl_type,
	[out]	sec_acl_tower_set_t *towers,
	[out]	error_status_t *st
);

void rdacl_get_access(
	[in]	handle_t h,
	[in]	sec_acl_component_name_t component_name,
	[in]	uuid_t *manager_type,
	[out]	sec_acl_permset_t *net_rights,
	[out]	error_status_t *st
);

DCE Security Service RPC Client Interfaces

The "manager swacl" uses DCE client Security Service interfaces which in turn call the RDACL server interfaces.

The definition of each of these calls can be found in DCE Security Service documentation.

void sec_acl_bind_to_addr(
	[in]	idl_char *site_addr,
	[in]	sec_acl_component_name_t component_name,
	[out]	sec_acl_handle_t *h,
	[out]	error_status_t *status
);

void sec_acl_get_manager_types(
	[in]	sec_acl_handle_t h,
	[in]	sec_acl_type_t sec_acl_type,
	[in]	unsigned32 size_avail,
	[out]	unsigned32 *size_used,
	[out]	unsigned32 *num_types,
	[out]	uuid_t manager_types[],
	[out]	error_status_t *st
);

void sec_acl_lookup(
	[in]	sec_acl_handle_t h,
	[in]	uuid_t *manager_type,
	[in]	sec_acl_type_t sec_acl_type,
	[out]	sec_acl_list_t *sec_acl_list,
	[out]	error_status_t *st
);

void sec_acl_replace(
	[in]	sec_acl_handle_t h,
	[in]	uuid_t *manager_type,
	[in]	sec_acl_type_t sec_acl_type,
	[in]	sec_acl_list_t *sec_acl_list,
	[out]	error_status_t *st
);

DCE Security Service RPC Type Values

This section lists the supported values for parameters of the client and server RPC calls.
Component Naming
The component_name (with type sec_acl_component_name_t) identifies the name of the target object with which an ACL is associated. If the authentication_service option is set to dce-secret, the component name uses the following syntax:

_key

The acl_key is a string representing the type of object the acl is associated with, and if needed, a installed software collection or distribution path and a software specification of a product. The following defines are used:

SW_SEC_HOST		host
SW_SEC_ROOT		root
SW_SEC_DEPOT	depot
SW_SEC_PRODUCT	product

The acl_key is constructed as follows, depending on the level of the ACL specified by the -l option to swacl:

host				SW_SEC_HOST
global_soc_template		SW_SEC_HOST
global_product_template		SW_SEC_HOST
root				SW_SEC_ROOT ':' root_path [ ':' root_catalog ]
depot				SW_SEC_DEPOT ':' depot_path
product_template		SW_SEC_DEPOT ':' depot_path
product				SW_SEC_PRODUCT ':' depot_path ':' product_catalog

The root_path variable is the pathname to the installed software collection. The depot_path is the pathname to the distribution. The root_catalog is the added if an installed_software_catalog option was set to a value other than the default. The product_catalog is the control_directory attribute of the product.

If the authentication_service option is set to internal, the acl_key in component name is preceded by the principal and internal secret information needed to authenticate the user before accessing the ACL. This information is provide in this manner because the DCE Security Service interfaces do not provide a way (such as options for the XDSA-DCE interface) to pass this additional information:

username.groupname[.othergroups]@realm;encrypted_secret,acl_key

The username is the name of the user. The groupname is the current primary group of the user. The othergroups is a dot-separated (".") list of secondary groups the user belongs to. The realm is the NIS domain name, internet name, or network address of the manager. The encrypted_secret is a concatenation of the 2-character salt used by the manager to encrypt its secret and the encrypted secret itself. The manager and daemon encrypt using crypt(3), and the daemon uses the salt provided in the first two characters of the encrypted_secret.

ACL Types
The sec_acl_type parameter (with type of sec_acl_type_t) also depends on the level of the ACL specified with the -l option to swacl. The values are DCE type values:

host				sec_acl_type_object
root				sec_acl_type_object
depot				sec_acl_type_object
product				sec_acl_type_object
product_template		sec_acl_type_default_object
global_soc_template		sec_acl_type_default_container
global_product_template		sec_acl_type_default_object

Additionally, for use with lookup, the owner of the object is designated by the DCE type value:

owner		sec_acl_type_unspecified_3

ACL Permissions
The supported ACL permissions for the perms member (of type sec_acl_permset_t) of the sec_acl_entries array include the XDSA-DCE permissions and the corresponding DCE type values:

r(ead)		sec_acl_perm_read
w(rite)		sec_acl_perm_write
i(nsert)		sec_acl_perm_insert
t(est)		sec_acl_perm_test
c(ontrol)	sec_acl_perm_control
ACL Entry Types
The supported ACL entry types for the entry_type member (of type sec_acl_entry_type_t) of the entry_info member of the all_entries array include the XDSA-DCE entry types and the corresponding DCE type values:

object_owner	sec_acl_e_type_user_obj
object_group	sec_acl_e_type_group_obj
user		sec_acl_e_type_user
group		sec_acl_e_type_group
other		sec_acl_e_type_other
user:@realm	sec_acl_e_type_foreign_user
group:@realm	sec_acl_e_type_foreign_group
other:@realm	sec_acl_e_type_foreign_other
host		sec_acl_e_type_user
any_other	sec_acl_e_type_any_other

Contents Next section Index