Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
On Wednesday, October 22, 2014 10:51:49 AM LC Bruzenak wrote:
On 10/22/2014 10:12 AM, Eric Paris wrote:
> On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote:
>> 1) For the *at syscalls, can we get the path from the FD being passed to
>> be
>> able to reconstruct what is being accessed?
>
> You might sometimes be able to get A path. But every time anyone ever
> says THE path they've already lost. There is no THE path. There might
> be NO path. Every single request with THE path is always doomed to
> fail.
IIUC we've got to have some assurance that the path is legit for forensics.
Technically I believe I understand and concur with what you are saying
Eric, but as a guy on the far end of the process I know I need to be
able to reference a complete path to a FD.
One which we believe did exist at the time the mod occurred. To me,
sometimes isn't really good enough. But A path probably is.
...
The thing is, that if an fd is open, there is an entry on
/proc/<pid>/fd/<number> that you can use readlink on to get the path. So, if
/proc has the info to show the outside world, why can't it be accessed from
inside when needing it for an audit event?
>> 9) Can we get events for a watched file even when a
user's permissions do
>> not allow full path resolution?
>
> No.
No?
There are requirements that say audit should send notification on the attempted
access in both success and failure scenarios. It doesn't say when convenient.
-Steve