Re: How to get full pathname from an inode?

jesse@cats-chateau.net

On Thursday 24 July 2003 15:23, Valdis.Kletnieksat_private wrote:
> On Thu, 24 Jul 2003 13:26:02 EDT, Omen Wild <Omen.Wildat_private>  said:
> > Think of it as a kind of runtime TripWire.  I realize there are a bunch
> > of issues dealing with database integrity and kernel integrity, but we
> > are not quite ready to talk about how we have solved those yet.  In a
> > couple weeks we will go public with the project and that part will make
> > sense.
>
> This may not add as much security as you might think.
>
> Let's analyze the basic concept here - you're trying to protect against
> modification of binaries.  Now there's two basic possibilities:
>
> 1) There is no channel/hole/backdoor for the attacker to modify the binary
> before use.  In this case, the check is pointless. For example, if the
> attacker can't modify /bin/login, checksumming the binary doesn't matter.
>
> 2) The attacker has a way to modify the binary - exploiting some SUID
> binary, a hole in /proc, scribbling a block on /dev/hda, whatever.  The
> check is then somewhat useful for catching modified binaries before use.
>
> However - if the attacker is able to identify that your system is in use,
> it's simple enough to launch the binary and exploit the race condition -
> you are doing a check *at execve() time* - and there's no real guarantee
> that the pages you checksummed are *STILL* the pages that actually get
> executed...
>
> There's also a rather nasty race condition in the time between when the
> binary itself gets started by exec(), and the runtime loader resolves all
> the shared libraries and you actually get to main().....

Drat. I should have rememberd those too...

There is also the possiblility that the contents get replaced even after
the execution reaches main... If the pages are "suitably" replaced before
they are pagefaulted in during execution then there is/are problems. Ditto
with the shared libraries (it's easier here since "busy" binaries with the
main are frequenty unwritable).

I've unintentionally done this just by rebuilding the program/library.

This is a bigger problem for network filesystems than local filesystems.

Now one way around this is to copy the binary into swap, checksum it, and
keep all pagefaults for the program to the swap file. There is STILL the
possibility that the attacker has access to the swap area...

You also have to enforce another thing.. any program that is checksummed must
also have EVERY shared library that it references verified also.

It would be MUCH simpler to have the binaries on a read only CD, or if it is
a CD R/RW, in a drive that can only read... (do they exist anymore?...).
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module