FreeBSD Security Survey

FreeBSD User fbsd at sefao.com
Mon May 22 17:42:10 PDT 2006


   Should something like automatic security updates not be a goal? If
   done correctly, and on a per-stable/version basis, it is "possible" to
   increase security exponentially. The responsible administrator will
   naturally keep ontop of all changes and fixes.  But just like in the
   wintel and other *nix worlds, not every administrator updates their
   servers. Ok, maybe only a few FreeBSD administrators don´t update...
   What I am trying to suggest is a mechanism that incorporates all
   security fixes and specified (or installed) ports/packages for a given
   server, within a per-stable/version basis.  Tools that exist already
   accomplish this, and run by a custom script via cron.  There still
   would likely be a strong need for an administrator to buildworld,
   especially for those of us who prefer configuring custom kernels and
   bulilding (mostly) by source.
   It is naturally a "wish" that could potentially save a busy
   administrator some time. As I said, this of course would be a massive
   project/challenge. Varying system and kernel configurations alone
   would make this a huge challenge, not to mention the potential
   security implications.
   Granted, many FreeBSD versions will not be maintained for long periods
   of time.  But are there no out dated versions running now?
   Is something like this not worth looking at for the future?
   Sejo
   -------- Original Message --------
   From:Peter Jeremy
   Sent: Tue 23 May 2006 05:23:50 1000
   To: FreeBSD User
   Subject: 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 upda
 te 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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"


More information about the freebsd-stable mailing list