Minutes of the POSIX 1003.6 meeting, Irvine, California, 19-23 April 1993 Plenary session - Monday 19th April 1993 Jon Spencer, Data General, acting chair. Sederunt Attendance list circulated for update. Secretary David Ferbrache, appointed as temporary working group secretary Agenda Agenda noted and approved. Mon 9.00-10.30 Discussion of new interface subgroups 10.30-11.30 Formation of new subgroups 13.00 - 14.00 Discussion of liaison issues 14.00 - 14.30 Selection of liaisons Tue 9.00 - 17.00 Subgroups meet 13.30 Election Wed 9.00 - Ballot resolution group report - 17.00 Subgroups meet Thu 9.00 - 17.00 Liaisons liaise to subgroups, subgroups meet Fri 9.00 - 10.00 Ballot resolution group, subgroups 10.00 - 11.30 Subgroups report in plenary session 13.00 - 17.00 Ballot resolution groups, subgroups Believed that standardisation of new areas of interface should be undertaken. Awaiting Denver meeting to establish stable participation before cutting PAR for meeting. Liaison, have prepared list of groups on which security representation is required. Volunteers requested. A couple of liaisons to be selected to ensure regular attendance. Objections received by ballot resolution group require wider discussion in 1003.6 forum and will be addressed in plenary session on Wednesday morning. Agreed to establish two email lists - a US list to be held by Shane Deitchman - NOSC, and a European expander to be held by David Ferbrache - DRA. This list will serve as a general 1003.6 list and will initially carry traffic from subgroups. Noted that 1003.22 has an existing email expander "dssg@perch.nosc.mil". New interface areas Following discussion at the New Orleans meeting, a number of possible areas of new standards activity have been identified to augment existing 1003.6 standards effort. These areas of work are summarised below: * Administrative services 1003.7 have requested input (general) on their current work program. A number of categories of management and administrative functions were identified some of which were specific to objects introduced as a result of 1003.6 extensions, others of which concerned identification of security relevant actions during administrative functions. Password management Backup restore Audit Privilege/authorisations MAC Info labels Label management Process management Job control management Resource management Login management Terminal management I&A management Config. management ACL management Role management * Identification/authentication Standardisation of user and entity identification and authentication mechanisms, distributed authentication mechanisms, and the introduction of generic I&A interfaces suitable for biometrics. * Network services A number of distributed and networked security service APIs were noted, although the selection of API form and structure will be influenced by the security framework under development in the 1003.22 forum. Security extensions for distributed systems Secure RPC Authorisation/access control Distributed management Distributed audit Distributed I&A * Cryptographic Development of generic crypto interfaces providing facilities in a number of areas including: encryption, digital signature and integrity. * Portable data formats Standardisation of portable representation formats for ACLs, labels, privileges, audit trail information and backup/restore information. * Liaison P1003X A general liaison role with other POSIX working groups to ensure that standards in development address security requirements and 1003.6 extensions, to raise the level of awareness of security issues and ensure the availability of security expertise if required by other working groups. Noted that considerable overlap and co-ordination will be required between subgroups. A discussion was held regarding the target level of assurance and trust levels for new areas of standards activity, and whether interfaces should be aligned to a Federal standard. It was noted that 1003.6 targeted generic systems rather than a specific functionality class. The security framework should be used as the basis for the definition of network services APIs, and that 1003.22 will be identifying categories of security facilities for which API's should be defined. This will serve to clarify the requirement for network security API standardisation. Agreed to defer work in this area until 1003.22's architecture/framework work has advanced. Issue of export/import controls on cryptographic algorithms and interfaces was raised with concern being noted by X/Open on the current constraints on export/import of products containing generic crypto interfaces which might permit retrofit of crypto-algorithms. The working group considered that standards effort in this area is of importance, although legal issues should be tracked. The working group has temporarily suspended conformance testing effort to permit new activity to commence in the POSIX 1003.6 forum. The status of LIS is under review by the SEC. A question was raised as to the continued level of commitment from new members. The significant duplication of effort in the distributed security arena was noted with concern, as was the delays inherent in achieving consensus international standardisation of security functionality. The relative merits of reference implementations early in standards development vs additional effort on generation of mature standards prior to industry implementation were discussed. Noted that POSIX aims to generate mature standards capable of achieving wide industry backing, and does normally generate reference implementations as a means to evolve standards. Agreed that all members of 1003.6 will indicate area of standardisation effort being undertaken by other bodies which relates to proposed 1003.6 work topics. The chair to seek to maintain liaison with other standards bodies to minimise duplication of effort. In approving POSIX 1003.22 PAR it has been requested that we work with NUIF and OIW (Open systems implementers security workshop) security standardisation effort. NIST indicated interest in the cryptographic subgroup standards effort. Jon encouraged move to inter-national standardisation through tracking and establishment of links with European activities including the European workshop on open systems security (EWOS). It was felt that the diversion of effort towards the ballot resolution group over the last 1.5 years has led to stagnation of 1003.6 core work other than the DSSG. Noted that significant changes in the ballotable material continue to occur as a result of comments submitted. It is impossible to introduce new material into the 1003.6 document in ballot, and thus new work topics may generate new project authorisation requests (PARs) leading to new ballotable documents. POSIX 1003.22 Distributed security study group report David Rogers reported on the status of the DSSG which has now had its PAR formally approved, and thus becomes POSIX 1003.22, security framework working group. The slides used in this presentation are attached as Appendix 2. The work on security domain definitions has been presented to the OSF security SIG in Paris and was believed to have been well received. X/Open are already working with 1003.22 in order to contribute to the X/DSF document. Agreed to circulate the latest draft of the guide to security framework document to 1003.6 in the next mailing. The current paper is an evolution of 3 sections of the original "white paper". Action request that .6 members be added to .22 mailing list, and that Jon Spencer be added to the .22 electronic mail list. Ballot resolution group status report. 1003.6 proceeded to second ballot in November and was originally planned to close in February. The ballot remained open until a 75% response had been received and formally closed on March 24th. There are 238 people on ballot list, and a total of 275 on IEEE mailing list. Unofficial responses continue to be considered during the balloting process. 183 votes (76.9% response) 54 abstentions (29.5%) 56 vote negative, 73 affirmative (56.6% affirmative vote of non-abstentions) Once a 75% affirmative vote (excluding abstentions) is received it becomes possible to send the document for recirculation rather than re-ballot. In a recirculation only changed sections may be commented upon. Only those voting in initial ballot may vote on recirculation. If still 75% affirmative on recirculation then the standard may proceed to next stage of approval. All non-accepted objections must be published as preface to recirculated document, and must be sent to IEEE standards board for comment. The document is now in 2nd ballot, closing late 1993. A further reballot may be required, although recirculation is preferred. The total number of received comments and objections are summarised below: Objections Comments Total General 258 125 383 .1 & .2 197 92 289 Acl 342 257 599 Audit 173 156 329 Labels 134 66 200 Mac 162 93 255 Privileges 225 228 453 TOTAL 1491 1017 2508 Noted that a total of 3291 objections and comments were received on draft 12. The status of unresolved objections on draft 13 compared with the final outcome of resolution of comments / objections on draft 12 was noted: Draft 13 Draft 12 Accepted 511 1660 Accepted with change 125 1046 Rejected 169 551 Withdrawn 6 21 Child 43 - Distributed 2 13 Open 1652 - TOTALS 2508 3291 Noted that the ballot resolution group has met once in February in Gaithersburg, and will be continuing to meet during the Irvine meeting. While fewer objections have been submitted to draft 13, it is noted that a number of objections raise significant resolution difficulties which require wider discussion in plenary session including the removal of the ACL mask and multi-level directory facilities from the standard. Consistency comments relating to function names and data structures have now been addressed. Noted that Mike Ressler intends to step down as technical editor shortly. Nominations for the post of technical editor are elicited. It was noted that if necessary the role of technical editor, and chair of the ballot resolution group could be separated to minimise workload. Liaison activities The following liaison members from 1003.6 to the undermentioned working groups were appointed. It has since been noted that 1224 has completed IEEE balloting, and security extensions to X.400/X.500 APIs will therefore require initiation of separate effort. 1003.0 Dave Rogers 1003.2 Jeremy Epstein 1003.4 Roland Buresund 1003.7 Roger Myers 1003.14 Roland Buresund 1224 David Ferbrache Subgroup establishment The working group reviewed the areas of interest of attendees in establishing sub-groups to address a range of new work area, these are summarised below: Identification and authentication 4 Network services 2 Cryptography 3 Distributed security (1003.22) 9 Administration 2 Threads 1 Portable data formats 1 Agreed to set up subgroups to investigate I&A, generic cryptographic interfaces, administrative interfaces and portable data formats. 1003.22 provides a core architecture and framework giving a strategy for 1003.6 effort. Subgroups may however investigate API definition for particular functional areas within this framework. A focal point was designated for each unit of work, the interests of members in serving on each subgroup was noted, namely: Cryptographic interfaces Shu-jen Chang Bob Elander Administration Lynne Ambuel Jon Spencer Nina Lewis I&A Piers McMahon John Donlin Nitin Mehrotra Cliff Neuman Martin Bailey Portable data formats Casey Schaufler Bill Smith Roland Buresund Security framework(.22) David Rogers Lee Terrell David Ferbrache Roland Clouse In addition, a number of members are allocated to ballot resolution duties under the chairmanship of the technical editor (Mike Ressler), they are: Ballot resolution group Mike Ressler Lynne Ambuel General Jeremy Epstein .1/.2 Larry Parker DAC Daniel Ujihara DAC Jon Spencer Privilege John Griffiths Privilege Jeff Picciotto IL Kevin Brady Audit Chris Hughes Audit Roland Clouse MAC Plenary session - Tuesday 20th April 1993 Subgroup initial reports Subgroups reported back to a plenary session on Tuesday 20th on proposed workplans and initial strategy prior to the Denver meeting. These are: * Systems administration - An initial move will be made towards the definition of managed attributes and objects by July. Noted that this work will involve close liaison with 1003.7, this group has selected two differing models of interface specification - one of which is specific to the work on print management. The DSSC chair has been consulted on the requirement to address name space management. It was noted that this issue may have fallen within the scope of the X.500 API definition working group. * Identification and authentication - This subgroup met briefly after a joint session with 1003.22. Agreed that human authentication, mutual authentication interfaces (GSS API), associated management interfaces, user and password management interfaces fall within scope. Agreed that the subgroup will define a list of services which should be addressed by the next meeting. Agreed that the subgroup will review existing practice and will select targets for standardisation of I&A interfaces based on the doctrine of developing a policy neutral and mechanisms independent interface. * Portable data formats - Minimal work to date. Noted that initial research work is required prior to definition of subgroup scope. The need for portable audit trail formats and potential contribution from audit translation work supporting automated intrusion detection systems was noted. This may prove a useful source of existing practice. * Cryptographic interfaces - The subgroup proposed two levels of standardisation based around a set of high level interface calls supporting interfaces such as automated keying from smart card, and a set of lower level direct crypto interfaces for symmetric and asymmetric crypto. The subgroup is examining the proposed NIST generic crypto interface as a base document. Noted that consideration of the IBM common crypto architecture, ICL and SESAME crypto interfaces , X9.17, digital signature standard, ISO 9796, and RSA public key standard may be useful. NIST intend to progress their generic crypto interface to guideline FIPS by September 1993. It was proposed that liaison links be established with ISO SC27, and that the subgroup review the work of the CEC ITAG V on crypto interface APIs. The issue of standardisation of proprietary crypto algorithms was discussed. Shu-Jen noted that NIST has carried out development work on high- level crypto interfaces for the US Army corps of engineers. She will investigate whether the results of this work may be released into POSIX. Election for working group chair The chair passed to Jim Isaac, chair of PASC. Nominations were requested for the post of working group chair, two candidates were proposed: Jon Spencer, Data General Lynne Ambuel, US Department of defence The candidates were asked to leave the room. Jim Isaac detailed the responsibilities and required personal qualities of a chair. A discussion was held on the merits of the candidates. The working group then held an election by secret ballot. Lynne Ambuel was elected to the post of working group chair. Agreed that Lynne will be permitted to nominate vice-chair and secretary for 1003.6. Noted that it may be advantageous to nominate two co- vice-chairs to encompass the 1003.22 activity. Requested that Lynne Ambuel become the formal point of contact for the 1003.22 PAR. Plenary session - Wednesday 21st April Lynne Ambuel, DoD, Chair. Ballot group working meeting Technical review group considered that 3 topics are worth referring to the main working group for review and discussion. The issues are the multi-level directory, ACL mask and privilege granularity. Multi-level directories There were 7 specific and well argued objections to multi-level directory APIs in draft 12, it was therefore decided to delete the MLD APIs from draft 13. Objections were targeted at removal rather than modification of the APIs, and identified a primary usage as being administrative tools which is outside the current scope of 1003.6. Noted that porting applications onto MLS systems may require the functionality of multi-level directories. The requirement for exercise of privilege to create and access multi-level directories is contentious. Noted that a number of existing and divergent interfaces existed. Proposed interfaces were parallels to opendir and readdir to permit scanning of all entries for which the MAC label is dominated by the current process MAC label. A modified open permits specification of the MAC label of the target file as a discriminator. Sufficient contention exists to prohibit standardisation of this interface, although it was noted that the ACL standardisation permitted selection of a preferred interface from a number of industry alternatives. First ballot led to 7 objections for deletion of MLD, with a number of additional comments on interface specifics. Second ballot led to 3 objections against their removal. Are multi-level directories purely implemented to prevent covert channel signalling via name space collision? The need for mutli-level directory to support applications with threads of execution at a range of MAC labels was identified, such as the use of cron with schedulers at various classifications. The possibility of implementing a directory which is a wildcard to permit write at any MAC label as an alternative to MLD was discussed. Agreed that the working group will conduct a straw poll on the inclusion of multi-level directories which will be advisory on the ballot resolution group. Straw poll on whether 1003.6 will reinstate D12 text on MLD into Draft 14: For: 5 Against: 11 Abstentions: 5 The working group therefore advises that MLDs be excluded from future versions of the standard. ACL mask An overview of the ACL concept was provided noting the forms of ACL field entry, the concept of default minimum ACL, and the possible extensions to incorporate alternate access modes. In draft 12 a MASK_OBJ is required in all non-minimal ACLs. The mask was automatically introduced when an additional group or user entry is introduced. Permissions displayed by "ls" are those of the mask entry rather than the group entry with a non-minimal ACL. The intent of the mask is to specify the maximum permission for additional entries excluding the owning user and other entries, and thus provides compatibility with the uses of "chmod" to limit access. Draft 13 ACL excluded the mask ACL, thus correspondence to ACL entries is constant. This infers that a "chmod 0" will not clear permissions for additional ACL entries for named users and groups. The mask acts to support file locking and provide a degree of compatibility with applications using previous DAC models. Draft 12 comments noted that the mask is not fully compatible with the semantics of the 1003.1 chmod; that the display of mask in preference to group is counter-intuitive; that recalculation of the mask is complex as is the setacl utility and access check algorithm. Draft 13 comments noted that mode bits do not specify maximum permission, incompatibility with existing applications, silent failure of chmod to correctly operate, and the significance of the change proposed. Results of Draft 12 ballot objections: Completely remove the mask 3 people Complexity: change of mapping 7 people general complexity 2 people setacl/recalculation 3 people Obviously misunderstood 2 people Results of Draft 13 ballot objections: Put the mask back 6 people + 3 reference ballots Compatibility but did not suggest mask 6 people + 1 reference ballot Complained about compatibility but 1 person fenced concerning solution There are two groups of customers who must be addressed, those who are ACL aware and wish the functionality of ACLs; and those who aim for application compatibility using the previous UNIX access control model. The move towards graphical user interfaces to control file system permissions was noted, with reduced dependence on "chmod" system call and utility routines. A limited number of applications attempt to utilise chmod to perform mode changes on files with extended ACLs. The getacl and setacl commands provide the preferred means of manipulating the access control rights of files with extended ACLs. Applications designed for standard POSIX without the POSIX 1003.6 acl extension will potentially utilise chmod, and when executed on systems with 1003.6 ACLs the program may attempt a chmod over files with ACLs. Considered that compatibility with previous applications may be of great importance, and that such applications should interact with extended ACLs in a secure manner. Problems associated with previous implementations of the mask should be addressed to ensure that the system operates in a secure manner, with minimal complexity of functionality. Straw poll to return Draft 12 ACL mask mechanism to Draft 14: For: 11 Against: 3 Abstentions: 9 Based on the results of the above poll, the ballot resolution group will return the mask mechanism to the draft and will continue in its efforts to minimise the complexity of the ACL mask implementation consistent with the maintenance of system security and previous application compatibility. Privilege granularity The current 1003.6 privilege model was outlined. The issue of mapping of POSIX privileges to implementation defined privileges was discussed. In particular three scenarios were considered: 1. The implementation uses a finer grained privilege mechanism. A single POSIX privilege must therefore be mapped into two or more implementation privileges. A process operating with a coarse grained privilege is therefore using excess privilege to conduct its operation, furthermore the reverse mapping from current fine grained privileges to POSIX privilege may be problematic, and may also grant excess privilege. 2. The implementation uses a coarse grained privilege mechanism. A number of POSIX processes map into a single implementation privilege. Acquisition of a POSIX privilege may therefore infer the acquisition of a wide range of rights in excess of those required to carry out the task. In particular operation with excess privilege violates not only the least privilege security doctrine, but may violates process assumptions concerning the operation of DAC and MAC access constraints on system objects. 3. The implementation has addition privileges which are not addressed in the POSIX privilege model, such as alternate integrity access control policies and associated bypass privileges. Such privileges may permit bypassing of POSIX security interfaces. The coarseness of privileges implemented by a system claiming POSIX conformance was discussed. In particular the reductive case of a system implementing all POSIX privileges as a single "root" privilege was reviewed. At a number of locations in the privilege section of 1003.6 there is a requirement for a series of wording changes to reflect that a required POSIX privilege may be mapped to one or more implementational privileges. It was suggested that an application might ascertain the names of the required implementation specific privileges required to carry out an operation at installation or runtime. The required implementation privileges may then be turned on by via a privilege API. Straw poll: should we remove named POSIX privileges from POSIX 1003.6 For: 0 Against: 14 Abstentions: 5 Straw poll: should the document require that a vendor has an exact 1-1 mapping between POSIX and implementational privileges, i.e. may a vendor may not implement finer or coarser grained privileges: For: 3 Against: 16 Abstentions: 4 Straw poll: should POSIX 1003.6 define particular permissible forms of privilege mapping (eg possible exclusion of mapping to coarser implementation privileges): For: 6 Against: 9 Abstentions: 9 In summary, MLD continue to be excluded; ACL mask will be reintroduced; privilege mapping will be supported and the document shall not restrict whether such mappings are to coarser or finer granularity. The POSIX privilege subgroup requested input on the forms, and implications, of permissible privilege mappings. Document register, April 1993 Attachments to minutes Appendix 1: Attendance list Appendix 2: Presentation by David Rogers on work of 1003.22 Working documents 4/93 01 Agenda for Irvine meeting, proposed subgroups and liaison activities J.Spencer 4/93 02 Coverage of new subgroups L.Ambuel 4/93 03 Attendance list, Irvine D.Ferbrache 4/93 04 Presentation slides on security framework (1003.22) D.Rogers 4/93 05 MoD Technology demonstrator program - generic security archit. P.McMahon 4/93 06 Security framework - submission for security domain definitions D.Rogers 4/93 07 NIST generic cryptographic interface S.Chang Page 8