Re: FreeBSD Security Survey

On Mon, 2006-May-22 15:20:11 -0000, FreeBSD User wrote:
Since time is always and issue, if the system could by default
(without an admin having to write scripts and/or apps, or manually
update) update itself for both system and installed ports/packages, it
likely would reduce security issues exponentially.

I think it would substantially reduce the reliability and security.

Firstly, automatically installing arbitrary "fixes" on a production
system is almost always a bad idea. The release engineering and
security teams do regression testing but can't test exactly your
system configuration and there's a non-trivial likelihood that
installing patch X will break something that your configuration relies
on. This can be mitigated by using a test system and rolling out the
updates from it, but that negates the whole point.

It's also likely to inconvenience users. Our ITS department take it
upon themselves to automatically roll out (wintel) desktop updates.
This almost always results in your desktop machine insisting that it
needs to be rebooted immediately when you are in the middle of doing
something crucial - thus breaking your concentration and potentially
losing data (my manager managed to lose 3 man-hours work once). I,
for one, would hate it if my FreeBSD boxes started doing the same.

Specific FreeBSD versions aren't maintained forever. An "install it
and forget it" philosophy will increase the number of machines that
aren't being patched because they are running unmaintained versions
of FreeBSD. With the current approach, the sysadmin is aware that
particular machines need to be updated to a newer version. If
everyting is automatic, the sysadmin will probably forget.

Finally, it only takes one security failure in the update process for
someone undesirable to "own" all the FreeBSD machines that have been
left in this default mode. Despite the best efforts of FreeBSD
developers, FreeBSD will always contain bugs and some of them will
be security holes. Any automatic update process needs to balance
the benefits of reducing the number of unpatched boxes against the
risks of the update system being subverted.

--
Peter Jeremy
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: FreeBSD Security Survey
    ... I think it would substantially reduce the reliability and security. ... automatically installing arbitrary "fixes" on a production ... Specific FreeBSD versions aren't maintained forever. ... particular machines need to be updated to a newer version. ...
    (FreeBSD-Security)
  • Re: FreeBSD Security Advisory FreeBSD-SA-05:21.openssl
    ... >> few boxes but try to imagine how to manage security on hundreds of them ... FreeBSD just don't have a mechanism to handle security ... thousands of machines, through a few well selected build machines") ... This is _UNACCEPTABLE_ in a large setup. ...
    (FreeBSD-Security)
  • Re: SSHD revelaing too much information.
    ... He *is* the FreeBSD Security Officer. ... you still need to be sure that students' machines don't get ... client can activate a workaround when it connects to a broken sshd. ...
    (FreeBSD-Security)
  • Re: URLScan and Hacking
    ... I'm sure there are machines being hacked ... IIS is just one of the mode. ... windows security, antivirus, physical security, ... Has anyone had their> machine hacked at all since installing these 2 utilities? ...
    (microsoft.public.inetserver.iis.security)
  • Re: Limiting Users
    ... Have you tried using the compatws.inf Security Template on your users ... Due to> certain software we are using, these particular users had> to be placed in the "Power Users" local group. ... > Unfortunately, they've taken a liking to installing> software such as Webshots, Weatherbug, toolbars, and> other unnecessary, spyware infested software on their> machines. ... Is there a way for me to completely stop them> from installing anything on their machine, yet still> remain part of the "Power Users" group such that they can> continue to use their PCs normally? ...
    (microsoft.public.win2000.security)