Re: linux-audit: reconstruct path names from syscall events?
On 10/7/2011 6:50 AM, Eric Paris wrote:
Casey only talked about the easy part of the reason the pathnames
are
useless. He forgot to mention
I didn't forgot to mention the whole mount point thingy.
People always get hung up in coming up with ways to explain
around the problem, and having already identified the root
cause of the problem I figured we might avoid yet another
round of clever and convoluted arguments around identifying
mount points.
that the linux kernel has mount
namespaces. There is absolutely no reason why one could not mount a FS
in the init namespace, launch a whole 'virtual machine' in that new FS,
and then unmount the FS from the initial namespace. Now we have 2
COMPLETELY disjoint 'filesystems'.
You don't even need all this to demonstrate the problem. A simple
chroot (or worse yet, fchroot (do we have that? I forget)) gives
most audit tools the willies.
The audit logs, and things like /proc/pid/fd or dpath functions are
all
going to be relative to the local FS namespace. Sometimes it just quite
simply can't be resolved. So now inside virtual machine namespace they
might read/modify /etc/shadow and that file IS /etc/shadow. There is no
other 'path' for that file. True its not the same /etc/shadow as the
one in the init fs namespace. And at some point there may have existed
a path in the init namespace /mnt/virt1/etc/shadow which also
represented that inode, but at this point in time the ONLY path which
represents this file is /etc/shadow.
Audit logs based on name are wrong and misleading. There's a reason the
auditable object is the inode and fs details Casey mentioned. We might
be able to usually give me information, but that information cannot EVER
be used for anything useful. Its unreliable. Exposing it only leads
one to believe they have knowledge they don't.
The unfortunate reality is that audit requirements dating back to
the 1985 Orange Book clearly require audit be done by name. The
intent has always been clear that the name should be the name by
which people reference the object. We have been arguing that
providing the dev/inode pair meets the requirements for decades
now and only getting by with it by promising to provide mappings
to real pathnames.
The best you can do, and Irix(tm) did (does in some remote backwaters)
is report the dev/inode, the pathname requested and the pathname
resolved with indications of components that are symlinks and mount
points.
This is why there is value in pathname based access controls.
In many cases you don't care so much which object was accessed
as you do that the object is accessible using the name /etc/shadow.
Of course, once you say that, you really care about the object
because it may be accessed by other names as well and if you
care about the object named /etc/shadow you care about it regardless
of the name used to access it.
I would be delighted if someone came up with the fiendishly
clever solution to the issue. I am not going to bet on one
in my lifetime.
-Eric