|
|
The security policy of UnixWare prescribes a relationship between access rules and access attributes. The access attributes allow the system to define several distinct levels of authorization, and the access rules provide the mechanism for the system to prevent unauthorized access to sensitive information.
Access to a file is determined by the file's absolute pathname. The kernel determines whether or not to allow a process the kind of file access requested (read, write, execute/search) based on
For example, if the file
/usr/src/cmd/mv.c
is readable by a user,
but the directory
/usr/src/cmd
(or any other directory in the path)
is not searchable by the user
(that is, the user does not have
search permission on
/usr/src/cmd),
then
mv.c
cannot be read.
The system enforces access control by means of the Discretionary Access Control (DAC) mechanism.
Users on a computer system typically share commands, programs, library routines, and files. For example, all users need to share the user-level commands in the operating system, such as ls, cp, ed, and so on. Also, users in the same group or in related groups often may want to share some of the same data or text files. Object sharing introduces some potential security violations. To maintain security, the security policy requires that the system oversee object sharing in a known and controlled manner.
DAC provides for the controlled sharing of objects among subjects. DAC is part of the ``who can access what'' mechanism. With DAC, the owner of an object can choose to grant access permissions to other users; that is, the segregation of information and the prevention of unauthorized access to information is set according to the discretion of the owner of the information.
Two complementary DAC mechanisms are available:
The UnixWare file permission modes are retained from previous releases of UnixWare for compatibility. Administrators already familiar with UnixWare file permissions will find that this mechanism still works as expected. For more information on file permission modes, see ``Understanding file protection''.
ACLs are designed to satisfy B2-level US government security requirements and to be compatible with the UnixWare file permission modes.
A given combination of permission mode bits on a file is directly translated into a basic ACL for that file; it provides identical protection. The ACL on a file can be displayed by invoking the getacl command. The owner of the file can add more users and groups to the basic ACL by invoking the setacl command. Refer to getacl(1) and setacl(1) for more information concerning these commands.
The ACL concept supports finer control than file permissions alone by providing the ability for the owner of an object to grant or deny access by other users to the granularity of a single user. All DAC information may be changed in one atomic operation with the setacl command, avoiding the possibility of an intermediate insecure state.
UnixWare's ACLs also allow specification
of access rights to members
of groups as defined to the system
in the administrative file
/etc/group.
ACLs can be arbitrarily large; that is,
the number of ACL entries
is not limited by the system.
The system administrator
can set the maximum number of entries
per ACL by setting a tunable parameter.
(Naturally, as ACLs get larger,
processing gets slower,
which induces a practical limit on
the number of ACL entries.)
ACLs are associated with each filesystem object on a Secure File System (sfs) or Veritas File System (vxfs) and IPC object. ACLs for filesystem objects are stored in the associated inode. ACLs for IPC objects are stored in an internal structure associated with the instantiation of the IPC object.
The commands that a user can invoke to manipulate and read DAC permissions are
The system calls that a program can invoke to manipulate and read DAC permissions are The library function for reading and sorting ACL information is