Re: [Audit-test-developer] [design] How to write / run / audit syscall wrappers?

[Jiri J. <jja...@re...>]

On 08/04/2014 10:08 PM, Linda Knippers wrote:
> On 8/1/2014 8:11 AM, Jiri Jaburek wrote:
>> I made some proof-of-concept attempts regarding the automatic build of
>> only relevant syscalls and I'm not sure anymore whether it's a good
>> idea. The thing is - it's too "smart", which would be beneficial for
>> something like LTP (which has TCONF), but not really for our suite,
>> where we want things to be as static as possible.
>>
>> IOW the way I understood it, we don't have any advanced output-checking
>> logic that would guarantee that all the required/expected syscall tests
>> were run - this is guaranteed by the (static) logic itself.
> 
> Right.  I think you'd have to start with a static list but you could automate
> the build of the tests for the calls on that list, but the static list would
> still have to know about the weirdness for different arches.
> 
> Our static logic presumes that someone has looked at all the system calls
> and determined that all that are necessary are actually covered.  If we
> were generating something automatically, we'd probably want to check against
> a whitelist of system calls we know we need to include, a blacklist of system
> calls we know we don't need to include, and if there are any that aren't on
> either list - that should generate a warning.
> 
>> Using a static list both as a replacement for utils/bin/Makefile and for
>> execution/auditing could work, but I'm not really sure of its format
>> and whether it wouldn't go against KISS. Meaning that, sometimes,
>> leaving things in apparent disorder might be the best solution.
> 
> At least we understand our mess. :-)
> 
>> The implication being that I'll stick with (B), eg. using library
>> functions where possible, ie. fstatat() instead of newfstatat(), etc.
>>
>> This also means that I can finish that ipc/socketcall patchseries,
>> I'm still undecided whether to do it network-style (add ie. do_msgget,
>> call it, but audit syscall==ipc on related arch/modes) or whether leave
>> do_ipc in place and just make it a special case (calling bodies of the
>> "normal" do_* ipc wrappers) instead of a feature.
> 
> The special case is more like it is now?

I wanted to make all the ipc-related wrappers standalone, ie. more like
all the other wrappers (do_socket, do_bind, etc.), with do_ipc being
a "special case" that can use various hacks and tricks to call ipc(2),
but these hacks would be confined to do_ipc.c.
Hacks like doing execve() on the standalone wrappers (ie. do_semget)
or like (more cleanly) making the standalone wrappers module-friendly
(python like) and omitting the main() when included into do_ipc.c.

Though I'm not sure whether any of this would be worth
reviewing/including as it doesn't improve the situation by much.

My current plan is to make a new augrok_ipc function in syscalls/,
which would differentiate between various architectures/modes, and use
this function in run.conf of syscalls/, eliminating the in-place
conditions along with do_ipc and do_socketcall. This makes more sense
to me, since we need these conditions only for auditing purposes.
This is essentially what network/, trustedprograms/, etc., do.

For that to work, I need to sort out other problems first, though.

> 
> -- ljk
>>
>> Jiri
>>
> 
> 
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Audit-test-developer mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audit-test-developer
>