TSIG X WINDOWS WORKGROUP MINUTES

[trident![e-mail]]

==================================================================
>>> Submissions to the tsig list: [e-mail]
>>> Additions/deletions/questions: [e-mail]
>>> Archive Server: [e-mail]
==================================================================
January 1992
TSIG X Windows Working Group Minutes
------------------------------------

Attendees:

Maria Cangialosi	BellCoRe ([e-mail])
Jeremy Epstein		TRW ([e-mail])
Scott Marticci		NSA
Barry Miracle		SCTC ([e-mail])
Ken Bronstein		HP ([e-mail])
Ping Chen		AT&T USL ([e-mail])
Ed Cande		DEC ([e-mail])
Mike Zajdek		DIA
Mark Smith		AT&T Bell Labs ([e-mail])--chair & notes

Agenda
------

The working group operated under a loose agenda, owing to the
new direction we are attempting to take.  A rough outline of
the agenda follows:

1.  Brief talk by Mark Smith on policy-free X Window design proposal

2.  Free-flowing discussion on design proposal, including discussion on
    a proposed set of Xlib requests (binding mechanisms and access control
    mechanisms; plus a simple "PDC privilege" mechanism proposal)

3.  Alternatives to proposal; discussion on policy necessity vs.
    mechanism necessity; discussion on other ways to make the
    proposed mechanism work

4.  Discussion on policy-cognizant clients:
    - access control emulation of "gadget manager" as an example
    - setting access control information (ACI) by policy-cognizant
      clients:  use in privilege bracketing and in object floating

5.  Discussion of a set of "revision numbers" for interoperability
    - rev 0:  All policy abstracted, contained in X Server; no policy-cognizant
	      clients
    - rev 1:  All policy abstracted, contained in X Server; policy-cognizant
	      clients supported
    - rev 2:  Policy completely separated in a Policy-Defining Client (PDC);
	      policy-cognizant clients supported

6.  Discussion of type decomposition as a requirement for mechanism
    - examples for type "window"

Discussion highlights
---------------------

