I read in Tanenbaum's book about operating systems that there are protection rings and ring 0 belongs to the kernel. Is it in general that one may say that "kernel modules handle the I/O and memory management of ring 0" or is "kernel module" specific for linux and not applicable for example for OpenBSD and MULTICS?
The ideas presented by Andrew Tanenbaum are usually not directly applicable to Linux (or any traditional monolithic Unix kernel). The answer to your question is much simpler than you are suggesting: a Linux kernel module is kernel code that has been compiled and linked into a separate file, instead of being linked into the kernel image. This separate kernel object file (.ko) can be loaded into the kernel address space, on demand, at run time. Practically all the drivers that can be compiled as kernel modules can also be statically linked into the kernel image, without any difference in functionality once code has been loaded.
The module code is kernel code and it runs with the same privilege as all other kernel code. A kernel module can in principle replace any kernel code, but to do so cleanly the kernel proper must provide a mechanism for the module to hook into.
A side note on terminology: Protection Rings is a concept introduced with the Multics operating system. "Ring 0" to "Ring 3" are terms that are specific to Intel processors. Other processor architectures use other terms, like User/Supervisor mode. Although Intel processors provide four different levels of privilege, most operating systems have only used two: Ring 3 for user level code and Ring 0 for kernel code, mirroring the User/Supervisor modes of other processors. (The exception is OS/2, which used three levels of privilege.)
The privilege level concept has been expanded lately with the advent of hardware level virtualization technology. For example, the ARM architecture defines three privilege levels: User, Supervisor and Hypervisor. Jokingly, it has been said that finally four rings are used on Intel-based machines: Ring 3 for user level code, Ring 0 for (virtual machine) kernel code, Ring -1 for hypervisor code and Ring -2 for SMM mode.
The concept of kernel does not apply to all operating systems. It is widespread but exactly how to apply it to a particular system can be a matter of debate.
In the case of multiprogramming systems where programs are isolated from each other, there is a precise definition of the kernel: the kernel is the part of the system which has access to everything. The kernel is the part that isn't isolated. The role of the kernel is at least to provide the isolation mechanism, but it can do more. In a traditional Unix kernel architecture, which includes Linux, the kernel also contains hardware drivers, network protocols, filesystem drivers, etc.
On most systems, the isolation between running programs relies on hardware features (processor privilege modes, memory management unit). The kernel is then the part of the system that runs in the processor's highest privilege mode, the mode where the privileges of the whole system can be controlled. On x86 processors, this mode is called “ring 0”; note that “ring 0” is x86 terminology, not a general concept. The general concept is called “kernel mode” or “privileged mode” or “supervisor mode”.
The statement “kernel modules handle the I/O and memory management of ring 0” doesn't make sense. The kernel, as a whole, handles memory management (at the level of deciding which process owns which memory and at what address it accesses it) and I/O (at the level of copying data in and out of peripherals). The kernel, as a whole, runs in the processor's kernel mode, which is ring 0 on an x86 processor.
A kernel module is a part of the kernel which is loaded after boot time. The only difference between a module and boot-time code is how it's loaded. Code in a kernel module runs at the same level of privileges as kernel code loaded at boot time and can perform the same functions (any code that can be loaded as a module can also be included in the boot-time image). Many modern Unix systems have kernel modules, including Solaris, *BSD, Linux, etc.