Path: utzoo!attcan!uunet!longway!std-unix From: std-unix@longway.TIC.COM (Moderator, John S. Quarterman) Newsgroups: comp.std.unix Subject: Standards Update Part 5: 1003.6 Message-ID: <338@longway.TIC.COM> Date: 11 May 89 15:39:41 GMT Reply-To: std-unix@uunet.uu.net Lines: 159 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) Standards Update Part 5: 1003.6 An update on UNIX|= Standards Activities January 1989 IEEE 1003 Meeting, Ft. Lauderdale Part 5: 1003.6 Shane P. McCarron, NAPS International 1003.6 - Security Extensions to POSIX The security working group is currently working on a number of topics in parallel - Autiding, Discretionary Access Controls (DAC), Mandatory Access Controls (MAC), and Privileges. As these topics have been described in detail in previous installments, I won't do it again. Instead, here is a brief summary of topics of interest being discussed in those sub-committees: MACs The group decided to accept one proposal before them as a baseline. This will help them to decided on their exact scope of operation and also to decide on their goals. This baseline proposal has not solved even a small percentage of the problems facing this committee. Things like information label mechanisms, data transport, text label format, label constraints, and security for public/shared directories were too abstract at this time, the group decided to ask for white papers to talk about them at the April meeting. AUDIT This group has embraced a proposal as a base. This proposal, in conjunction with a proposal from X/Open, will probably be the primary source in this area. DAC This group was finally able to resolve some of the issues that have been in dispute since its creation. In particular, the group was able to agree on: The representation of an Access Control List (ACL), Ordering, Default ACLs, and most importantly the issue of how ACLs are to be used in the system. ACLs will be an additional security mechanism, which much be enabled by explicit user __________ |= UNIX is a registered trademark of AT&T in the U.S. and other countries. January 1989 - 1 - Ft. Lauderdale Standards Update Part 5: 1003.6 action. This satisfies the requirements of the 1003.1 standard, which had left room for just such a mechanism by leaving some weasel-wording in the definition of File Group Class. The specific mechanism will be that the permissions available to users (or groups) listed in an ACL will be a subset of those availabe using the traditional group permissions of the file. In addition, the inheritance of ACLs was discussed. It appears as if the group will agree that the ACL for a directory will propogate to any sub-directories that are created. However, this is still an issue and will be debated at the April meeting. In addition, the group agreed that there will be routines in the standard for manipulating each type of ACL, and that named or shared ACLs will not be in the standard. PRIVILEGES: The principle of least privileges requires that each subject in a system be granted the most restrictive set of privileges needed for performance of authorized tasks. The principle of Least Privilege will also include the concept that each privilege is available for the minimum scope of execution required to perform the task for which it is needed. The purpose of privileges is to assure the authorized and restricted use of a service. Security relevant code can be bracketed and the privileges may be enabled only during execution of that part of a program. Issues that need to be addressed by this group include: 1. To what degree can privileges be segmented to allow control over individual privileged actions? 2. How can a designer of a privilege propagation mechanism assure compliance with the principle of least privilege? 3. How can user access to privileged operations be limited in accordance with the principle of least privilege? 4. What control interfaces are necessary to allow privilege mechanism? The group has agreed that no privilege should grant access to more than a single set of related operations. The group January 1989 - 2 - Ft. Lauderdale Standards Update Part 5: 1003.6 also agreed that the propogation of a privilege from one "subject" (process) to another should be strictly controlled. Because traditional implementations propogate priviliege based on the effective user ID of a process, any secure implementation will have to permit this behavior. However, to permit for more secure software being developed in the future, it is necessary to provide some primitives that will permit a parent process to restrict which privileges are progated to its children. The standard will be defining a set of interfaces for accessing privileged operations. These interfaces will allow for: Reducing the level of privileges, setting, creating, or adding privileges, acquiring privineges, testing for privileges, requesting a privilege type, setting privilege propogation, requesting a set of maximal privileges, determining the set of privileges currently enabled, determining the success or failure of privilege accumulation, and creating of privileges not in the current set. The scope of this committee is to define extensions to the POSIX interface which support a privilege mechanism capable of enforcing a 'Least Privilege' security policy, and a minimum set of privileges which are necessary to support such a policy in a portable applications environment. The Usenix Standards Watchdog Committee contact for this group is Anna Maria de Alvare. She can be reached at: Anna Maria de Alvare Lawrence Livermore National Laboratories PO Box 808 L-303 Livermore, CA 94450 +1 (415) 422-7007 annamaria@lll-lcc.llnl.gov uunet!lll-lcc.llnl.gov!annamaria January 1989 - 3 - Ft. Lauderdale Volume-Number: Volume 16, Number 36