TSIG X WINDOWS WORKGROUP MINUTES
trident!mark@neptune.att.com Thu, 06 February 1992 21:33 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa28147; 6 Feb 92 16:33 EST
Received: from wdl1.wdl.loral.com by NRI.NRI.Reston.VA.US id aa28142; 6 Feb 92 16:33 EST
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.08) id AA06229; Thu, 6 Feb 92 12:36:44 -0800
Received: from att.att.com by wdl1.wdl.loral.com (5.61+++/WDL-3.08) id AA06216; Thu, 6 Feb 92 12:36:22 -0800
Message-Id: <9202062036.AA06216@wdl1.wdl.loral.com>
From: trident!mark@neptune.att.com
Date: Thu, 06 Feb 1992 15:28:00 -0500
X-Mailer: Mail User's Shell (6.5.6 6/30/89)
To: neptune!att!tsig@wdl1.wdl.loral.com
Subject: TSIG X WINDOWS WORKGROUP MINUTES
Cc: bsmith@neptune.att.com
Sender: tsig-request@wdl1.wdl.loral.com
================================================================== >>> Submissions to the tsig list: tsig@wdl1.wdl.loral.com >>> Additions/deletions/questions: tsig-request@wdl1.wdl.loral.com >>> Archive Server: archive-server@wdl1.wdl.loral.com ================================================================== January 1992 TSIG X Windows Working Group Minutes ------------------------------------ Attendees: Maria Cangialosi BellCoRe (mariah@ctt.bellcore.com) Jeremy Epstein TRW (epstein@trwacs.fp.trw.com) Scott Marticci NSA Barry Miracle SCTC (miracle@sctc.com) Ken Bronstein HP (ken@hpcrlx.cv.hp.com) Ping Chen AT&T USL (pcc@usl.att.com) Ed Cande DEC (cande@decvax.dec.com) Mike Zajdek DIA Mark Smith AT&T Bell Labs (mark@neptune.att.com)--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 (x-tsig@wdl1.wdl.loral.com). If you are not on the X tsig mailing list, you can ask Bill to put you on it by mailing to tsig-request@wdl1.wdl.loral.com. Mark Smith mark@neptune.att.com
- TSIG X WINDOWS WORKGROUP MINUTES trident!mark