According to Perry E. Metzger:
>
>I've been thinking about this, and I'm far from sure this whole scheme 
>is going to provide any real security. It may add a lot of complexity, 
>but in the end, I'm far from sure its a win.
>

I have been thinking about it too in the light of the comments I have
received.  I am not totally convinced the idea is a turkey yet but
there are some issues which I think do have a bearing:

  * A working ETXTBSY would mean that running binaries could not be
  overwritten.

  * If the signatures for the file system being mounted are put in a
  file either a) on the file system or b) in the directory that is the
  mount point then the mount command could exec a program that loads
  the signatures into the kernel if the appropriate mount flag is
  given.  This ties the signatures to the file system neatly.

  * A system of distributing a trusted copy of the signatures would be
  useful.  What form that takes I don't know - I am not that familiar
  with the mechanics distributing encrypted software bits.

I do not believe what I have done is complicated at all.  The kernel
code is quite simple and with caching of the signatures the real
impact is about 3% (i.e. doing a make on a kernel too 3% longer with
the signing on) - I have not done a measurement that includes the
comparison of the loaded signature against the calculated one but I
don't expect that the impact will be much greater - especially if the
in-kernel loaded signatures are sorted.

I strongly believe that trying to lock down a system with immutable
flags is going to be much harder to reliably achieve.  Doing a
chflags(1) on all the executables is just the start, you would also
need to make a lot more files immutable - even down to the
.cshrc/.profile/.login files to ensure things like PATH have not been
modified.  With my scheme if PATH was manipulated to try and run a
trojan it simply would not run.  This is what I mean by validating the
TCB (Trusted Computing Base).  Sure, tripwire can do the same thing
but with some riders:

1) Securing the tripwire database is more problematic because the file
is referenced by userland code - you can make the file immutable which
will address this but you still need to be very careful that the file
you think you are access is actually the file you are accessing.  With
my scheme if you put the signature file under the mount point then it
would be very difficult to manipulate the file without unmounting the
filesystem.

2) With tripwire there is always a tradeoff between the frequency of
running it against the load on the machine.  You cannot run tripwire
too frequently without loading up the machine.  With my scheme the
signature is evaluated automatically on exec - there is no need to
check binaries that are not run, the result is cached in the kernel so
further execs do not re-evaluate the signature.  Being in the kernel
we can invalidate the cached signature if the file is modified or
shifted.  Tripwire must evaluate the signatures on each run.

There is also the issue of stopping people running binaries.  You can
do this in a relatively crude manner with a noexec flag on mount but
there are some cases where conflicting requirements on the file system
will break this.  An interesting one that springs to mind, not that I
would expect this to be an issue, would be running dhclient(8) to set
up the ip address (you REALLY would not be doing this on a firewall
but it's an example of a conflict).  You see, dhclient(8) writes and
runs some shell scripts from /tmp - if you have mounted /tmp noexec
then it will break dhclient(8).  My scheme would allow the scripts to
run if the securelevel was appropriate.  This is just a simple
example, life gets much more complicated when you try the same trick
with something like INN - just splitting that monster into read-only
and read-write sections was a headache.

I do acknowledge that any interpreter can be made to run a modified
script by bypassing the exec.  There are two answers to this:

1) The attacker needs to convince some(thing|one) to execute the
modified script in a different manner to normal.  I doubt many people
run their shell scripts by typing "sh xxxxx" by habit.

2) If you leave tools lying around that can be used against you then
you should not complain when they are used against you.  If you leave
tcpdump available on your system then you cannot complain if an attacker
uses it to sniff your network.  The same applies to perl/tcl/whatever,
these may be useful tools but the risk of having them available on
your system needs to be carefully evaluated.


Finally, the modifications I have made are completely optional and
need to be configured into the kernel - I certainly would not
recommend it for a standard build, there is no need to have the exec
checking there except for certain classes of machine
(e.g. firewalls).  I do believe that what I have done is a useful
adjunct to other measures that help providing a more secure system.
After all the discussion that has happened I am thinking I shall back
burner the idea for a while so I can think more about the suggestions
and criticisms of what I have done.  I may change parts of what I have
done to make things work better.  Like I said before I am not
convinced that using the current tools available to get a similar
level of security that is provided by what I have done is tenable -
locking down the machine properly is very involved and if you don't
get it 100% you lose.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================