Re: Q on audit, audit-syscall

[Kyle Moffett <mrmacman_g4@mac.com>]

On Apr 5, 2006, at 09:50:17, Herbert Rosmanith wrote:
>> On Apr 5, 2006, at 08:06:30, Herbert Rosmanith wrote:
>>> as I said, "ptrace" is not an option.
>>
>> Why not, exactly?  (No, we don't know why).
>
> according to the man-page:
>
> RETURN VALUES
>      EPERM   The specified process [...] is already being traced.
>
> this makes it unusable for me.

Please stop being unclear and describe _exactly_ what you want to do;  
otherwise it's impossible to help you.  You want to trace and  
intercept syscalls, no?  It implicitly doesn't make any sense to try  
to trace and intercept syscalls from one process in more than one other.

>> ptrace is _the_ Linux  mechanism to trace and intercept syscalls.   
>> There is no other way.
> "there is no other way": [1,2,3,4]
>
> [1] http://www.uniforum.chi.il.us/slides/HardeningLinux/LAuS- 
> Design.pdf
> [2] http://www.usenix.org/publications/library/proceedings/als01/ 
> full_papers/edwards/edwards.pdf
> [3] http://www.citi.umich.edu/u/provos/papers/systrace.pdf
> [4] http://www.nsa.gov/selinux/papers/freenix01.pdf

It looks like you solved your own problem, then!  Feel free to use  
any one of those.  The only commonly-available mainline mechanism to  
_trace_ and _intercept_ syscalls is ptrace.  If you happen to be  
looking for how to implement extra process security checks, might I  
suggest looking at Linux Security Modules?  On the other hand, I  
think LSMs may never even see some requests if they fail access- 
restrictions before calling into the LSM.  I believe there's  
documentation on them in the linux/Documentation dir of your copies  
of the linux sources.

Cheers,
Kyle Moffett