Brett Lymn <blymn@baesystems.com.au> writes:
> 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.

I'm not sure that there actually *is* anything better you can do here,
thus my comment that I suspect chflags may be sufficient.

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

I have to admit I don't understand the distinction. You can choose not
to have a file executable, and you can set the immutable flag as
easily as you can add a fingerprint.

OTOH, having the code path you've opened up might have some
interesting other possibilities to it I've been thinking of.

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

Yes, you could, but this seems like a contrived idea -- there are
likely simpler ways to accomplish such things, including simply
chmoding the file and setting it immutable before raising the secure
level.

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

Well, yes, if the immutable flag code is buggy you won't get
confirmation, but your code is buggy the same is true.

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

chflags the login scripts for root to be immutable.

Anyway, I do want to note that I don't think your work is useless here
-- just that I'm no longer sure that the original intended use is as
interesting as I once thought.

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

-- 
Perry E. Metzger		perry@piermont.com