Date: Tue, 18 Jan 2000 18:59:35 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Omachonu Ogali <oogali@intranova.net>, Adam <bsdx@looksharp.net>, Will Andrews <andrews@TECHNOLOGIST.COM>, freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) Message-ID: <Pine.BSF.3.96.1000118184849.5887A-100000@fledge.watson.org> In-Reply-To: <200001181605.IAA48520@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Jan 2000, Cy Schubert - ITSD Open Systems Group wrote: > 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. Unfortunately, given the nature of the exploit and the architecture, this is more of a "security by obscurity" kind of measure than actually preventing the writing of effective attacks--it's a little like preventing the execution of /bin/sh, as you point out you just switch to /bin/sh. The reason for this is that the premise of a buffer overflow attack is that the attacker is allowed to introduce new executable code into the system--the easiest way to exploit that capability is to take advantage of a large existing library of tty-based file management routines, AKA the shell. However, the attacker can still introduce other code directly--for example, rather than invoking exec on /bin/sh, they could just invoke unlink on the password files in /etc, or stomp some new data in to set a password in a standard configuration. That said, you'd disable a bunch of current-generation exploit scripts for a while, which might have some advantages, but still leaves you vulnerable to the next generation. :-) Deterrence, despite theoretical limitations, has often proven useful in the past... > Another idea might be that Robert Watson's logging and ACL's could > be extended to implement this. Robert, care to comment? Using auditing to detect unfortunate events is a good idea, but auditing is still a ways from ready. I need to check out a recent version of Nate's code and see how it's going in SRI-land :-). > 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. As you suggest, the real solutions are: 1) Prevent bugs from occuring in the first place, by using well thought out libraries that discourage sloppy coding practices (i.e., DO NOT USE the C-style nul-terminated string routines, rather use some bounded-buffer dynamically allocated string management library) 2) Limit the effects of remote execution compromise through fine-grained process access control--if popd needs to read a user's mail file and access a socket, make it so that that is *all* it can do. This is hard in our current environment, but a combination of jail() and fine-grained capabilities and resource access control (in the wings, to be commited post-4.0), this is a lot easier. > 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. There are some general purpose security solutions that generalize jail, such as integrity- or privacy-based mandatory access control. Jail is really a subset of the two of these: jail protects integrity by preventing processes in the jail from influencing system operation and other processes in a different jail or not in jail, and it protects privacy by limiting access to files and processes not in the jail. Using Biba intregrity protection or multi-level, multi-category privacy protection would provide a more general solution to this problem, but is harder to implement :-). Work is also in the wings, albeit in a longer time scale, to introduce mandatory access control into FreeBSD. This may not end up being committed, but at the very least we'll try our best to make it easy to plug in. Introducing ACLs in /proc might be a good way to add some initial (and cheap) protection. I.e., set a default ACL on /proc, and have children inherit the ACL. Due to the way POSIX.1e ACLs work as a superset of the file/directory "ownership" scheme, you could specify policies such as "owner and group can read", "only owner can read" for both directories and files. I've been considering this for a while, but am currently working to de-bde the next round of ACL commits :-). 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.1000118184849.5887A-100000>