Hook test

jmjonesat_private

On Thu, 5 Jul 2001, Chris Wright wrote:

> * jmjonesat_private (jmjonesat_private) wrote:
> >
> > Isn't that what Chris is for? (^_^)
> > 
> 
> heh ;-)  that is what this list/project is for.  commiting code changes
> does mean a healthy dose of testing, and watching out for lonely lost
> hooks.  any additional testing tools would be helpful.
>

*G*, j/k (mostly :))

I apologize for the mailbox clutter, but I've attached a
"first-draft-rough-banged-out" LSMTEST-API description as 
one way we can see to go with regard to a test module that 
userspace testers can use to get the job done.  Anybody who's
interested is invited to tear it apart before I invest too 
much time going down the wrong road.  

Feedback Appreciated,
J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

LSMTEST-API (Option Using the /proc filesystem...)

/proc/lsmtest-api  is a virtual file (multiplexed by PID of read/writer) and  
                   organized as follows:

[VERSION INT]	Changes if the module changes.  Read always successful.
                Write never changes it.

[CONTROL INT]	 0  = SET 	Create structure associated with calling PID
                 1  = GO	Start Trapping for PID. 
                 2  = STOP	Stop Trapping for PID.
		-1  = RESET	Delete structure associated with calling PID
		-2  = MASTER    Resets EVERYTHING to recover a stuck module.

[TRAP ARRAY ]   An array of structures as follows:

                typedef struct {
			int	control;
  			int	retval; 
		}
		LSMTEST_TRAP;

                control ==  -1	No trap set.
                control ==   0	Trap set.
                control ==  >0 	Trap was triggered this many times.

                retval		Value to be returned when the trap
				is sprung. [3]

		indexed according to hook (the offset of each and 
                the specific hook trapped will be provided).

GENERAL

1) Read [VERSION INT] and make sure your test app is compiled to 
   use the correct module.

2) Write a SET into [CONTROL INT].  If the write fails, the module
   is busy and can't support your request. [1] 

3) Write the traps the process is interested in to [TRAP ARRAY]. [2]

4) Write a GO into [CONTROL INT] to start trapping. [3]  

5) Perform some test operations.

6) Write a STOP into [CONTROL INT] to stop trapping.  [2]

7) Read the trap array elements you're interested in and see if they 
   were tripped and figure out your results. [2]

8) Repeat steps 3-7 as desired for other test suites.

9) Write a RESET into [CONTROL INT] to free up the module.

10) You're done, do your report or whatever and go away. ;)

NOTES:

[1]	The module may have too many PIDs already trapping to support
        another request.  Suggest retrying at 1 second intervals for 
        a decent amount of tries (maybe 30?) if desired.

[2]     It's possible that the module can get hit with a MASTER RESET
        to unstick it (if, say, test apps blow up and leave rubbish).
        Subsequent attempts to read or write from /proc/lsmtest-api 
        may mean you got reset... suggest restarting at step (2).

[3]	Since reading and writing to /proc/lsmtest-api would trigger 
        some traps, I'm looking at ways to "protect" those specific
        hook invokations from the results, allowing them to succeed
        even if a failure retval is returned in other cases.  Kinda 
        sticky, but necessary.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module