On Tue, 22 Jun 1999, Brett Lymn wrote:

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

A bit tangential:

A working ETXTBSY would be REALLY NICE to have for not only binaries,
but I'd like to see it available for scripts as well.

[I'm assuming that ETXTBSY means that write on a file being read will
 fail, and read on a file being written will fail.]

I've always wanted a parameter to a system call to force ETXTBSY on
a file in that manner...

Back on topic, this sort of thing looks as if it could qualify for
C2 inasmuch as it attempts to establish a trusted computing base.
The difficult part about achieving C2 under *X is that there is no
set of keystrokes that only the kernel sees which cannot be mapped
by a userspace program.  Of course, I'm sure people will be quick
to point out that if we want NT, we know to whom to sell our soul...

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

What kind of signatures are you intent on storing, and is this where
you'd keep the filehandle information?

Would there be any benefit to using one of the remaining fields in an
inode for signature information?

# There is also the issue of stopping people running binaries.

Ah.  You don't want them to be able to run their own programs?
This seems a bit ... er, Draconian, don't you think?
[reading ahead to the firewall bit, I understand it a bit better.]

# 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.
[example: dhcp; deleted]

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

Hi.  I do this frequently, especially in the course of debugging them
or finding out what they do [sh -vx].

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

which is why it's typically only runnable by a super-user.  If you really
don't trust someone sniffing your network, run encrypted.  It's slower,
to be sure, but you gotta trade somewhere.  If you have sufficient encryption
that the keys change once every so many minutes, a sniffer's not going
to stand a very good chance of figuring out the algorithms in use.

There are ways of doing multilevel proxy encryption on something like
tcpdump such that it, itself, might be passworded; maybe force attaches
to interfaces to automagically generate a yellow flag to force encryption.

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

...on which you wouldn't have user accounts, per se, anyway.  A
firewall is a pass/filter mechanism which should have no other
functionality than what is needed to ensure internal security.  A
firewall with user accounts is a hole waiting to open.  Tcpdump
from a firewall can eventually become lethal in experienced hands.

# locking down the machine properly is very involved and if you don't
# get it 100% you lose.

Ain't THAT the truth.

				--*greywolf;