On Wed, 2006-09-20 at 11:56 +0300, Shlomi Fish wrote:
> On Tuesday 19 September 2006 22:28, Omer Zak wrote:
> > On Tue, 2006-09-19 at 18:28 +0300, Nadav Har'El wrote:
> > > a
> > > general Debian or Fedora system (with automatic updates, firewall, and
> > > other things required to keep that secure) is a more sensible choice than
> > > a home-grown everything-must-be-chrooted system.
> >
> > This is an argument in favor of monocultural system configuration.
> > To be secure Hamakor's server should have sufficiently unorthodox
> > configurations that if someone breaks into the system, it will be
> > difficult for him to find his way in the system.
> >
>
> Omer, we had this discussion before on iglu-web:
>
> http://www.mail-archive.com/iglu-web%40iglu.org.il/msg01367.html
>
> Right now I'd like to note that there are two types of "security by
> obstacles":
>
> 1. Security by Hurdles - you create obstacles that are not impossible to
> overcome, just as a hurdle can be jumped over.
>
> 2. Security by Walls - you create obstacles that are imposssible to overcome,
> just as it is impossible to jump over a whole.
In the big scheme of things, even password-based security is a
difficult, but possible, hurdle. A sufficiently determined and crazy
Saddam Hussein can get the password if he wants to (even if by snatching
someone who knows it and torturing him).
The threat, against which I support non-standard configurations, is by
automatic malware - viruses, worms, Trojan horses, etc. To break into a
system with nonstandard configuration, the virus has to carry with
itself more intelligence and spend more time attacking each system.
In a properly designed non-standard configured system, the nonstandard
configuration can itself be considered as a part of the password
(directory names, numbering of syscalls in a customized kernel, etc.).
Of course, this requires that the configuration can be as easily changed
as changing a password is.
> As I noted the problem with creating an unorthodox configuration, is that
> people who are used to orthodox configurations will need to maintain it. And
> we may need to train newer administrators with this configuration. And being
> used to "orthodox" configurations, these people will make mistakes with the
> unorthodox configuration. And these mistakes can be destructive.
Then ask Shachar to prepare written documentation about the unorthodox
configuration which he created, including a cookbook section about the
way to perform every maintenance task the future sysadmin will need to
do. Hopefully, Shachar can recoup his time investment in documentation
by providing the documentation also to paying customers who had their
servers fortified by him.
> > If this means chrooting, then I am in favor of chrooting.
> > If Debian or Fedora do not support this style of working, then it may be
> > a good idea for the person maintaining the system to develop
> > improvements to the packaging systems and offer them as patches.
> >
>
> Do you volunteer to maintain these patches?
In this specific context, the question is a variant of argument by
intimidation. I did volunteer to perform other tasks, and may again
volunteer in the future. So I claim not to be a case of someone who
knows only to speak and does nothing.
To ask me about maintaining patches to the Debian packaging system is
like asking someone who passed a short first aid training course and
made a suggestion about a medical program - to learn medicine (the 7
years worth of stuff, that is) and only then have the right not to feel
intimidated before making further medical suggestions.
--- Omer
--
In civilized societies, captions are as important in movies as
soundtracks, professional photography and expert editing.
My own blog is at http://tddpirate.livejournal.com/
My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