(Note:  ACI means "access control information," PDC means "policy-defining
client.")

After an initial discussion about the idea of trying to solve the secure
interoperable X Window problem through the use of policy-free
protocol mechanisms, Ed Cande suggested that the "real" part
of the problem was the ability to abstract the policy.  He felt that
interoperability was based on the policy abstraction, not the
actual protocol mechanism used to communicate between the PDC
(policy-defining client) and the X Server.

This was discussed at some length, after which I suggested a set
of interoperable revisions (5. above) based on (1) how the policy 
is abstracted, and (2) the set of clients we intend to allow.

We need to think a more about this.  It might be that all that we will
ever need to specify is revision 1, which would allow clients to
be security cognizant.  It appears that the access control mechanisms
are still needed pretty much intact in revision 1, since policy-cognizant
clients need to be able to request policy decisions (to emulate
windowing policy) and bind access control information (so that privileged
clients can, say, float a window).  It is also possible that privileged
clients might need to be able to change their ACI through the protocol
to implement privilege bracketing--although it is possible that a
secure OS implementation is sufficient for privilege bracketing.

There was a caveat that Mike Zajdek brought up:  having an emulation
capability causes some spoofing concerns.  Thus, if I run a
"gadget manager" client that is emulating the X Window security
policy, can I really trust it?

We also briefly discussed whether the PDC ought to be state-full or
stateless.  Jeremy Epstein noted that error conditions are very
difficult to handle in a stateless policy module--basically the X Server would
have to be able to back out past decisions upon an intervening ACI change.

If we specify a revision 1-type architecture, then there is no
physically separate PDC (and in fact "PDC" is a misnomer, though I'll
continue to call it that).  In that case, it becomes easier to make
the PDC state-full, since current access control information is 
available across a function call rather than across a protocol.

It was also noted that a revision 1 PDC could still allow an X Terminal
vendor the ability of having pluggable policies.  There would need
to be an X Terminal download capability similar to the already-existing ones
that allow (say) font downloading.

Ping Chen believes that a reasonable implementation of a revision 1
PDC would be one utilizing shared libraries.

There was some discussion about the relationship between the secure OS
policy and the windowing policy.  In particular, since a system with a
PDC has an abstracted policy, there exists the problem of choosing among
PDC-defined policies with respect to the secure OS policy--they are no
longer taken together as a monolith.  A similar problem exists if a
customer intends to use different PDCs on the same network:  there must
be a way to certify or accredit that the set of PDCs and secure OSs can
coexist.

As our last workitem, we looked a bit into the issues involved in a
type decomposition, taking the 'window' generic type as an example.
Ed felt that it would be necessary to add a 'contextID' indicating the
placement of a particular access monitor, so that the PDC
would have all the information it needed to make decisions.  Mark argued
that the 'contextID' ought to be implicit in the object type, and if there
is a spot that looks "special" with respect to the access control policy,
then probably a new subtype needs to be defined there.

(Mark Smith's comments/opinions:

Putting these ideas together somewhat, we can start to think in terms
of secure X Window interoperability as follows:

1.  We need to fully specify the protocol so that
    policy-cognizant clients are supported.  The proposed mechanisms
    (ACI binding and access control) should be sufficient, but they
    may be overkill.

2.  We need to develop a standard format for X Window object ACI.  This is
    necessary so that my server/PDC can understand your policy-cognizant
    client.  It should be possible for us to do this without a lot
    of controversy.

3.  We need to figure out whether we will need to specify *client*
    ACI as part of the X protocol.  It is possible that the secure
    OS/network will be able to handle this job.  In any case, it appears that
    there should be an interoperable standard for client ACI, even if 
    it doesn't impact the X protocol.  The major problem here appears to be
    what constitutes the privilege set for X Window.

4.  We must fully specify all X Window types.  There are two reasons
    for this.  First, there is an interoperable administrative issue
    here, where the format for a pluggable policy must include
    X Window types in its policy rules.  Second, policy-cognizant
    clients (those emulating policy) must be able to communicate 
    with any PDC.  These clients have to specify the object types.

To recapitulate a bit, we have identified a couple of non-X Window
areas that require interoperability.  First, the secure OS/network probably
needs to provide an interoperable format and transmission capability for 
client ACI, including privileges.  Second, there should be defined an 
interoperable standard for stored, type-based policy.  
The latter standard makes sense in a system where a vendor would like 
to write a policy-cognizant client using the local formatting rules.

end of Mark's comments)

Open Issues generated
----------------------

1.  Privilege implementation and representation:  Is it an X Windows
    interoperability issue?  Or is it an administrative interoperability
    issue (i.e. standardization of privilege formats contained within
    a distributed format file)?

2.  Type decomposition:  Is it reasonable for us to come up with a type
    decomposition that we can agree on?  Is it possible without "context IDs,"
    which would tell the PDC exactly what part of the server is doing
    the access check?

3.  Security policy consistency:  What statement, if any, should we make about
    the relationship between policy defined by the PDC and secure OS
    policy?

4.  Privilege model consistency:  What is the relationship between X Window
    privileges and secure OS privileges?

5.  The mechanism is basically a way of designing a monolithic X server.
    What is the relationship between a monolithic X Server and a
    "separation" server (polyinstantiated server) a la TRW?

6.  Is it feasible to come up with a complete type decomposition that we
    can all agree on?

7.  Should the PDC retain state (i.e. own the access control 
    information bindings) for clients and objects?

8.  Should we specify a protocol for a peer design (PDC as a real X
    client) or for a "ring" design (PDC as a shared library or a directly
    accessed, abstracted rule database)?

9.  What mechanism do we need to specify for subject ACI changes, especially
    dynamic implicit changes (such as a floating client)?

Summary/Actions
---------------

1.  Review open issues via email

2.  Attempt to reach a consensus (eventually) on type decomposition

3.  Allow material to sink in!

There was some reason for optimism.  For one thing, it appears that
there is groundwork laid for X Server modeling at some time in the
not too distant future.  Also, there is some hope that problems that
appeared to be very hard technically (e.g. privilege bracketing,
remote client authentication, client floating, etc.) may have 
near-term solutions.

I will be thinking some more about these open issues and will generate
some more opinions shortly.  I will do any future mailings on the
X-specific mailing list ([e-mail]).

If you are not on the X tsig mailing list, you can ask Bill to put you on
it by mailing to [e-mail].

Mark Smith
[e-mail]