home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.16 / text0038.txt < prev    next >
Encoding:
Text File  |  1989-08-11  |  5.8 KB  |  161 lines
  1.  
  2. Standards Update                              Part 5: 1003.6
  3.  
  4.           An update on UNIX|= Standards Activities
  5.        January 1989 IEEE 1003 Meeting, Ft. Lauderdale
  6.  
  7.                       Part 5:  1003.6
  8.  
  9.            Shane P. McCarron, NAPS International
  10.  
  11.      1003.6 - Security Extensions to POSIX
  12.  
  13.      The security working group is currently working on a
  14. number of topics in parallel - Autiding, Discretionary
  15. Access Controls (DAC), Mandatory Access Controls (MAC), and
  16. Privileges.  As these topics have been described in detail
  17. in previous installments, I won't do it again.  Instead,
  18. here is a brief summary of topics of interest being
  19. discussed in those sub-committees:
  20.  
  21.      MACs
  22.  
  23.      The group decided to accept one proposal before them as
  24. a baseline.  This will help them to decided on their exact
  25. scope of operation and also to decide on their goals.  This
  26. baseline proposal has not solved even a small percentage of
  27. the problems facing this committee.  Things like information
  28. label mechanisms, data transport, text label format, label
  29. constraints, and security for public/shared directories were
  30. too abstract at this time, the group decided to ask for
  31. white papers to talk about them at the April meeting.
  32.  
  33.      AUDIT
  34.  
  35.      This group has embraced a proposal as a base.  This
  36. proposal, in conjunction with a proposal from X/Open, will
  37. probably be the primary source in this area.
  38.  
  39.      DAC
  40.  
  41.      This group was finally able to resolve some of the
  42. issues that have been in dispute since its creation.  In
  43. particular, the group was able to agree on:  The
  44. representation of an Access Control List (ACL), Ordering,
  45. Default ACLs, and most importantly the issue of how ACLs are
  46. to be used in the system.  ACLs will be an additional
  47. security mechanism, which much be enabled by explicit user
  48.  
  49. __________
  50.  
  51.   |= UNIX is a registered trademark of AT&T in the U.S. and
  52.     other countries.
  53.  
  54. January 1989               - 1 -              Ft. Lauderdale
  55.  
  56.  
  57. Standards Update                              Part 5: 1003.6
  58.  
  59. action.  This satisfies the requirements of the 1003.1
  60. standard, which had left room for just such a mechanism by
  61. leaving some weasel-wording in the definition of File Group
  62. Class.  The specific mechanism will be that the permissions
  63. available to users (or groups) listed in an ACL will be a
  64. subset of those availabe using the traditional group
  65. permissions of the file.
  66.  
  67.      In addition, the inheritance of ACLs was discussed.  It
  68. appears as if the group will agree that the ACL for a
  69. directory will propogate to any sub-directories that are
  70. created.  However, this is still an issue and will be
  71. debated at the April meeting.
  72.  
  73.      In addition, the group agreed that there will be
  74. routines in the standard for manipulating each type of ACL,
  75. and that named or shared ACLs will not be in the standard.
  76.  
  77.      PRIVILEGES:
  78.  
  79.      The principle of least privileges requires that each
  80. subject in a system be granted the most restrictive set of
  81. privileges needed for performance of authorized tasks.  The
  82. principle of Least Privilege will also include the concept
  83. that each privilege is available for the minimum scope of
  84. execution required to perform the task for which it is
  85. needed.
  86.  
  87.      The purpose of privileges is to assure the authorized
  88. and restricted use of a service.  Security relevant code can
  89. be bracketed and the privileges may be enabled only during
  90. execution of that part of a program.
  91.  
  92.      Issues that need to be addressed by this group include:
  93.  
  94.   1.  To what degree can privileges be segmented to allow
  95.       control over individual privileged actions?
  96.  
  97.   2.  How can a designer of a privilege propagation
  98.       mechanism assure compliance with the principle of
  99.       least privilege?
  100.  
  101.   3.  How can user access to privileged operations be
  102.       limited in accordance with the principle of least
  103.       privilege?
  104.  
  105.   4.  What control interfaces are necessary to allow
  106.       privilege mechanism?
  107.  
  108. The group has agreed that no privilege should grant access
  109. to more than a single set of related operations.  The group
  110.  
  111. January 1989               - 2 -              Ft. Lauderdale
  112.  
  113.  
  114. Standards Update                              Part 5: 1003.6
  115.  
  116. also agreed that the propogation of a privilege from one
  117. "subject" (process) to another should be strictly
  118. controlled.  Because traditional implementations propogate
  119. priviliege based on the effective user ID of a process, any
  120. secure implementation will have to permit this behavior.
  121. However, to permit for more secure software being developed
  122. in the future, it is necessary to provide some primitives
  123. that will permit a parent process to restrict which
  124. privileges are progated to its children.
  125.  
  126.      The standard will be defining a set of interfaces for
  127. accessing privileged operations.  These interfaces will
  128. allow for: Reducing the level of privileges, setting,
  129. creating, or adding privileges, acquiring privineges,
  130. testing for privileges, requesting a privilege type, setting
  131. privilege propogation, requesting a set of maximal
  132. privileges, determining the set of privileges currently
  133. enabled, determining the success or failure of privilege
  134. accumulation, and creating of privileges not in the current
  135. set.
  136.  
  137.      The scope of this committee is to define extensions to
  138. the POSIX interface which support a privilege mechanism
  139. capable of enforcing a 'Least Privilege' security policy,
  140. and a minimum set of privileges which are necessary to
  141. support such a policy in a portable applications
  142. environment.
  143.  
  144.      The Usenix Standards Watchdog Committee contact for
  145. this group is Anna Maria de Alvare.  She can be reached at:
  146.  
  147.           Anna Maria de Alvare
  148.           Lawrence Livermore National Laboratories
  149.           PO Box 808
  150.           L-303
  151.           Livermore, CA  94450
  152.           +1 (415) 422-7007
  153.           annamaria@lll-lcc.llnl.gov
  154.           uunet!lll-lcc.llnl.gov!annamaria
  155.  
  156. January 1989               - 3 -              Ft. Lauderdale
  157.  
  158.  
  159. Volume-Number: Volume 16, Number 36
  160.  
  161.