Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.17/text0011.txt

Text File | 1990-01-06 | 12.2 KB | 293 lines

            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare ([e-mail]) reports of the April,
1989 meeting:

P1003.6 covered these global issues at the five-day Minneapolis
meeting:

  1.  Supplements to 1003.1 will address portability, data interchange
      format, and symbolic links. This means 1003.6 must also consider
      those areas.

  2.  1003.6 would like to define a system variable that tells what
      security policies are allowed on the system, and a function that
      returns which security-related attributes (e.g., MAC, ACL) are
      currently in operation.  Such changes would need to be made in
      collaboration with 1003.1.

  3.  Other pieces of 1003.1 and its supplements may conflict with
      security extensions.  A short-term subgroup was proposed to
      review these documents and propose additions or changes.  1003.6
      is looking for volunteers for this work.  [Ed.  -- If you have,
      or can imagine, the orange book and the ugly green book side-
      by-side on your bookshelf, now's the time you should work to
      insure that only their colors clash.  The chair of 1003.6 is
      Dennis Steinauer ([e-mail]), who, we believe,
      would be happy to hear from you if you're willing to help.]

  4.  Two members of the networking group (1003.8) joined 1003.6 for
      half a day to list and explain their areas of concern:
      transparent file access, authentication at mount time, setuid
      programs, file format, local id contents, and who does the
      audit.  These issues were scheduled to be re-visited at the San

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 - IEEE 1003.6: Security Extensions

      Jose meeting in July in a joint meeting of the two groups.

  5.  Charlie Testa gave a status report on TRUSIX.  The TRUSIX
      working group responded to Tom Parenty's paper, which summarized
      the TRUSIX efforts.  The members felt compelled to clarify
      certain sections that they believed misconstrued their real
      objective: the creation of a trusted UNIX operating system.
      This response is also published in the December, 1988, Data
      Security Letter Journal.

      There are serious conflicts and points of contention between
      POSIX and TRUSIX.  POSIX is worried that systems conforming to
      TRUSIX recommendations will get preferential treatment during
      product evaluation, that vendors who currently plan only Class
      B2 systems or below are excluded from TRUSIX, and that
      participants in TRUSIX share proprietary information.  TRUSIX
      takes the position that the marketplace should be the final
      judge.  TRUSIX will be POSIX compliant, and will make no attempt
      to force vendors to be both POSIX and TRUSIX compliant.  If
      customers force a de-facto standard of dual compliance for even
      non-DOD applications, so be it.

      TRUSIX's ACL proposal will be delivered to the IEEE at the July
      meeting.  The proposal is only a guide, and it will not be
      written in a formal specification language as a favor to the
      reader.

      TRUSIX's audit subgroup is trying to follow both POSIX and
      X/Open efforts in this area.  Their subgroup is focusing on
      pre-selection, in contrast to the 1003.6 focus on post-
      selection, and they will review a token-based scheme at their
      next meeting.

  6.  At the previous meeting, a common descriptive top-level
      specification language (DTLS) was proposed.  For the moment,
      this language will form an appendix to the draft, and will be
      used as an internal tool to let the group define unambiguous
      security interfaces.  Every subgroup of 1003.6 will provide
      descriptions of interfaces in both English and DTLS.  Steve
      Sutton will be the chair of the DTLS team, and will work in
      conjunction with the technical editor of the draft.

The Security Working group is split onto separate groups for audit,
discretionary access control (DAC), mandatory access control (MAC) and
privileges.  Each subgroup gave a summary report at the end of the
week and some were able to give a first-cut delivery schedule.  The
following is a short summary of each group's efforts.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 3 - IEEE 1003.6: Security Extensions

AUDIT:

The scope of the audit group encompasses audit definition, auditable
events, audit trail contents, and audit trail access and control.  The
group will also define a portable audit-trail data representation and
focus on post-processing event classes.

Audit records will include process identification, audit id, effective
user id, effective group id, media addresses, MAC labels and privilege
information.  In San Jose, the audit group will try to identify all
token types, define the audit id, propose some changes to the 'seek'
function, pursue event classes, and review and merge the DTLS
interface descriptions with the English sections.

DAC

The DAC group is almost done with its rationale section.  One question
this time around was how to pass access mechanisms based on DAC across
the network.  Currently, file ownership is the first access check; on
networked systems, this can lead to spoofing, particularly when root
tries to access files on other systems.

Another hot issue was access functions.  The consensus is that an
access function to an opaque DAC (i.e., one that prevents knowledge of
the structure) should replace the use of stat(),chmod(),stat() or
locking mechanisms for controlled file access.  The function will not
replace chmod(), stat() or permission bits; however it will define
operations that will allow applications to continue to work correctly
in the face of ACLs.

MAC

Issues addressed here come from the MAC requirement that all system
objects be labeled with security levels (e.g., CONFIDENTIAL, SECRET,
TOP-SECRET).  Two proposals were on the table -- one from Addamax, the
other from Olin Sibert -- but no strong consensus was reached.
Miscellaneous comments on the issues discussed:

  1.

         o+ Downgrading (of security levels)

         o+ How should it be done?

         o+ Must the old label dominate the new one?

         o+ Does downgrading need to be strictly controlled?

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 4 - IEEE 1003.6: Security Extensions

         o+ What about upgrading?

  2.  Directory labels.
      mkdir should be allowed to label directories on creation, to
      permit portable, level-hierarchy-dependent applications.

  3.  File locking.
      The standard should address locks and may consider them as
      objects.

  4.  "Write-up" appends.
      Writing to a file at a level above you is known as "write-up".
      Processes can write to files that they can't read.  At first
      blush, this seems analogous to standard UNIX, which allows files
      with permissions --w--w--w-.  What MAC adds is the prohibition
      that the process even know if the write succeeds.  Because
      appending to such a file provides no way to assure that the
      write succeeded, requested file, the question of whether to
      allow such write-ups was raised and discussed.

  5.  Change of file level with open file connections.
      UNIX does not expect open connections to break.  (An exception
      is /dev/tty* on 4.3BSD, which can be checked for open connection
      breaks.) Since /dev/tty* are special files and 1003.1 doesn't
      address special files it was argued that 1003.6 need not either,
      but this issue will be discussed further in San Jose.

  6.  Open tranquillity.
      The tranquillity property states that a resource should not be
      in active use during changes to its attributes.  (See also issue
      #5 above.) It was stressed that POSIX should be defining states
      and mechanisms that are as safe as possible, obvious to
      implement, deterministic, and clear.  Only privileged processes
      should be able to change the MAC label of a file object.

  7.  Replication or Recalculation?
      Replication means copying current properties across from one
      label to another.  Recalculation means re-evaluating the
      situation, then assigning properties or attributes needed for
      each file to work as labeled.  The consensus was that
      recalculation is needed in the standard, but there was no
      consensus on how either recalculation replication should occur.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 5 - IEEE 1003.6: Security Extensions

  8.  Multilevel directories
      A "multilevel directory" is a directory with files at different
      levels (e.g., both TOP SECRET and CONFIDENTIAL).  Should a
      multilevel directory feature be available for general use?
      Should it be part of the standards?  If so, operations on
      multilevel directories would be restricted and functions to be
      able to create, check for existence, query for directory name
      would be required.  These directories would inherit their DAC
      from their parent.

      The directory that stores files the user can see at the current
      time, as determined by the label at request time, is the "access
      hidden directory".  An open question is whether access to such a
      directory should be controlled by process privilege or the
      pathname syntax.

  9.  Text Format
      Two proposals were put forward on text format, but only one was
      discussed because of time constraints.  Despite this, the group
      resolved that naming should be site-specific, but names should
      be unique and order-independent.  Furthermore, a label should be
      interpretable and unique.  One major problem was that the
      characters suggested for hidden directories were outside the
      constrained character set provided by 1003.1 -- [a-z][A-Z][0-9]
      and a very limited set of punctuation characters.

 10.  System High/Low?
      This government concept is used a lot in discussions of secure
      systems.  It was put on the agenda for the July, San Jose
      meeting.

 11.  Other Issues
      Should the standard assure a non-decreasing directory hierarchy?
      In other words, should subdirectories always have at least as
      high a level as the parent?  Should the standard define level
      ranges such as system high?  Should the standard define a
      process clearance range? (Clearance only defines how to specify
      an error return that the system is allowed to give.)

PRIVILEGES

The group reviewed interface functions defined at the previous
meeting, and agreed on all of them except 'exec()', which poses
unresolved problems about inheritance of privileges.  The group
expects to finish this in July.

Some of the functions defined so far are: is_effective(p),

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 6 - IEEE 1003.6: Security Extensions

make_effective(p), make_ineffective(p), is_inheritable(p),
make_inheritable(p), make_not_inheritable(p), is_permitted(p),
relinquish(p), make_effective_if_inherited(p), and
make_all_ineffective(p) -- all related to querying the process
privilege state.

Old goals were revised and new goals added, including: support for old
binaries, support for new binaries implementing true least privileges,
acquisition of effective privilege following exec(), prevention of
some programs from inheriting privileges, and unsetting of privileges
on exit from signal handlers.

Other issues included:

  1.  Privilege inheritance
      When is it needed?

  2.  Forbidden privilege
      Should a flag be available to forbid a process to gain a
      privilege?

  3.  Privilege System Variable
      Should the standard define a system variable to set privileges
      at installation time?

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 14