Date: Sun, 1 Oct 2000 10:51:27 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Mark Murray <mark@grondar.za> Cc: Warner Losh <imp@village.org>, Jordan Hubbard <jkh@winston.osd.bsdi.com>, security@FreeBSD.ORG Subject: Re: Security and FreeBSD, my overall perspective Message-ID: <Pine.NEB.3.96L.1001001100510.53359B-100000@fledge.watson.org> In-Reply-To: <200010010932.e919WRl00389@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Oct 2000, Mark Murray wrote: > > Exposure: > > > > Whether or not the application should, in normal use, be exposed to data > > of untrusted origin (e-mail, data files from untrusted users, socket > > connections in or out-bound, etc). > > > > - Intended to be run with exposure to untrusted environments > > - Not intended to run with exposure to untrusted environments > > This is policy - we should not mess with that, I don't think. _Everything_ > in Unix sees an untrusted environment is the assumption. While I agree that is true, I think that we regularly make distinctions, for the purposes of advisories, between buffer overflows in command line tool arguments of binaries that do not elevate privielges, and those that do. Similarly, we consider overflows in command line arguments of tools running with privilege and overflows in input/output of tools running with privilege. So there is something in this distinction that is worth considering. Certainly, it is the case that all of them should be fixed, but it's not clear that all are worth an advisory, and that our risk/trust factor shouldn't reflect that distinction. > > Privilege: > > > > What amount of privilege and access this code will be run as, determining > > the level of damage possible as a result of an exploit. > > > > - Run with elevated privilege > > - Run by normal users > > - Run sandboxed The reason I made this distinction was to try and quantify the cost of a software failure: if Apache is compromised running as nobody, that's substantially better than inetd compromised running as root. Not ideal, mind you, but in the grant scale of things, an improvement (hence why it runs as nobody :-). I think this is a quantafiably different measure than the amount of risk associated with the program due to the type and quality of data it processes. There probably needs to be another couple of items here quantifying network compromise (i.e., firewall proxy failure, etc). 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.1001001100510.53359B-100000>