I'm an idiot. On Wed, Mar 21, 2007 at 03:35:18PM +0000, Dave wrote: > Remember, > Derek's solution to the security problem is to install as many boobietraps as > possible between an invader and a vulnerability, and it's trivial to show that > his solution, while extremely expensive on the programmer's end (since it > essentially requires every program to actively insert boobietraps, thereby > violating the UNIX philosophy of doing _one_ thing, as well as the KISS > principle that the entire worldview that the UNIX philosophy is based on is > rooted in - now you know why Churchill might've been wrong about prepositions > at > the ends of phrases being okay)
, is also extremely expensive on the attacker's end (since it essentially requires every attacker to actively circumvent boobietraps, thereby violating the UNIX philosophy of doing _one_ thing (as well as the KISS principle), thereby lowering his own efficiency at attacking your system) > . Sorry about that, - Dave On Wed, Mar 21, 2007 at 03:35:18PM +0000, Dave wrote: > On Wed, Mar 21, 2007 at 01:49:45PM +0100, Vincent Lefevre wrote: > > On 2007-03-21 00:27:10 +0000, Dave wrote: > > > On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote: > > > > On Tue, Mar 20, 2007 at 07:28:36AM +0000, Dave wrote: > > > > > On Mon, Mar 19, 2007 at 11:51:37PM -0400, Derek Martin wrote: > > > > > > > I'd also really like to see a configure option for mutt refuse to > > > > > > run binaries in directories where the user has write access, > > > > > > > > > > I think that's a useful option. > > > > > > > > > it sort of defeats ~/bin. > > > > > > Well, you can "lock" ~/bin by chmod(1)ing u+w ~/bin before every > > > time you add or remove a local script/program, and u-w after you're > > > done. > > > > So, what's the point of preventing Mutt from running binaries from > > such directories? > > First off, I'm not in favor of adding it because I can prove how it improves > security, but rather simply because somebody feels it can improve security, > and > it doesn't really hurt the code much to add this feature. We certainly > wouldn't > have an easy time proving that it can _never_ improve security. Remember, > Derek's solution to the security problem is to install as many boobietraps as > possible between an invader and a vulnerability, and it's trivial to show that > his solution, while extremely expensive on the programmer's end (since it > essentially requires every program to actively insert boobietraps, thereby > violating the UNIX philosophy of doing _one_ thing, as well as the KISS > principle that the entire worldview that the UNIX philosophy is based on is > rooted in - now you know why Churchill might've been wrong about prepositions > at > the ends of phrases being okay). > > That said, I'd like to take a shot at showing at least one case where we might > successfully fend off a half-hearted attack with this boobietrap: If an > intruder > can somehow creat(2) a file with the X bit set (but has no access to the > chmod(2) call - say, he has the opportunity to manipulate the flags of a > creat(2) call somehow), then if a directory in the $PATH is writeable, he may > be > able to capitalize on the opportunity to displace a common utility without > Derek's boobietrap. > > Derek's philosophy is about agressively trying to harrass an adversary at > every > single corner (much like old "encryption" systems), rather than implementing > all > security in one strong wall that's simple enough so we can easily prove its > theoretical security (much like a modern encryption system). It's also easier > to maintain a program that doesn't have boobietraps strewn everywhere, since > there are fewer opportunities for a change to accidentally nuke a "micromine" > without anybody noticing. Next, it's important to note that sticking to the > KISS principle allows programmers who aren't security experts to create (and > maintain) easily auditable programs; obviously, not requiring programmers to > be > security experts in order to build secure software (a) increases the number of > available programmers who can build secure software, and (b) better matches > reality, where most programmers are not security experts. (The only problem > is > that "security experts" then lose a lot of consulting work.) Finally, it's > far > easier to educate a user in the science of opening doors conservatively than > in > the art of maximizing confrontations with potential intruders using half a > zillion "micromines" in (what the programmer (who, of course, may not be a > security expert) considers) strategic locations. > > > Note that if the user saves a file from an external source to bin by > > mistake, the file won't have the x bit set. So, there's no problem. > > And if a chmod can be done on the file, it can also be done on the > > directory. > > Well, if our intruder can manipulate the flags on a chmod(2) call, but can't > modify the file argument, he still may be able to chmod(2) a particular file, > but not necessarily the directory it's in. The other option is if the > intruder > can manipulate the file argument, but the flags are set to 0700 or something. > In that case, you could chmod(2) the directory if you wanted to, but you'd > have > to find another way to chmod(1) u-w the directory before your planted binary > could be executed by Mutt. (Obviously, if the user were to execute a > "non-security-critical" program that had the misfortune of trying to execute > the > utility displaced by your new binary, the user would be just as screwed, but > Derek would probably counter that _all_ programs must (re)implement the > boobietraps in order to block this type of problem. Are you starting to see > why > simple, clean, orthogonal interfaces are so cool? Dennis Ritchie may not have > been a security expert, but he's always been a very wise man.) > > > > > the most secure solution is already the default: no sane program (except > > > > the linker) creates/saves files with an executable bit set. this is a > > > > conscious decision of the user - at the point where it is not, the > > > > security was already compromised. > > > > > > I don't disagree with your last statement. However, some people may > > > appreciate the added bit of security gained by extra restrictions on > > > program execution. > > > > If the user doesn't trust his $PATH or what he installs in his bin > > directory, he can still use full pathnames. > > I'm sure there are cases where a ban on trusting $PATH can be a useful > boobietrap (i.e., can stop at least one half-hearted attack). > > > But a *compile-time* > > option would be a bad idea, as the one who installs the software > > is not always the one who uses it. > > The one who installs the software should be the system administrator, who's > (an > agent of) the owner of the system. It's his domain to make these types of > decisions about his system. How about runtime options having two shadow > compile-time options, default-blah and force-blah? Normally, a sysadmin would > only set default-blah options (or none at all, ideally), but when a sysadmin > decides to pursue the boobietrap approach, he still has the option of setting > force-blah options. This type of scheme should be fairly easy to maintain > from > a programmer perspective. How does that sound? > > > BTW, a shell with restrictions would be a much better idea. > > smrsh? > > - Dave
