I've been waiting all day for my post to be approved so I could post a retraction for Redhat Linux and its derivatives. :) It seems I forgot all about pam. Thanks to Mike Johnson of Redhat for bringing pam_limits.so to my attention. Any distribution that uses pam can set limits to prevent this. However, other distributions like Slackware and the default debian install still need some method to set the RLIMIT_AS limit. You need to patch login.c and other methods of authentication (ssh & rlogin, etc), or replace the appropriate functions in the lshell distribution (ftp://metalab.unc.edu/pub/Linux/system/admin/login), and wrap your shells accordingly. I still don't know what to do about dgb in that case. The alternative is to patch all your system shells and set the rlimits via the worldwide rc scrips. I've been told that pam patches do exist for ssh, but I don't have any urls. FreeBSD is completely vulnerable still. It provides no equalent to the Linux RLIMIT_AS (RLIMIT_VMEM under Irix), and checks no rlimits for mmap() and shmget. Still no word on OpenBSD. P.S. You can undefine __REALLY_FUXX0R__ in vmfuxx0r.c to stop the program from actually pagefaulting the maped memory, if you want to see OS's for which you have no kernel source enforce their rlimits for mmap. (the program will also safely unmap shared memory in this mode). P.P.S. You can do some very primitive ipc shares manipulation with ipcs(8) and ipcrm(8). ipcrm only allows you to remove indiviual IPC IDs. the --clean switch of vmfuxx0r removes all IPC IDs under Linux. (I tried to write additional functionality for other OS's, but it seems that the SysV IPC calls aren't very standardized for doing things like that). -- Mike Perry Proud user of both PGP 2.6.3i and GNU Privacy guard. Considering overthrowing any governments? Count me in! http://mikepery.linuxos.org/keys.html
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:52:29 PDT