Events

Another area of concern is the malicious sending of X events to windows belonging to other clients. This sort of behavior enables the ``shatter'' attack which has been demonstrated on Microsoft Windows systems. This attack involves sending malicious configuration events to a window owned by a privileged process, causing a buffer overflow that allows arbitrary code to be run as the privileged user. [6].

It should be noted that X events are part of a wire protocol, not an internal API such as in Windows, nor can X events used to configure individual text fields or other widgets as in done in the shatter attack. However, there is a SendEvent protocol request which allows clients to send arbitrary events, including fabricated keyboard and mouse input or other unexpected notification normally generated only by the server.

In Kilpatrick et. al., the various core protocol events were grouped into rough categories which are expressed as permission bits on the window object class [4]. Thus, sending a KeyPress event to a window requires the inputevent permission on that window. In Figure 3, line 12, the window manager domain is granted permission to send events from two different categories to all application windows.

In this manner, SELinux policy may be used to control the sending of events. In the future, however, the category model may be discarded in favor of X events as a distinct object class, labeled based on the event name (or number) in a similar manner to the property class.