Date: Thu, 02 Jan 2003 13:18:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Claus Assmann <freebsd+current@esmtp.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: 5.0-RC2 informal PR: 90 sec sendmail delay Message-ID: <3E14ACAC.2014C867@mindspring.com> References: <rgptrg1uzx.trg@localhost.localdomain> <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <20030102104810.A27967@zardoc.esmtp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Claus Assmann wrote: > There is no magic, this is plain and simple good engineering > standard: you need multiple layers of security. You have to > minimize the impact of any mistake that can happen. I understand the principle. Air bags in a car make sense, since they can help you survive a crash; air bags in a space shuttle don't. > > Nope. I don't agree. I think the change makes things harder, and > > I don't see a difference in the volume of security advisories (e.g. > > not a lot of advisories warning about people being able to obtain > > the "$MAILUSER" identity through some buffer overflow, rather than > > "root"). > > I can't believe you have written this. Come on, this is trivial. > > What can you do with root access? Send tons of SPAM. Execute code as root. > What can you do with smmsp group access? Send tons of SPAM. Execute code as mailuser to raise my priviledge to root, and then execute code as root. 8-). I look at as putting on a chain lock to save yourself, in case someone breaks through your deadbolt, on the theory that this extra step will keep the Visigoths out of your house. > Here's the plain and simple reason for the change in 8.12: > > 8.11.6/8.11.6 2001/08/20 > SECURITY: Fix a possible memory access violation when specifying > out-of-bounds debug parameters. Problem detected by > Cade Cairns of SecurityFocus. > > This was what triggered finally the switch, which we had put off > far too long. Note that this could be triggered by a non-root user, but only if they already had the ability to run as a user on the machine, not as a client of an application running on the machine. In other words, they would have to be inside the deadbolt, but not yet inside the chain lock. > Any simple bug somewhere in this huge program or in the environment, e.g.,: > > 8.10.2/8.10.2 2000/06/07 > SECURITY: Work around broken Linux setuid() implementation. > On Linux, a normal user process has the ability to subvert > the setuid() call such that it is impossible for a root > process to drop its privileges. Problem noted by Wojciech > Purczynski of elzabsoft.pl. > SECURITY: Add more vigilance around set*uid(), setgid(), setgroups(), > initgroups(), and chroot() calls. > > would give someone root access. This is NOT acceptable (IMNSHO). > > Is that "just a propaganda move, and it's not technically justified"? If the environment is not secure, then the system is not secure, by definition. For this particular case, the Linux system is going to be insecure, unless you remove all setuid() programs that attempt to drop root priviledges from the system. If it's still possible to get in to execute code as the UID of the mail user, then it's possible that the code you execute would be another setuid() program that is succeptible to the problem, and therefore you've only added an extra step to the exploit, rather than eliminated the possiblity. In other words, in this particular case, you have added security through obscurity... which is generally acknowledged as not really increasing security at all. The general security threat out there is knowledgable attackers who write tools that get into the hands of "script kiddies", who are not themselves capable of writing the attacks, but are able to run them just fine, once they are written. Such a change does nothing in defense against the knowledgable attacker. It's really a matter of where you put your walls. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E14ACAC.2014C867>