On Tue, Apr 23, 2002 at 09:47:56AM -0500, Jeff Licquia wrote: > On Tue, 2002-04-23 at 07:44, Jeroen Dekkers wrote: > > On Mon, Apr 22, 2002 at 05:26:17PM -0500, Jeff Licquia wrote: > > > Unfortunately, no one is perfect. Are you claiming the title? If you > > > are, thanks for letting us know; we need to start auditing all of your > > > projects right away. :-) > > > > I don't think you will find buffer overflows in my code. At least not > > any overflow libsafe would protect against. If you don't want to know > > all details of string manipulation use a higher level language. If > > you want to program C and want to manipulate strings do it right. > > You didn't get my joke, even with the smiley. This could mean that you > just don't have a sense of humor, or it could mean that you're > dangerous. > > If you really believe that you're incapable of making mistakes just > because you know something about the (im)proper use of strcpy(), then > you're an accident waiting to happen. I don't use strcpy() at all. I don't see how you can easily make buffer overflows with memcpy(). > > > The best security plan makes use of layers. This way, a screwup on one > > > layer has a chance of being compensated for on another. That's why we > > > still have both tcp-wrappers and ipchains, for example. > > > > The best security thing is to write clean code and make the system > > less vulnerable by the design of the system. > > This is absolutely, positively incorrect. Nothing could be further from > the truth. > > If your security model depends on everyone doing design and code work > being perfect, then your security fails the moment someone makes a > mistake. I don't see it's the *only* thing. But it's the best way to start. With a clean, commented source code auditing is a lot easier for example. > This means your security falls fairly quickly, since everyone > overlooks things, makes mistakes, etc. OTOH, if you design your > security system in a layered fashion, with failsafes, then there's a > chance that your mistake will be covered by some other check. If the > other failsafe logs its activation, so much the better; you'll be > notified of a problem in your code, and you can fix it. > > I'm not faulting clean code and good design here. Every little bit > helps. But you're a fool if you trust in clean code and clean design as > your primary security bulwark. If you don't give any permissions to some code running, it can't be a security problem if there are bugs. For example, by eliminating the need for suids binaries, you avoid any security problem they could cause if they have bugs. If you avoid having to run some kind of server like a ftp daemon as root, it isn't a security problem if there is some bug. I think this works better than some library which checks every function call to look for mistakes. > My main objection in this whole thread are these ideas you seem to have > that: > > - new ideas aren't worth trying Of course it is, as long as the ideas aren't obvious bad. > - incomplete ideas aren't worth expanding upon I'm talking about the wrong base of the idea. > - you're incapable of making stupid mistakes I didn't say that. But if I don't use those functions at all, how can I make mistakes with those functions? > The former two just mean that you're cranky, but the last is troubling. > There are a lot of examples of people in history who made stupid > mistakes because they had an inflated sense of their own infallibility. You are thinking I have that. I have nerver said it however. > You should always have an innate fear of your own code, and should > always suspect it to be riddled with errors; that will prompt you to > look for them more closely. That is Rule One of secure programming. > The moment you catch yourself saying "I'd never do that" is the moment > you should do penance for having such thoughts. I'm talking about the faults libsafe would catch. If you make such faults, you should learn what's going on or use a higher level language. C is made for programmers who know what they are doing. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgpQqkDJ2RdTj.pgp
Description: PGP signature