Date: Mon, 20 Sep 1999 10:03:42 -0600 (MDT) From: Jobe <jobe@attrition.org> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <Pine.LNX.3.96.990920094005.13128S-100000@forced.attrition.org> In-Reply-To: <Pine.BSF.3.96.990920115728.42321E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, Robert Watson wrote: <snip> > One thing I am particularly interested in seeing brought to fruition is a > way to protect key system security processes from interference--from any > other user process, even one running as root. This might be similar to > the jail code--the world being in a jail and only processes such as auditd > (possibly init?) outside of it. 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. > 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 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 ;). --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 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.990920094005.13128S-100000>