home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: stephe@mks.com (Stephen Walli)
-
- USENIX Standards Watchdog Committee
- Stephen R. Walli <stephe@usenix.org>, Report Editor
-
-
- POSIX.6: Security Extensions
-
- Charisse Castagnoli <charisse@sware.com> reports on the
- January 13-17, 1992 meeting in Irvine, CA:
-
- Summary of the POSIX meeting in Irvine
-
- This was the first meeting of the POSIX.6 group since the
- ballot closed on January 6, 1992. Of the 232 official
- ballot members, 181 members responded. The response equals
- 78 %of the ballot pool. (A minimum of 75% response is
- required by IEEE for a ballot to be considered valid.)
-
- The 181 returned ballots were divided as follows:
-
- Affirmative Negative Abstain
- 69 61 51
- 53% 47% <don't count>
-
- In order for a ballot to pass, there must be a 75%
- affirmative ballot. One would think this means 75% of the
- responses must be affirmative, but this is not the case.
- Only 75% of the non-abstaining votes need to be affirmative.
- Taken to an extreme, this means that regardless of the
- ballot pool size, if 3 people vote affirmative, 1 votes
- negative and the rest abstain, the initiative passes. The
- moral of the story is: abstain only as a last resort, there
- may be deleterious side effects.
-
- The POSIX.6 committee is now divided into 3 groups:
- -- test assertions,
- -- new projects,
- -- ballot technical reviewers.
-
- The test assertions group, led by David Rogers, is
- developing the companion document of test assertions. This
- is required to actually complete the ballot process.
-
- The new projects group is working on new Project
- Authorization Requests (PARs). Three PARs were presented:
- -- one PAR for Identification and Authentication,
- -- one for data interchange,
- -- and one for terminal I/O.
-
- In addition, PARs were prepared for the existing POSIX.6
- functions. The current PAR for the existing functionality
- will eventually be transformed into POSIX.6a (Security
- Extensions to System Interfaces) and POSIX.6b (Security
- Extensions to System Utilities and Shell). [ed. -_- PARs
- are essentially administrative project control documents,
- but are becoming administrative nightmares in the IEEE
- standards development process.]
-
- The ballot resolution group began reviewing the ballot
- objections. A preliminary analysis indicated that one
- common objection was lack of consistency within the ballot.
- Requests for consistency in function naming, calling
- parameters, data types and return codes were frequent.
- After careful reflection, the ballot resolution group agreed
- this was a reasonable request and began to work out a set of
- guidelines to ensure consistency throughout the draft.
-
- Highlights of the ballot resolution group discussions
- include:
- -- Should ``set'' and ``get'' be used for function names
- instead of ``read'' and ``write?''
- -- Should data types be contiguous in memory? (That is,
- can a data object be copied with a bcopy().)
- -- Should functions manage data storage and allocation or
- should the programmer manage them?
-
- After arduous negotiations, the group developed a set of
- guidelines, that resolved many issues that have plagued the
- drafts for years. The ballot resolution group will now join
- the State Department to support peace negotiations in the
- Middle-East.
-
- The ballot resolution group tested the guidelines by
- applying them to each of the primary functions in the draft.
- These functional areas are privilege mechanism, mandatory
- access control (including information labeling), and access
- control lists. The auditing functions were granted an
- exemption from this exercise, because they were being
- reviewed in light of the new data type guidelines and
- substantial interface modifications were expected.
-
- Chris Hughes presented some options for new auditing
- interfaces. The existing interfaces, in addition to being
- inconsistent, lack good support for application level
- auditing. Additional work is needed on the auditing
- functions, and will be presented at the next POSIX meeting.
-
- At the end of the meeting, we all agreed to try and complete
- the interface changes necessary to bring each function in
- line with the new guidelines. We also agreed to resolve as
- many ballot objections as possible before the April meeting.
-
-
- Volume-Number: Volume 27, Number 57
-
-