Homeopathic Doses of Novelty

I can't help but point out that quite alot of academic work is not intended to clump together
large "doses of novelty."

In fact, the nature of most academic research and publication is to focus on one particular
subject or perhaps a novel combination of otherwise well-known topics and perform and in-depth
analysis of that.  Naturally such things are "boring" to most people and only relevant to very
narrow groups (usually other researchers in the same niche of the same field and occasionally
in other fields which are affected by the topic at hand.

My earlier point was that sometimes there are facets of a body of knowledge which become
"terms of art" in their field.  On the one hand one can argue that a requirement to use the
terms of art is elitist (who cares of he knows about the Clark-Wilson work if he describes the
concept adequately).

But my point was that the omission does have some downsides.  In particular a reference to
such a fundamental term gives the reader the basis for finding out quite a bit more
information with very little additional effort.  It's omission would make it very difficult to
find this related work (no other simple terms or phrases are sufficiently unique to the
discussion to readily lead to it using search engines ... for example).

Also on the other hand, the proper use of these obscure "terms of art" allows one to more
succinctly base one's work on those concepts and allows those readers familiar with the
terminology to get to the point more quickly.  (Yes, this can be at the expensive of broader
readership which might be forced to chase a hyperlink or read a side bar or whatever to "catch
up").

In the case of these "Clark-Wilson triples" the concept is recurring (for example using
traditional UNIX set group ID (SGID) it's possible for me to "deputize" a program so that it
has access to data (such as a game's score file, or a mail spool) while preventing direct
access thereto (using arbitrary tools such as an editor).  Unfortunately the problem of the
confused deputy is also recurrent.

(There are also some odd issues in the traditional UNIX model: for example if I want to make a
certain SGID program only accessible to members of a different group then I have to use
permissions on one or more parent directories to the program's links to express that policy.
Example: I might have a cash register file which I want to be modified only by certain
accounting programs while also restricting access such that those accounting programs can only
be accessed by a certain group of users -- cashiers, for example.  Normally programmers and
admins immediately reach for SUID in that situation.  But that carries even higher risks (the
confused deputy can chmod "his" files and thereby completely expose them).  A different
technique is to put the accounting programs into a directory which is associated with the
target user group (chgrp cashiers ./acctbin) and which is not world executable (chmod 07450
./acctbin).  Now the acctbin/* executables can be marked SGID to the acctdata group.  Result:
only members of the cashiers group can execute the programs which are deputized to modify the
accouting data.  Despite this wrinkle it is far less complicated and plausibly about as
effective as the SELinux model described in the original article.  (Incidentally one can
express logical OR and logical AND relationships using hard links into other parent
directories and multiple levels of directory.  I'll leave that as an exercise to the reader).

Now I will also grant that referring to these as "Clark-Wilson triples" may be misleading.
They describe a set of relationships among user, program and data which is similar to those
detailed by the "Clark-Wilson integrity model" but the system as a whole doesn't conform to
their design.  (Remember the little constraint about who the creator/maintainer of these
triples must not have direct execute permissions on the programs in question).  However I
think that giving this particular relationship a name is useful for discussing systems
administration topics more succinctly.  When I say I have "deputized" a program it would be
nice if that was as readily understood as when I might way that I've "wrapped" it with a
script.  (And, in fact, one could then talk about deputizing a wrapper in a meaningful way
without getting bogged down by the details).

I remain unconvinced that SELinux gives us enough real additional functionality to justify
it's horrendous complexity.  I still advocate more widespread use of systrace which is simple
enough to explain in a page and to more or less fully document in a few pages (with the
pre-requisite that the reader understands UNIX/Linux system call usage) and which is analagous
to an ubiquitous networking security model.  So I can tell any sysadmin that systrace is like
a firewall or set of packet filters between user space and the system call interface to the
kernel and I've summarized the entirety of the systrace model in a single sentence.  Anyone
who has dealt with packet filtering will then already have a ready frame of reference into
which to feed the usage details.  They will probably "get it" immediately.  I have seen almost
zero traction on the SELinux model.  It's so convoluted and so disjoint from the rest of the
UNIX/Linux permissions and access/control model that the vast majority of sysadmins prefer to
disable it wherever possible.

We could argue that those sysadmins are just a bunch of old-fogeys who are unwilling to
embrace change and who are impeding progress.  I've seen SELinux proponents come just short of
calling all of the rest of us a bunch of Luddites.  (If we were truly "Luddites" then SELinux
should be welcomed as it's complexity will surely guarantee those of us who can learn it
paying work for the rest of our careers).

Anyway, I hope this is entertaining and perhaps a bit informative because, at this point I
realize I'm just rambling.  Time to get that first cup of coffee. :)

JimD