policy and mechanism

Question

I was going through my operating systems textbook and I came across the concept of "separating mechanism and policy". I wasn't sure of what that meant so I checked out wikipedia which I must admit, was not of much help either.

The separation of mechanism and policy[1] is a design principle in computer science. It states that mechanisms (those parts of a system implementation that control the authorization of operations and the allocation of resources) should not dictate (or overly restrict) the policies according to which decisions are made about which operations to authorize, and which resources to allocate.

Could someone tone this down, and explain if possible with a few examples what separation of mechanism and policy means in the context of Operating systems?

Alehouse

Answer 1

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.

Alleenallegation

Yeah, especially since the original policy was you pass -geometry when starting all X applications (from the command line). – Couple

Answer 2

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).

Couple

+1 - Another excellent example of the principle. Unix actually has almost (but not quite) enough mechanism to allow the implementation of capability-based security. File descriptor passing over Unix domain sockets is one basic thing that's a very important feature for this. But it needs more, like a way for even a user process to exec and have the resulting process have fewer privileges. – Alleenallegation

@Omnifarious: actually that last one's easy. Drop privileges between fork() and exec(). However, there is no equivalent of Vista's sandboxing. – Couple

But if you're a user process, how do you drop privileges? For example, have the privileges of 'nobody' and no permission to create sockets. And Vista's sandboxing can be implemented with file descriptor passing. – Alleenallegation

I once encountered this thing where one could limit the system calls that could be issued by a child process, but I forgot its name and can't find it now. – Couple

There is the capability mechanism - although seemingly at the moment Linux specific. Linux has implemented the now defunct draft standard of POSIX/SUS relating to capabilities and is now fully compliant with this standard as of kernel 2.6.24. On linux systems, it is documented under man 7 capabilities. I am currently using the libcap api in an httpd daemon that I am developing, along with the epoll api, which is also linux specific. – Diao

@Diao - Those capabilities are not exactly what I mean. Though they do provide a way to drop many kinds of privileges after fork and before exec. And so do namespaces. Capability based security is an overall model of security that scraps the idea of authentication completely and disallows any program from accessing something not given to it explicitly by another program. See: en.wikipedia.org/wiki/Capability-based_security – Alleenallegation

Answer 3

Difference between mechanism and policy mechanism determines how to do something, policies decide what will be done.

The separation of policy from mechanism is very important principle, it allows maximum flexibility if policy decisions are to be changed later.

Tishtisha

Answer 4

Although this is a very old question, I still want to share my point.

The reason why this passage is confusing is because of the two words "mechanism" and "policy". And in the context of software engineering, I think it's always ok to replace "mechanism" with "interface" and "policy" with "implementation".

As for the separation of interface and implementation, if you're programming in Java, then you must be quite familiar with these two concepts. By doing so, we can isolate "what to do" from "how to do", which helps us achieve system decoupling.

Why decoupling? Decoupling improves the extensibility and maintainability of the code, which means we can write less code when requirements change :)

Learn more techniques about decoupling from "The GoF Design Patterns".

Renatarenate