stjude-project Mailing List for Saint Jude

On Fri, 11 Apr 2003 ca...@po... wrote:


Its still being maintained, but not updated. If
you can provide information on what your seeing
on your end, and the Makefile.in your using,
I will track down whats going on.

--Tim

> 
> Greetings,
> 
> I've been looking at StMichael.  It looks pretty
> nifty.  In trying to get it running with a 2.4.18
> (RH) kernel, I discovered a few bugs and other 
> oddities.  Is this code still being maintained?
> I hate to see it get too dusty.  I doubt I could
> offer any improvements, but I may be able to help
> keep it up to date.
> 
> I would like to discuss some of the changes, to
> see how valid they are.  It seems to work okay.
> I tested it with suckit 1.3b and it appears
> to be doing the right thing.
> 
> --Shane
> 
> 
> 
> ------------------------------------------------------------------------
> Shane Canon                             voice: 510-486-6981
> PSDF Project Lead                       fax:   510-486-7520
> National Energy Research Scientific
>   Computing Center                       
> 1 Cyclotron Road Mailstop 943-256
> Berkeley, CA 94720                      ca...@ne...
> ------------------------------------------------------------------------
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> stjude-project mailing list
> stj...@li...
> https://lists.sourceforge.net/lists/listinfo/stjude-project
> 

-- 
Tim Lawless     Email:  [ la...@ww... ,  la...@ne... ]
GPG Key: http://www.wwjh.net/~lawless/gpgkey.asc 
GPG Fingerprint: 2764 E9CA BE7F 7876 95CB 6249 37EB FD88 20F5 8047

Greetings,

I've been looking at StMichael.  It looks pretty
nifty.  In trying to get it running with a 2.4.18
(RH) kernel, I discovered a few bugs and other 
oddities.  Is this code still being maintained?
I hate to see it get too dusty.  I doubt I could
offer any improvements, but I may be able to help
keep it up to date.

I would like to discuss some of the changes, to
see how valid they are.  It seems to work okay.
I tested it with suckit 1.3b and it appears
to be doing the right thing.

--Shane



------------------------------------------------------------------------
Shane Canon                             voice: 510-486-6981
PSDF Project Lead                       fax:   510-486-7520
National Energy Research Scientific
  Computing Center                       
1 Cyclotron Road Mailstop 943-256
Berkeley, CA 94720                      ca...@ne...
------------------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 2 Apr 2002, 4lj wrote:

Hey!

> Hi, all.
> 
> I found a little problem in delete module process.
> First, it isn't check delete_module_return in sm_delete_module().
> if non-root user type "rmmod foo", original delete module function
> returns -EPERM. So after sm_remove_module_list() destory module 
> list integrity. it should be check delete_module_return.
> 	
>    if (delete_module_return == 0)
>      sm_remove_module_list();
> 

Ouch. I have patched the CVS with this one. I will include it
in a interum patch, along with other changes by friday.

> 
> Next, if anyone unload StMichael.o, current implementaion
> returns -EBUSY. In the case compiled with CLOAK option,
> it is better to return -ENOENT.

Intresting issue, I have modified your solution to
actually shortcut out the "StMichael" check if
CLOAK is defined. In playing with this just now, 
in cloak mode it is possible to actually load another
module called "StMichael", and not be able to remove it.

Test: insmod StMichael.o
      mv StMichael.o StMichael.old.o
      cp /lib/modules/`uname -r`/kernel/drivers/net/dummy.o StMichael.o
      insmod StMichael.o

Since the Cloaking causes the module entry for StMichael to
be removed -- its name may be loaded again. 
Attempting to remove it would generate a "-ENOENT"
when we can do an lsmod and see the module is there.

I have modified your fix to read as follows:

#if defined(CLOAK)
   if (name != NULL && *name != '\0')
   {
   if ( ! sm_strncmp(name,"StMichael", 12) )
      {
          return -EBUSY;
      }
   }
#endif	


Thanks,

- --Tim


PS. I am trying to move this project to being more community
    supported. I will be posting information about where patches
    will be posted. I hope to be able to do at least weekly patches
    for smaller issues untill I have a chance to get a CVS setup
    for this project (on a site other then sourceforge).

- --
Tim Lawless     Email:  [ la...@ww... ,  la...@ne... ]
GPG Key: http://www.wwjh.net/~lawless/gpgkey.asc 
GPG Fingerprint: 2764 E9CA BE7F 7876 95CB 6249 37EB FD88 20F5 8047

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8qSunN+v9iCD1gEcRAu9DAKDfouLzGCVae3LyrAzWnbJGx/899wCeOemI
wRocPhV7mQBXZmKwuoyiW5c=
=PSqT
-----END PGP SIGNATURE-----

Hi, all.

I found a little problem in delete module process.
First, it isn't check delete_module_return in sm_delete_module().
if non-root user type "rmmod foo", original delete module function
returns -EPERM. So after sm_remove_module_list() destory module 
list integrity. it should be check delete_module_return.
	
   if (delete_module_return == 0)
     sm_remove_module_list();

   /* misc. integirty check... */


Next, if anyone unload StMichael.o, current implementaion
returns -EBUSY. In the case compiled with CLOAK option,
it is better to return -ENOENT.

   if (name != NULL && *name != '\0')
   {
   if ( ! sm_strncmp(name,"StMichael", 12) )
      {
#if defined(CLOAK)
	 return -ENOENT;
#else	      
         return -EBUSY;
#endif	      
      }
   }	

Good Day.

I have configured this list for announcements, discussion of issues,
submittal of requests/patches/questions pertaining to StJude -- and
general discussion about system survivability and intrusion resiliency
in general.

What is Intrusion Resiliency?

Intrusion Resiliency is a term that describes a system's ability to
detect an intrusion, and automaticly respond in such a way that the
system is able to restore its integrity and continue opperating, even
if with some degredation in performance. In this respect, the system 
becomes self-healing in the light on a penetration.

Intrusion Resiliency contrasts to Intrusion Containment, the 
stratagey of setting up compartments, jails, or virtual sub-systems, in 
which an intrusion is limited to contaminating only a contained part of
a whole system. The contained intrusion is then responded to manually,
or the contamination is removed by eliminating the contaminated 
compartment and replacing it with a fresh/clean copy of the compartment.

Kinda neat idea eh? I though so too.


--Tim