[RFC][PATCH] audit: log join and part events to the read-only multicast log socket

[LC Bruzenak]

On 10/22/2014 01:18 PM, Eric Paris wrote:
> On Wed, 2014-10-22 at 10:51 -0500, 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.
>> ...
> >From the PoV of the process in question there was, at some point, A
> path.  That I agree with.  But imagine I clone a new mount  namespace
> and don't share my changes with the parent namespace.  Now I mount
> something new in that child namespace.  What is A path for a file in the
> new mount?  From the parent namespace there is NO path, ABSOLUTELY NO
> PATH.  (guess which mount namespace auditd lives in, by the way).  From
> the PoV of the processes in the child mount namespace there is A path,
> but it's possibly/probably completely meaningless to the
> admin.  /etc/shadow != /etc/shadow the admin cares about...  readlink()
> doesn't work in this case either.  Sometimes there just plain is no
> path.  So yeah, I'm betting MOST of the time we can come up with A path,
> but that's not exactly what you want either   :-(
OK; interesting case. Now I hate namespaces.
:-)

Perhaps we'll have to get smarter in order to be able to work backwards
through namespaces.
Or if not solvable, maybe some of us will have to decide to not allow
ad-hoc mounted namespaces. Just saying. This stuff matters.
I'm assuming we get the namespace info in userland audit events? My
RHEL6 versions are behind where you guys are...
>
>>>> 9) Can we get events for a watched file even when a user's permissions do not
>>>> allow full path resolution?
>>> No.
>> No?
> Say I set a watch for failure to open /path/to/my/file.
> If someone comes along and says open(/path/to/my/file) but they do not
> have execute permissions on /path/to/ their request will be denied.  Not
> because they didn't have permission to open /path/to/my/file, but
> because they didn't have permission to open /path/to.  Watches do not,
> and can not, emit a rule for that.  The rule you requested (failure to
> open /path/to/my/file) was not violated.  The kernel did not try to
> open /path/to/my/file.  It tried to open /path/to/ and died right there.
> If you care about things being unable to open /path/to/, put a watch
> on /path/to (although I'm not 100% such watches actually work, but at
> least the theory is right and maybe that could be fixed)
I didn't match the "no" answer to what I read to be a more general question.
Per the STIG (& added) rules there are exit watches for EACCES and
EPERM, which IIUC would be caught in your example. Not all the way down
to the end of the path but to the point of failure. Good enough.
So I probably misinterpreted the question. Your answer cleared it up
nicely; thanks.

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny at magitekltd.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2193 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20141022/b4ea74ef/attachment.p7s>