home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0085.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  9.2 KB
  1. From: Jeffrey S. Haemer <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                             December 1989
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.6: Security Extensions Update
  13.  
  14. Ana Maria de Alvare <anamaria@lll-lcc.llnl.gov> reports on the October
  15. 16-20, 1989 meeting in Brussels, Belgium:
  16.  
  17. The security working group worked the full week, discussing the draft.
  18. The meeting's primary goal was to approve the current draft for
  19. distribution to the international working groups. It was presented, at
  20. the EEC, to new members of the group from the European countries, and
  21. every member introduced himself/herself the first day of the meeting.
  22. Once introductions were out of the way, we dealt with the major topics
  23. that follow.
  24.  
  25. TRUSIX
  26.  
  27. A representative from TRUSIX, Charles Testa, gave the usual progress
  28. report on TRUSIX.  [Editor's note -- TRUSIX is an organization
  29. sponsored by the National computer security center (NCSC), developing
  30. a secure UNIX model.  The participants are a number of vendors
  31. developing secure UNIX implementations.] Their modeling subcommittee
  32. has nearly completed a formal model describing the UNIX file system.
  33. They have accepted the "Ina Jo" model to describe Trusted UNIX System
  34. Interfaces.  This model revolves around a MAC-read criterion, MAC-
  35. writes and a DAC constraint, and consists of simple security
  36. properties, confinement properties, and discretionary security
  37. properties representative of the Bell-LaPadula model.
  38.  
  39. The TRUSIX ACL Rationale and Working Example Document has been
  40. approved by the NCSC and is being reviewed for publication under NCSC
  41. security publications.
  42.  
  43. One topic of interest to all security readers is prevention and/or
  44. detection of covert channels.  TRUSIX is planning to include this
  45. under the Audit Rationale Document, which will include examples of
  46. typical covert channels and their implications.  Issues such as
  47.  
  48. __________
  49.  
  50.   * UNIX is a registered trademark of AT&T in the U.S. and other
  51.     countries.
  52.  
  53. December 1989 Standards Update        IEEE 1003.6: Security Extensions
  54.  
  55.  
  56.                                 - 2 -
  57.  
  58. bandwidth evaluation will be addressed by a separate white paper.
  59.  
  60. POSIX Conformance Testing
  61.  
  62. A representative from 1003.3,the POSIX Conformance Testing group,
  63. presented 1003.3's goal -- to establish a series of specifications for
  64. testing the different POSIX standards. Although they have written the
  65. pseudo-code to test the conformance of a system to 1003.1, they feel
  66. they lack the staff and expertise to produce such tests for all the
  67. 1003 groups.  Given this, their current plan is to draw upon each
  68. group for expertise and background knowledge of the subject at hand,
  69. and join those skills with their testing skills to produce a test bed
  70. for each 1003 standard.
  71.  
  72. Their ultimate goal is to allow testing of all elements of an open
  73. system for POSIX conformance by defining common test methods, which
  74. can then be implemented by private industries as test suites. They
  75. explained how to list the assertions, how to classify them, and what
  76. information they will need to produce a test method for 1003.6.
  77.  
  78. One factor mentioned was that the description has to address a single
  79. unit of behavior expected of a conformant system at a time. This
  80. implies dissecting interfaces into separate groups of assertions and
  81. generating assertions for both semantic and syntactic descriptions.
  82.  
  83. Discretionary Access Control (DAC)
  84.  
  85. The group focused on polishing and adding information to the draft.
  86. It was suggested the standard shouldn't define the behavior of 'chmod'
  87. when old programs are being executed with the DAC mechanism.
  88.  
  89. It was noted that the current proposed Access Control List (ACL) might
  90. not be fully compatible with the current behavior of a 'chmod' call.
  91. With the current, old-style behavior, when 'chmod' is used to change
  92. owner, group and/or other permissions, the changed permissions
  93. represent the access modes of the file.  In the current proposal for
  94. ACL, a 'chmod' will provide the old behavior for the "owner" and
  95. "other" fields, but the "group" field permissions as set by 'chmod'
  96. and shown by 'stat', wouldn't represent the actual access permissions
  97. of the group associated with that file; instead, it's a summary of all
  98. access permissions included under the ACL list for group entries.  In
  99. other words, it would represent the maximum permissions allowed to the
  100. group entries included in the ACL list.
  101.  
  102. Some participants argued that 'chmod' should be replaced by other
  103. system calls in a system conforming to 1003.6.  In other words, if
  104. your system were to conform to 1003.6 the behavior of chmod would be
  105.  
  106. December 1989 Standards Update        IEEE 1003.6: Security Extensions
  107.  
  108.  
  109.                                 - 3 -
  110.  
  111. unspecified and unpredictable.
  112.  
  113. I disagree.  Although defining the behavior of 'chmod' might restrict
  114. some implementations of ACLs, having a well-defined chmod behavior
  115. will provide backward compatibility and ease porting old programs to
  116. 1003.6-conformant systems.  Otherwise old programs will have to be
  117. ported to platforms with system-dependent representations of 'chmod'
  118. and 'stat' information.
  119.  
  120. It was also proposed that the ACL list should allow entry types like
  121. timestamping.  This would allow a policy that is more restrictive than
  122. the DOD, orange-book policy to provide more granularity of file
  123. access.
  124.  
  125. Mandatory Access Control (MAC)
  126.  
  127. Kevin Murphy, of British Telecom, presented his views on electronic-
  128. mail-label usage and proposed that such a mechanism should be used as
  129. part of the standard.  The electronic mail security labels consist of
  130. a generic format that includes four major components: security policy
  131. id, security classification, privacy mask, and security categories.
  132. This approach to labels is implemented on X.400 security services.
  133. One clear advantage of using such a format for labels is that it
  134. maximizes the potential synergy between operating-system and
  135. electronic-mail labels.
  136.  
  137. Chris Hughes from ICL presented British views on MAC information
  138. labels.  Its main characteristics are these: object creation
  139. initializes the label, the label is implementation-defined and changed
  140. by the owner, and the label is not used for access control.  Chris
  141. proposed that the standard should provide a get/set mechanism for the
  142. object information label, and a way to merge and translate information
  143. labels, but should not standardize the labels' contents.
  144.  
  145. Information labels are useful because they provide added information
  146. on particular objects.  We concluded that information labels should be
  147. in the scope of MAC as part of the standard, and requested that MITRE
  148. provide a presentation on information label use at the next meeting.
  149.  
  150. Privileges
  151.  
  152. The whole group heard a presentation of the internal draft of the
  153. privileges document.  We decided that the wording had problems.  The
  154. draft interface description is too obscure and needs a simpler
  155. description of privilege interfaces, before it can be included in the
  156. 1003.6 draft document.
  157.  
  158. December 1989 Standards Update        IEEE 1003.6: Security Extensions
  159.  
  160.  
  161.                                 - 4 -
  162.  
  163. Although the group argued considerably about the wording, they seemed
  164. to agree on the concepts.  The main points are that privilege is
  165. associated with a process and privilege attributes can be attached to
  166. files.
  167.  
  168. I do not think I should burden the reader with the brainstorming ideas
  169. of the privilege group until a firmer position is taken at the next
  170. meeting.  One thing I can say is that the process-privilege concepts
  171. described in my last report (permitted, inheritable and effective),
  172. still stand, and a file still has three types of privilege attributes.
  173.  
  174. Audit
  175.  
  176. Kevin Brady from AT&T and Doug Steves from IBM presented a combined
  177. proposal, produced by them and Henry Hall from DEC, on how to define
  178. audit interfaces for 1003.6.  Their proposal was meant to contest the
  179. current audit stand, lead by Olin Sibert from Oxford Systems.
  180.  
  181. The current audit definition is based on the token concept and on a
  182. pure procedural interface.  In the procedural interface all data
  183. manipulation of the audit record is performed by function calls, with
  184. data passed explicitly through function parameters.  Although this
  185. sounds attractive and clear, in practice it requires many function
  186. calls.
  187.  
  188. Another major point of controversy was the audit trail format.  In
  189. Olin's proposal, conversion cost is minimal because writes and reads
  190. require an explicit specification of the format wanted.  In Kevin,
  191. Doug and Henry's proposal the conversion function is set to one of
  192. three conventional formats: little endian, big endian, or XDR.  In
  193. other words, the information is stored in machine-dependent format
  194. while Olin's chooses a uniform format for all information stored.
  195.  
  196. One last contested feature was the ability to rewind audit trail
  197. information when viewing it.  Kevin, Doug and Henry's proposal does
  198. not allow a rewind, since information is manipulated at the data-
  199. structure level.
  200.  
  201. Because of the heated discussion of procedural versus data-structure
  202. interfaces for POSIX, both proposals will be formally written out,
  203. removed from the draft, and presented in the next meeting for a final
  204. vote.
  205.  
  206. December 1989 Standards Update        IEEE 1003.6: Security Extensions
  207.  
  208.  
  209. Volume-Number: Volume 17, Number 94
  210.  
  211.  
  212.