Date: Sat, 30 Sep 2000 17:25:53 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: security@FreeBSD.org Subject: Re: cvs commit: ports/mail/pine4 Makefile (fwd) Message-ID: <Pine.NEB.3.96L.1000930172020.44697B-100000@fledge.watson.org> In-Reply-To: <200009301842.e8UIgA543368@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 30 Sep 2000, Brian F. Feldman wrote: > > : Another possibility might be to force pine into a > > : chroot... I guess the only good advice to give if you HAVE to run pine is to > > : run it inside a jail. > > > > I don't think that would work. > > That is, one can create their own jail (or just chroot(8)... I should y> probably get user-chrooting reviewed ;) which they would use for running > potentially evil things -- like reading e-mail with pine. It's not too > difficult, but it's really easier just to switch to a better MUA. Neither chroot(8) nor jail(8) are intended to provide a light-weight sandboxing service, and attempts to adapt them will no doubt run into substantial problems, as typically developing security features requires a whole-system view. There have been numerous projects which have provided various forms of light-weight sandboxing, but most of them involve more work to develop and set up than fixing the application in the first place. If you're interested in various forms of integrity-based containment, you might consider spending time working on our Biba MAC implementation, but keep in mind mail programs lose a lot of their utility once you've managed to effectively isolate them from the system (can no longer save attachments, load files to email them out, keep your PGP keyring accessible to your mailer, ...) It's interesting--people constantly bash type-safe languages, but sadly, the majority of the exploited bugs today would all be fixed by writing your mail reader in Java, ML, Modula-3... I support the current move to mark Pine4 as FORBIDDEN. It retains support for Pine in the base system as a port, while providing administrators a safety warning before attempting to install it. If the lack of a package substantially worries people, what we should look at is a way that the package mechanism can include security status information -- i.e., a +ATTRIBUTES or the like file, which includes information on the FORBIDDEN status. Package management tools could inspect this and display a warning as needed, allowing packages to inherit the security properties of their respective ports. 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.NEB.3.96L.1000930172020.44697B-100000>