atom feed19 messages in org.freebsd.freebsd-securityRe: Parent Logging Patch for sh(1)
FromSent OnAttachments
Omachonu OgaliJan 16, 2000 10:04 am 
Will AndrewsJan 16, 2000 12:03 pm 
Omachonu OgaliJan 16, 2000 2:10 pm 
Will AndrewsJan 16, 2000 2:29 pm 
Omachonu OgaliJan 16, 2000 3:11 pm 
Sheldon HearnJan 17, 2000 2:57 am 
AdamJan 17, 2000 12:47 pm 
Omachonu OgaliJan 17, 2000 6:03 pm 
Keith StevensonJan 17, 2000 8:20 pm 
Michael RobinsonJan 17, 2000 9:24 pm 
Sheldon HearnJan 17, 2000 10:09 pm 
Omachonu OgaliJan 18, 2000 4:02 am 
Sheldon HearnJan 18, 2000 4:20 am 
Omachonu OgaliJan 18, 2000 7:35 am 
Cy Schubert - ITSD Open Systems GroupJan 18, 2000 8:04 am 
Omachonu OgaliJan 18, 2000 8:15 am 
Sheldon HearnJan 18, 2000 12:14 pm 
Cy SchubertJan 18, 2000 1:42 pm 
Robert WatsonJan 18, 2000 3:59 pm 
Subject:Re: Parent Logging Patch for sh(1)
From:Cy Schubert - ITSD Open Systems Group (Cy.S@uumail.gov.bc.ca)
Date:Jan 18, 2000 8:04:53 am
List:org.freebsd.freebsd-security

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?

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message