On Wed, Oct 30, 2002 at 09:26:34AM -0500, Perry E. Metzger wrote:
> 
> What prevents them from also altering the fingerprints?
> 

either chflags or ro media.  To be honest, this is part that needs
work.  The loading of the fingerprints is something I consider that
needs work to improve the security of the mechanism.

> To change the flags, you need to either bring things down to
> securelevel 0 or you need to get access to the raw disk in some other
> method. To change the fingerprints, you have the same requirements. It
> doesn't seem to me that there is a real difference.
> 

From an operational perspective, you are correct they both have the
same implications when it comes to updating.

> 
> So, again, why is this better/different from an immutable flag?
>

It is different to the immutable flag because just because something
is marked executable by the file modes does not mean that it will be
executed.  If the file does not have a fingerprint (or a matching
fingerprint) then the request for execution is denied.  Think of the
fingerprinting as being more a verification that what you intend to
run is what you are actually going to run (or read for that matter, as
this scheme can do the same for plain files).  It gives you a fine
grain control over what is able to run on the system, you do have some
other mechanisms for doing this but they do not have the fine control
this gives you.  You could, for instance, have a binary run before the
securelevel is raised but not have that binary available after
securelevel is raised simply by not having a fingerprint for that
binary.  The other thing that this gives you is visible confirmation
that the file is ok - chflags can only prevent the modification it
will not report if the file was modified or not.
 
> 
> I could do that with your stuff too though, couldn't I?
>

No.  Not unless the attacker was able to update the fingerprint list
too and reboot the machine.  No fingerprint, no run.

> The only way
> to stop that is to a) know your PATH and b) make all directories in
> that PATH immutable with chflags (or with your mechanism).
> 

Assuming noone changed your path.  There was an incident on a public
project server a while back where someone managed to change the login
scripts for root and install a backdoor setuid shell.  With what I
have done this, quite simply, would not have worked - they could copy
binaries to their hearts content but the binaries would not run.

Another thing that seems to have been missed is that this scheme can
make the distinction between a binary being invoked from the command
line and one that is being used as a shell interpreter.  You can set a
binary to be run indirectly only - that is, it can only be a shell
interpreter not be exec'ed directly.  This means that you can put,
say, /bin/sh as an indirect exec only - the shell scripts will still
run but the exploit scripts that smash the stack and exec /bin/sh will
be blocked.  This is a rather simplistic example and it could be
worked around by an attacker...if they knew where the login shells
were kept, I am not really advocating that as a big security feature
but it does make things more difficult for an attacker.

-- 
Brett Lymn