On Mon, 26 Feb 2007 12:21:07 -0800, Paul D. Fernhout pdfernhout@kurtz-fernhout.com wrote:
A good question, but if you are serious about security, a much more secure system is going to come from building a system up (especially up from a textual description), and understanding what each component you include does, and testing all their interactions, rather than just accepting what results from some random shrink command that may or may not remove code with various security problems. Security is not an add-on -- if you want a secure application, the idea of security needs to be woven throughout everything you do -- initial image or source, code development processes, deployment approach, update streams, and so on.
Perhaps I had not followed closely enough the discussion, but I thought we were talking about options in the absence of being able to grow from nothing. So:
Why take a perfectly working application and start potentially introducing all sorts of random errors into it at the last minute just to save a bit of storage space and network bandwidth (especially these days)?
I thought you were offering the option of:
a) Leave all code in. b) Shrink, causing potential problems.
In which case, (b) is, if not more secure, easier to check, presumably. If we have another option:
c) Build, adding only what's needed.
Well, sure, I'll take (c). But I don't think we can ever escape (b) entirely, since our development image includes all our development tools, as opposed to simply being created by them. In fact, I wonder if that wouldn't resolve some issues: Having a development image which is used to build on a target image.
===Blake===