stripes@eng.umd.edu (Joshua Osborne) (03/26/91)
In article <1991Mar19.193342.28295@Think.COM>, barmar@think.com (Barry Margolin) writes: [...] > The problem is that while you may trust the *people*, you can't always > trust the software they run. In many window systems, it is possible for > software to simulate user actions, and this is ripe breeding ground for > Trojan Horses. If a user can manually cut and paste, then a TH can > simulate this and downgrade information without the user realizing it. In X any events created by a client program (the one that asks for things to be drawn in windows, not the thing that does all the drawing) have a bit set. Well it is a 16 or 32 bit field that gets set to a "non-zero" value, when makeing a MAC (is that the right term?). I guess that you could make the non-zero value the clasifaction level of the progam that sends. The only program that I know of that uses this is xterm which ignores all client created events (or at least the keyboard events, and most likely mouse ones) unless the AlowSendEvents resource is set to true (or the provided menu item is used...). > However, if cut-and-paste uses a "trusted path" that can't be emulated by > unverified software (which probably requires much of the window system to > be in the TCB, yuck) then it might be feasible to relax such restrictions > in some environments. It will only require the "paste" function to done by proper software. I don't know if it is acceptable for this software to be in a lib (as opposed to being part of the OS). > Such operations must be audited, but if you permit > downgrading at such a fine grain then then tracing back the information in > the logs can be difficult (cut buffers don't generally remember the name of > the document from which the data came). Again this could be done in X, the selection protocall is very flexable you can add to the data passed (via cut/copy) the file the info was from and even what line (or cell, or whatever) it was from. Then the paste could refuse to paste from a higher clearance window unless it (a) had all that info, and (b) the user was allowd to downgrade that info. Meta-comment: I cross posted this to comp.windows.x & alt.security, and redirected the followups to alt.security (I am unsure whether it belongs in alt.security or comp.windows.x so I guessed, it has gotten rather removed from comp.unix.internals 'tho) -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
dshr@eng.sun.COM (David Rosenthal) (03/27/91)
> In X any events created by a client program (the one that asks for things to be > drawn in windows, not the thing that does all the drawing) have a bit set. Well > it is a 16 or 32 bit field that gets set to a "non-zero" value, when makeing a > MAC (is that the right term?). I guess that you could make the non-zero value the > clasifaction level of the progam that sends. The only program that I know of that This is not correct. To quote from the protocol spec Section 1 [page 370 of the Digital Press 2nd edition]: Every event contains an 8-bit type code. The most-significant bit in this code is set if the event was generated from a SendEvent request. In other words, there is only one bit of information transferred from the server to the client, not a 16 or 32-bit field whose value could be used. General comment. When making claims about what X does or does not do, please do not depend on the arguments to the Xlib functions. Read the protocol specification to make sure what the real information transferred between the server and the client is. David.
stripes@eng.umd.EDU ("Stripes ", or Josh, if you must) (03/27/91)
David Rosenthal said: >This is not correct. To quote from the protocol spec Section 1 [page 370 >of the Digital Press 2nd edition]: > > Every event contains an 8-bit type code. The most-significant > bit in this code is set if the event was generated from a > SendEvent request. > >In other words, there is only one bit of information transferred from the >server to the client, not a 16 or 32-bit field whose value could be used. I guess I had forgotten. (I have read the RFC, and the DP book, don't rember which Ed) I'll be reading Book 0 of the O'Reilly X seires again soon... I guess if I had started it a few days ago I wouldn't have messed up :-( >General comment. When making claims about what X does or does not do, >please do not depend on the arguments to the Xlib functions. Read >the protocol specification to make sure what the real information >transferred between the server and the client is. I try to, I just happen to read Xlib specs more offen, and use 'em more. (this will change soon...) In fact I knew the client got 32 bits (an int, which is normally 32), and knew it wasn't 32, but for some reason I thought it was 16, not 1. *SIGH* -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)