Date: Fri, 25 Feb 2000 12:31:38 -0800 From: "Tim Brush" <tim@avantgo.com> To: Ryan Thompson <ryan@sasknow.com> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD minimal install... Message-ID: <38B6E6A9.F64FFFEB@avantgo.com> References: <Pine.BSF.4.21.0002251041010.98826-100000@ntstn.sasknow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) As you have mentioned, it won't really make a system that much more
> secure. In fact, it would probably only accomplish a false sense of
> security. Many SysAdmins out there know the intricicies of system
> security, and would already be familiar with which programs they need to
> chmod 000 or delete outright. I certainly wouldn't trust a "template" to
> decide that for me on a critical production machine, and I'd probably
> spend just as much time verifying the setup as I would doing it from a
> normal install myself. As well, many SysAdmins do NOT know all that much
> about general system security, and would gladly select the peared down
> distribution, then go into panic mode when their system still gets cracked
> or DoS'ed, thinking they should have been protected. Imagine good old
> Charlie Root leaving a bunch of unencrypted, sensitive files on his
> machine because, hey, _my_ system is secure.
>
> Another scenario: If I built you a house without doors, would you leave
> $500 USD sitting in plain view through a window?
If the template was configured correctly, the additional security would help
(not completely) protect a system. It would plug many of the simple holes that may
be overlooked. Although I do believe the number of System Administrators with
security knowledge is growing... Unfortunately I would have to say the majority
of System Administrators I've interviewed or talked with only have a cursory
knowledge of system security (another reason security professionals make a
killing). A firewall system is still only one scenerio though...
A template could be created for mail servers, web servers, new servers, etc.
with details on necessary configuration decisions. Many system administrators
work on building their own internal templates, this would help expeditate that
process. It could prove very useful to have the experience of individuals who
have run large servers of each type document specific configuration gotchas to
avoid... I know I'll like to offer my experience with larger mail servers
(80,000+ users - POP, 12,000+ users - IMAP and LDAP) into these templates and ease
the overall burden of other System Administrators.
> 2) Disabling or not installing certain important parts of the base system,
> like (as you suggested) gcc, IMO, is NOT a good idea. If I go to fix or
> troubleshoot a broken FreeBSD system, I want to know what I'm working
> with. Imagine the flooding to freebsd-questions:
I understand that certain tools should always be present but do you really use
uucp or f77? I do understand that there are individuals out there who use these
tools as well. Not every package or port is installed during a base installation,
so why have these tools been deemed more valuable then the others?
Another solution would be to have a entry in the /var/db/pkg directory for
bundled programs for easier removal and have simple configuration scripts that add
and remove packages based on template type. Disclaimers or additional template
specific mailing lists could be created to handle this traffic. Many System
Administrators could benefit and not have to re-invent the wheel.
> "I took over a system from a friend, and I followed the advice in the faq
> about making the world... Why won't it work??" Or, "why can't I telnet
> into my machine"? Or "The system didn't come with ..., how do I get it
> back?" You see the idea.
If a set of templates were designed and documented with the addition of
bundled software being built into packages, many of these problems could be
averted. If you knew that the system was built with a mail server template, that
works out to including package x, y and z but removes package a, c, d, f and g and
you could download packages a, c, d, f and g like any other package if you
"needed" to. This may require a better package management system with core system
requirement checking (i.e. you can't remove the package that handles booting of
the system, etc.) Perhaps this sounds a little too commercial...
> Perhaps if your idea was implemented with extensive documentation, on a
> command-by-command basis, with copious warning messages for each
> explaining WHAT the prospective SysAdmin is giving up, it might stave off
> some of the above problems. However, doing so would add a lot of text
> bloat to the already-stretched sysinstall. I really don't want to have to
> use THREE install floppies :-) Of course, it could be placed in an
> external text file, but that relies on the user actually reading it before
> installing. I don't want to suggest that people don't always read... But,
> well, people don't always read :-)
Documentation is unfortunately lacking in most areas... man pages can only do
so much and only give hints as to associated commands.
>- Ryan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38B6E6A9.F64FFFEB>