Re: [audit] Upstream solution for auditing file system objects

[Jan Engelhardt]

>> Some notable design problems to introduce now are with the "identity"
>> of Y file/directory with respect to the kernel.  In fact, we only
>> really care about paths of which file/directory Y completes.  I.e: If
>> we want to audit /etc/shadow, we might not care if /etc/shadow is
>> moved to /tmp/shadow.  This means that any access/alteration of
>
>Of course you would.  A mv to /tmp/shadow includes an unlink, which
>should be an auditable event.

Does it really? If /etc and /tmp reside on the same filesystem, only a rename()
is done as to my knowledge (and possibly, an fs-specific rebalance). And if
they are on the same fs, they might even keep the inode number.

>> /tmp/shadow would go unnoticed (unless otherwise specified).  However,
>> if /tmp/shadow were a hardlink to /etc/shadow, we would then still
>> care, because we are still effectively /etc/shadow... if that makes
>> sense :-)

(Your mentioning of hardlinks proves my assumption of you having /etc and /tmp
on the same fs.)


Jan Engelhardt
-- 
ENOSPC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/