Having read the various trojan horse mechanisms using insmod, almost all of
them revolve around replacing a syscall. This would include the ability to
change the syscall used to load, check for, and unload modules.
It should be possible to write a 'modlock' program that inserts itself into
the module add, module delete, and module insert entry points. After
inserting itself, it copies the whole syscall structure into static memory.
Since this is a loadable module, the kernel only grows if the user decided
they needed this sort of protection and run 'modlock' as the last loadable
module.
>From then on, after every install of a module it checks if any of the
syscall vectors have changed. Have two loadable parameters (WARN_ONLY,
ADDITIONS_ALLOWED) and use these to determine what happens if after a module
install one of the syscalls has changed.
If a new syscall was added, you only worry about it if ADDITIONS_ALLOWED is
false.
If a change was detected and WARN_ONLY is enabled all you do is log it in
the system log. Otherwise, you would undo the change because it is assumed
to be unauthorized.
The same sort of checking needs to be put into removing a module, although
there all that should be allowed is removing a syscall.
I am not yet experienced enough with loadable modules to do the work. From
my readings, this should be doable and provide a way of at least detecting
the changed syscalls. No protection for anything else, but it would close
off the most obvious methods of attack.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/