Ranum writes:
> It's possible, I suppose, but if you're dealing
> with that kind of level of effort it'd be easier
> to just hack the kernel to not see or remap certain
> files.
To "modify the open() routine in the C library" is not to "just
hack the kernel." The kernel is distinct from the C library.
> I know for a fact that tools exist which allow
> a hacker to modify the open() routine in the C
> library, so that if a program like tripwire tries
> to open a file for read, it actually opens a copy
> of the original file, and causes a failure if the
> original file is opened or stat()ted directly. This
> causes the file to be invisible to tripwire and to
> check out OK.
Something is missing here: how is "open a file for read" to be
distinguished from "open(ed) ... directly" if the only API
available to programs is open() operating upon a user-visible
pathname?
How will you deal with symbolic links? Anyone can make a symbolic
link to any file, as long as that person can search the directory
in which the file resides, and the pathname mapping [analogous to
the API readlink() function] would be performed by the kernel, not
by C library functions.
How will your magic open() function deal with hard links to files?
Will it track down each link dynamically each time a file is
opened? This will impose non-negligible delays, to say the least.
Lumping the stat() thingum into the open() solution is a bit
parochial. One can also stat() files given only a file descriptor.
In that case, pathname-based mechanisms are useless.
> That's a lot of work for an attacker to go through,
> though.
Modifying a single library does not seem like a lot of work for an
attacker to go through.
Follow-Ups:
|
|
