RE: Kernel Security Extensions USENIX BOF Summary

steven_kramerat_private

Let me paraphrase the concerns I brought up at the LSM BoF last week.  The
main LSM thrust is to beat a deadline for 2.5.X kernels and get LSM approved
and integrated into those kernels.  Everyone is working diligently towards
that goal.
In my 20 years of experience porting security to mainstream UNIX-type
systems, the initial port is only half of the battle.  In the first port,
one is concerned
about the security architecture, optimum placement of the hooks, and other
aspects
of smooth integration.  The more challenging political problems come later.
Either the security team gets the main developers to adopt the security
hooks in
the mainstream code, or the porting continues anew, on the next rev of the
mainstream kernel.  

Unfortunely, most of the cases I've seen are the latter,
where the mainstream kernel developers ignore security, and leave it to the
security group to repeatedly re-integrate the same security hooks into the
kernel.
The only "challenging" work is when mainstream code changes.  This can be as
small
a change as an optimized version of a local routine, or as pervasive as
changing
from BSD sockets to STREAMS.  

The couple of times I've seen attempts to integrate security into the
mainstream
kernel after the initial port, I've not seen it succeed.  The average kernel
developer does not understand security, and it shows in the resulting
kernel.
Even those who try to "get it right" can fail in subtle, yet disasterous,
ways.
I've seen that on the larger rewrites, the security code is just missing.
The
same is true when new functionality is put in.  With it typical that
everyone is
under deadline, the sad choice for the security team is to 1) have the
security
hooks taken out of the mainstream kernel altogether, forcing the typical
security
port after-the-fact, 2) leave them in the kernel with an ifdef that is never
turned on in the production kernel (and forcing the same
after-the-fact-port), or
3) holding up the release.  This last option is political dynamite, because
the
security team is seen as holding the release.  (It appears the last in line
in a
release is typically the accused.)

Because I didn't read any of this type of discussion on the LSM list, I
brought it
up at the BoF.  Someone asked me what could we do to prevent this from
occuring
to LSM.  My response, after some discussion, was the best we could do was a
three-pronged strategy.  First, develop a LSM test module. (More on that
below.)
Second, diligence by the LSM group in making sure, as early as possible in
development, that the LSM hooks are preserved and also integrated properly
into
new code.  Third, this being open source development, some of the political
pressures found in closed software shops may not be as readily
counterproductive
to maintaining LSM hooks by the kernel developers.

The LSM test module I proposed has a dual purpose: 1) to ensure all the LSM
hooks
exist in the kernel, and 2) that they are called in the appropriate places.
The
LSM test module would need a small application to exercise it.  The LSM test
module is not intended to implement yet-another-security-module, but instead
to
aid in the integrity of the hooks.  My intention was that it be used by
developers of security modules, but also kernel developers.  At the present
time,
kernel developers have a reason for dropping or misplacing security hooks --
there is no tool or document that explains the purpose of the hook or helps
check
to see if it is invoked properly.  (Remember, some developers may throw up
any
flag they can to see LSM fail.  Others will just make mistakes in forgetting
about
security.)  Because of some reluctance in getting LSM
approved by the powers-that-be, I would think a test tool would mitigate
some of
those types of arguments.  (A LSM functional spec would also help, but I'm
not
going there [yet].)

Another reason for the test tool is to make test tools for the various
security
projects easier themselves.  That a LSM test tool validates security hooks
in
the kernel is one less test scaffold required to be written by the
individual 
security implementations.

The LSMExample module that jmjones is a start in implementing the type of
test
module I am describing.  With an appropriate "driver app", it provides
coverage
of all the LSM hooks.  Clearly, that would be useful as a first step in
future
kernel development.  What it lacks is a validation of the manner in which
those
hooks are called.  The a driver app for the LSMExample, as written, would
not 
distinguish if the LSM hooks were distributed throughout the kernel as they
are now, or if they were all bunched up in main().  The LSMExample module
needs
to have the ability to return multiple values (minimally 0,1 on straight
conditional hooks - maybe more on those returning other values) on those
routines
that can do so.  It's not enough for a LSM hook in a conditional to be
merely 
counted.  In other words, the mere presence of the LSM hook does not
guarantee
that is is invoked properly within the kernel.
The test tool needs to have the app/module validate rudimentary control
flow.  For 
example, one wants to validate that this hook (from kernel/sys.c) is placed 
correctly:

  no_nice = security_ops->task_ops->setnice(p, niceval);
                if (no_nice) {
                        error = no_nice;
                        continue;
                }

A simple counter would not detect the erroneous hook:

  (void) security_ops->task_ops->setnice(p, niceval);

The app would need to invoke nice(2) minimally twice, resulting in no_nice 
being 0 and non-zero so that the "if" code is tested.  The app would of
course
need to detect that the result from nice(2) corresponded with the expected
value.
(Similar discussion for detecting the hook in an incorrect place.)

Steve Kramer

> -----Original Message-----
> From: jmjonesat_private [mailto:jmjonesat_private]
> Unless I misunderstand, LSMEXAMPLE already pretty much covers 
> this need...
> every hook is intercepted and a count is maintained of how many times 
> each is called.  A simple revision can reduce that to a 
> vector as another
> result available to user-land.  
> 
> 

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module