policy and mechanism

Here is what this means for the X-Windows system.

X-Windows, at the very base level, provides a way of manipulating screen areas called 'windows'. It also provides a way to receive events that happen inside windows.

But X-Windows says nothing about title bars, menus, scrollbars or any of that stuff. It also doesn't say anything about the rules by which a particular application can make its window occupy the whole screen, or when a window has to be moved off the screen. It does provide a way for one application to force other applications to ask it permission before doing things with top-level windows, but doesn't provide any such application as part of the base server.

X-Windows is all about mechanism, not policy.

The policy is provided by the widget toolkit, by the window manager, and by other things added to the system later. Many widget toolkits, for example, use a set of overlapping sub-windows for scrollbars and ask for mouse events for these sub-windows so they can detect click and drag operations and make the sub-windows respond appropriately.

This is why, for example, GNOME and KDE can get along on the same display, and why really old X-Windows programs that know nothing about panels or desktops still work just fine on modern systems.

In regard to *nix operating systems, the general idea is the security system is implemented by the kernel, and the authorization system is implemented by userspace.

The all-powerful root and suid binaries that so many people deride (whether justly or otherswise) are necessary for effective separations. It is possible to completely swap out the authentication mechanism while leaving the security intact (ssh does this, which is why it uses undocumented APIs on Windows).