Date: Sat, 18 Sep 1999 22:34:13 -0600 (MDT) From: Jobe <jobe@attrition.org> To: security@freebsd.org Cc: wes@softweyr.com Subject: Re: Real-time alarms Message-ID: <Pine.LNX.3.96.990918223142.9848A-100000@forced.attrition.org>
next in thread | raw e-mail | index | archive | help
There are lots of things to be worked out here. Seemings how we have to plan our security design to twart even the most skilled of hackers. Now, with this in mind we have to realize that a very skilled hacker will no doubt be able to write lkms to wrap arbitrary system calls and arbitrary kernel routines. At this point we realize that most of the current system calls are left extremely vulnerable, not only that but in order to provide sane security accounting we must also be sure that our logging/alert routines are untarnished by rogue code. I'd suggest possibly a sysctl variable that can be set only once after the system is rebooted that controls whether the alarms are to be sent locally or over the network, or both. Use IP Encapsulated UDP Broadcast/Multicast(Partially as Wes suggested) packets to transmit the alarms to the alert host(this is assuming that our evil friend hasn't disabled protocols he doesn't need to use). If we are strictly looking at a single host based alert system why not create a userland immutable device that can relay the events to a userland monitoring system, maybe set up a mod to the in kernel process signal processing disabling _ALL_ signals sent to the monitoring application's process id. Atleast this way the only way to mung the monitoring daemon would in effect be to actually corrupt the kernel's process table such that the scheduler wasn't giving any CPU time to the process. The design of the monitoring daemon is wide open, possibly just have it open an append only pipe to an immutable file, add an extra flag to fs options to allow the prevention of SYS_write() from overwriting previously written portions of files on this fs, mount a new fs with this option under say /alerts(similar to /proc only remove the ability of the fs to be umounted), and have the monitoring and place the file on the other end of the pipe here. This system is far from perfect, and whipped up rather spontaneously I might add, any questions/comments please feel free to mail me. --Jobe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.990918223142.9848A-100000>