LWM (Was RFC: Requirements...)

[Tim Fraser]

Hi!

ma> -Low water mark model
rw> Since Tim Fraser is on the mailing list, I'd be interested in hearing
rw> his opinions on the topic, as he has implemented LOMAC on Linux.

I chose to implement Low Water-Mark (LWM) over many other good models
because I wanted compatibility first and quality of protection second.
Consequently, I did not go with a model like Type Enforcement (TE), even
though TE provides superior support for limiting programs to precisely the
minimum set of privileges needed to do their job.  If you want to go to
sleep, you can read more about this issue in some rantings I recently
published [FRA00] (also in the latest LOMAC tarball).  I suspect that
TrustedBSD is more interested in quality of protection than compatibility,
so I will list LWM's good and bad points (as I see them) and let you
decide whether or not to investigate further.

On the good side, LWM will give you a solution that is largely invisible
to the user: the user will never have to choose a "role" or "level" or
"domain" from a list - that's all done automatically by the kernel.  LWM
will also provide useful protection in a default configuration, allowing
you to ship a "one size fits all" system that does not have to be
reconfigured to work at a given local site.  On the bad side, LWM compares
very poorly with Type Enforcement (TE): you may find yourself relying on
trusted programs with LWM.  LWM is also not as good as TE at confining
programs to precisely the minimum set of privileges they need to do their
`job.  It's probably worth noting that Biba's strict integrity model
shares these bad points, and that it may (or may not) be possible to
improve LWM by adding partially trusted subjects [LEE88] and integrity
categories [LIP82].

I suspect that the Chinese Wall (CW) model [BRE89] would share the good
points of LWM.  You may want to look at Simon Foley's paper about CW on
UNIX [FOL97].

rw> In a low water-mark model, I think it would be desirable to have
rw> changes propagate fairly quickly, or you lose the benefits of the
rw> scheme.  I.e., is a subject touches a low-integrity object, you would
rw> like to it to lose write access to high integrity open files.  This is
rw> one of the downsides of a scheme allowing floating labels :-).  In
rw> environments with entirely static labeling, revocation is not an
rw> issue.

Revocation isn't necessarily an issue in environments where subjects can
change privilege sets.  Neither LOMAC (implements LWM) nor DTE (implements
TE) implement capabilities with revocation.  Both of these systems compare
the attributes of the subject and object every time they make an access
control decision.  This method runs fast ("if( foo > bar )" doesn't take
too many CPU cycles), and makes correct decisions without having any kind
of complex revocation scheme.

rw> In a floating label system, such as Tim's LOMAC, IPC objects such as
rw> pipes between processes need special handling to retain their
rw> usefulness,

This is true, but...

rw> or all processes in a pipeline lose integrity as it works
rw> its way up.  Which is correct according to the model, but impractical
rw> in real-world systems, where it is desirable to handle streams of
rw> terminal data as unlabeled despite labeling the pipes they pass
rw> through.

I suppose this (not mediating the use of unnamed pipes) is a solution, but
it is not the solution used by LOMAC.  The problem with LWM and unnamed
pipes is as follows:  imagine a low-integrity file "F", and a pair of
high-integrity processes "P1" and "P2" connected by an unnamed pipe "|".
We might diagram this situation like this:

             F(low)      P1(high)      |(high)      P2(high) 

Imagine that P1 reads from F.  According to LWM, this will decrease P1's
integrity to "low":

             F(low) -r-> P1(low)       |(high)      P2(high) 

Now, when P1 tries to send data to P2 by writing to the pipe, LWM denies
the write because P1 is low-integrity and the pipe is high-integrity:

             F(low)      P1(low) --w-X |(high)      P2(high) 

No data gets through the pipe to P2.  I saw this situations many times in
the early LOMAC prototypes, when I would execute "ps auxw | less" at a 
high integrity level.  "ps" would read some low-integrity parts of the
/proc filesystem, get demoted, fail to write to the pipe, and "less" would
show a meaningless lack of output.

The solution described in [FRA00] involves treating all the members of a
process group ("job") as a single subject, so the demotion of one member
process causes a demotion for them all.  So, in our example, when P1 reads
the low-integrity file, both P1 and P2 are reduced to low-integrity
simultaneously:

             F(low) -r-> P1(low)       |(no level)      P2(low) 

In the [FRA00] solution, reads and writes to unnamed pipes are ignored,
although LOMAC enforces special constraints to make sure that unnamed
pipes are used only by memebers of the same process group.  Since the
entire process group is now low-integrity, the data transfer through the
unnamed pipe works fine:

             F(low)      P1(low) -w--> |(no level) -r--> P2(low) 

This solution worked fine with pipelines created by shells, but had some
problems with the way some cron jobs use unnamed pipes.  The latest LOMAC
pre-release experiments with a slightly different solution that does
provide levels for unnamed pipes.  However, in both solutions, the
transfer of low-integrity data via unnamed pipes does indeed reduce the
integrity of reading processes in LOMAC.  Unnamed pipes are used so
frequently in UNIX, it would be a shame to not mediate them.

I hope this helps!

				- Tim

[BRE89]  Brewer and Nash, "The Chinese Wall Security Policy," IEEE
Symposium on Security and Privacy, 1989.

[FOL97]  Foley, Simon, N., "Building Chinese Walls in Standard UNIX,"
Computers and Security Journal vol. 16 no. 6, December 1997.

[FRA00]  Fraser, Timothy, "LOMAC: Low Water-Mark Integrity Protection for
COTS Environments," IEEE Symposium on Security and Privacy, 2000.

[LEE88]  Lee, T. M. P., "Using Mandatory Integrity to Enforce `Commercial'
Security," IEEE Symposium on Security and Privacy, 1988.

[LIP82]  Lipner, S. B., "Non-Discretionary Controls for Commercial
Applications," IEEE Symposium on Security and Privacy, 1982.


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message