Date: Mon, 20 Sep 1999 13:22:36 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Jobe <jobe@attrition.org> Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <Pine.BSF.3.96.990920131336.42321G-100000@fledge.watson.org> In-Reply-To: <Pine.LNX.3.96.990920094005.13128S-100000@forced.attrition.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, Jobe wrote: > Why not seperate processes that are being sent to the scheduler into two > categories, privelleged and unprivellged. Privelleged processes run in a > completely different execution environment in which we completely disable > process signaling(this would be a first step to thwarting daemon > interruption if not anything else). The only real flaw I see with this is > that we would need to find a replacement for kill -HUP which shouldn't > prove to be too difficult. By different execution environment I mean that > we have two seperate process tables. This way our auditd is not showing > up in ps, /proc or any of the other conventional process accounting > systems in userland. Also this will allow us to set up different > 'guidlines' as far as how we want this process to be executed. We can use > sockets to provide communication between userland -> auditd -> kernel > device -> userland. Also something I was wondering, is there anything > that prevents root from unlinking device inodes and relinking them to > bogus ones? If so, we are going to need to prevent that from affecting > our /dev/audit device. I'm a little concerned that seperating the privileged processes from the existing process architecture limits the usefulness of those processes, as well as significantly complicating process management in the kernel--however, the point is well taken, especially with regards to denying scheduling time to the privileged processes--some of these are general denial of service issues. Another concern I've had is with regards to keying material in IPSEC oriented applications--e.g., isakmpd and so on. I'd be tempted to try and retain the existing scheduler architecture and process table, but provide an alternative signal handler (and if necessary syscall handler) for the protected processes, allowing them to mask incoming signals that normal processes could not mask (kill, and so on), as your describe, block all tracing mechanisms. Protecting against file modification/etc could be provided by the securelevel/chflags behavior (noschg and so on). Protecting against disk space denial of service is probably best done by flat allocating the log file as a certain size (500mb, say) and then having auditd iterate through the log file. And as it opened the file before the securelevel went up, it is allowed to write to it (or the like). > > Processes would be unable to attach debuggers to protected processes > > while securelevel was set above a certain value, and limited in their > > ability to signal the processes, etc. This would allow us to offload > > computationally expensive audit-related code (statistical IDS, crypto, etc) > > from the kernel into a user process, but also protect the user process in > > the event of a root compromise, complementing the securelevel behavior. > > I'll do you one better, this is all possible by limiting ktrace/ptrace > access inside the kernel. As far as securelevel goes, bah humbug. Why > not just make it init runlevel dependant and only traceable when we are in > single user mode(runlevel < 3 I think?) I believe this would be a much > better idea seemings how you never know how a wiley hacker might muck with > our securelevel, where as we are almost assured that if we are at runlevel > 1 or 2 that we are in single user mode, which means most likely no network > access anyways. We really need to start a capabilities thread as this is ..I just started one on Access Control :).. > roaming closer and closer into that territory. And all you lamers that > are holding off on this discussion jump right in the water is nice and > warm! I'm sure we all like hearing new a different approaches to these > concepts, it really isn't as difficult as it may seem. Your $0.02 is > worth just as much as our $0.02 ;). Securelevel does provide us with some string primitives though--protecting against direct memory access, against direct device manipulation, and the ability to prohibit the modification of certain file system objects (kernels, for example :-). Also, we want something more general than init--how to specify which processes are protected? Perhaps a syscall saying "protectme()" that may only be executed prior to securelevel raising--this prevents hackers from creating processes that are impervious to other processes, but allows us to leverage it for security-related processes. Securelevel also provides us with a model of non-repudiation to some extent--the securelevel may not be lowered, only raised. > > --Jobe > > > In the access control email I sent earlier, tokend would be another > > process worthy of such protection :-). Leveraging the jail code to do > > this might help keep to a minimum all of the forms of process sandboxing > > we have. Don't know if this is a topic that interests you, but it would > > certainly be worthy of some hacking :-). > > > > Robert > > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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.BSF.3.96.990920131336.42321G-100000>