Date: Tue, 18 Jan 2000 08:05:15 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Omachonu Ogali <oogali@intranova.net> Cc: Adam <bsdx@looksharp.net>, Will Andrews <andrews@TECHNOLOGIST.COM>, freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) Message-ID: <200001181605.IAA48520@cwsys.cwsent.com> In-Reply-To: Your message of "Mon, 17 Jan 2000 21:04:07 EST." <Pine.BSF.4.10.10001172101390.96286-100000@hydrant.intranova.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.10.10001172101390.96286-100000@hydrant.intranova. net>, O machonu Ogali writes: > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > username logging along with a deny list (/etc/sh.deny). > > And in reference to Keith Stevenson's 'So?', if you can determine the > point of entry in an intrusion you can backtrack to where it originated, > the main reason I created that patch was to allow a system administrator > to backtrack in the case of an intrusion. A couple of points re the patch: 1. Exploits are tailored, e.g. offsets, instructions, etc., for each targeted platform. All a cracker needs to do is use /bin/csh to circumvent this on FreeBSD systems. Since most people install another shell, e.g. bash, exploits can be altered to use other shells. Though I haven't had a chance to think about alternative solutions, I think we need to step back and look at the bigger picture. If I may offer a half-baked idea: Why not a kernel module that implements the access list at execve(2) for any shell or binary. The reason for a kernel module is that not everyone would want the latency that this would cause nor the extra kernel memory. It could also be a kernel option for static link into the kernel. Another idea might be that Robert Watson's logging and ACL's could be extended to implement this. Robert, care to comment? 1a. Related to #1 above, all a cracker needs to do is transfer his own shell to the victim system thereby circumventing all of #1. In this case a non-executable stack and jail(2) are your friends. A non-executable stack for FreeBSD was discussed here in the past. I'm not sure whether anyone is implementing this or not under FreeBSD. 2. The patch relies on a /proc filesystem. The proc filesystem has had security issues in the past, a reason why some don't use it. At the very least the patch should be #ifdef'd or should check for the existence of proc being mounted before proceeding. Any other ideas? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Province of BC "e**(i*pi)+1=0" 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?200001181605.IAA48520>