|
|
| Would you suggest that in.telnetd not ask for a password,
| and instead you packet filter at your gateways to allow only
| certain hosts?
:-)
Of course, FIRST OF ALL I'll set up an per-source-IP-based
filtering on a board router. THAN another level comes in --
a per-person level. Squid doesn't have one; or should it to?
| The router should not have to be reconfigured every time
| you add another piece of software,
Pretty rare case.
| or every time you move the software to a different machine,
Avoided by careful administration. Think what you are doing
and you'll be Ok :)
| or configure a different port for the software to listen to,
Even more rare case. Do you move your in.telnetd from
one random port to another on a weekly basis?
| If a software service desires security,
| it needs to implement its own security,
Why /bin/ls doesn't ask you for password each time you use it?
| rather than coming with an instruction book: "Ok, if you have this kind of
| system, you implement security like this... and if you don't, well
| go figure it out for yourself!"
Ok, suppose your'e right. So your'e left with N software
subsystems each with it's own security defence,
all partially overlapped and highly incompatible.
It would be more of a headache than of security,
beleive me. (Note what your firewall books tell you
on this topic. The main concept of firewalling
is to simplify things as far as possible,
otherwise you lose the ability
to manage all that many complex, nontrivial and
incompatible thingies. And this approach _really_ works).
| Yes you get slightly larger apps. The savings that you have in
| maintenance, though, far outweighs the extra disk space, memory, and
| cpu time it would consume.
| Experience tells me this (I do NOT work in
| an ivory tower), and these are features I look for in software that I
| use.
In _maintenance_????? All _my_ experience votes against
this. Either I'm missing something,
or I'm a sysadmin of a different brand than you ;)
In the case of "big" app like Squid we have a clear choice,
given a very limited manpower and time resources
of it's developers:
a) efforts are spent _both_ on cache functionality _and_
advanced (read: fascist :) ACL subsystem,
which isn't critical for Squid's direct
functionality and really is Yet-Another-Duplicate
of packet filter functionality.
This way both parts will be buggy for a much longer time.
(non-linear time dependance on complexity!)
b) ACLs are left alone in the state they are now,
and the efforts are spent at better functionality
of caching itself (is _everything_ Ok there? no more bugs
in caching? memory management? performance-wise? oh God... ;)
That's just my opinion... if the developers will think
that writing ACL stuff is a better application of their
spare time, nobody will ask me, of course. :) So I'm
shutting up, no more suggestions. :)
Thanks for Squid, Duane and others!
-- nic-hdl: ST73-RIPEReceived on Fri Sep 06 1996 - 01:41:06 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:56 MST