Filter
Top Products
Objects are passive repositories of data. The TOE defines three types of objects: named objects, storage
objects, and public objects. Named objects are resources, such as files and IPC objects, which can be
manipulated by multiple users using a naming convention defined at the TSF interface. A storage object is an
object that supports both read and write access by multiple non-trusted subjects. Consistent with these
definitions, all named objects are also categorized as storage objects, but not all storage objects are named
objects. A public object is an object that can be publicly read by non-trusted subjects and can be written only
by trusted subjects.
SLES enforces a DAC policy for all named objects under its control, and an object reuse policy for all storage
objects under its control. Additional access control checks are possible, if an optional kernel module is
loaded, such as AppArmor. If AppArmor is loaded, DAC policy is enforced first, and the additional access
control checks are made only if DAC would allow the access. The additional checks are non-authoritative;
that is, a DAC policy denial cannot be overridden by the additional access control checks in the kernel
module.
While the DAC policy that is enforced varies among different object classes, in all cases it is based on user
identity and on group membership associated with the user identity. To allow for enforcement of the DAC
policy, all users must be identified, and their identities must be authenticated. The TOE uses both hardware
and software protection mechanisms.
The hardware mechanisms used by SLES to provide a protected domain for its own execution include a
multistate processor, memory segment protection, and memory page protection. The TOE software relies on
these hardware mechanisms to implement TSF isolation, non-circumventability, and process address-space
separation.
A user can log in at the console, at other directly attached terminals, or through a network connection.
Authentication is based on a password entered by the user and authentication data stored in a protected file.
Users must log in to a host before they can access any named objects on that host. Some services, such as
ssh to obtain a shell prompt on another host, or ftp to transfer files between hosts in the distributed system,
require the user to re-enter authentication data to the remote host. SLES permits the user to change passwords
(subject to TOE enforced password guidelines), change identity, submit batch jobs for deferred execution, and
log out of the system. The Strength of Function Analysis [VA] shows that the probability of guessing a
password is sufficiently low given the minimum password length and maximum password lifetime.
The system architecture provides TSF self-protection and process isolation mechanisms.
2.2.5 Operation and administration
The eServer networks can be composed of one, several, or many different host computers, each of which can
be in various states of operation, such as being shut down, initializing, being in single-user mode, or online in
a secure state. Thus, administration involves the configuration of multiple computers and the interactions of
those computers, as well as the administration of users, groups, files, printers, and other resources for each
eServer system.
The TOE provides the useradd, usermod, and userdel commands to add, modify, and delete a user
account. It provides the groupadd, groupmod, and groupdel commands to add, modify, and delete a
group from the system. These commands accept options to set up or modify various parameters for accounts
and groups. The commands modify the appropriate TSF databases and provide a safer way than manual
editing to update authentication databases. Refer to the appropriate command man pages for detailed
information about how to set up and maintain users and groups.
2.2.6 TSF interfaces
The TSF interfaces include local interfaces provided by each host computer, and the network client-server
interfaces provided by pairs of host computers.
8