On Mon, 23 May 2005 14:50:31 -0400, rbt wrote:

> Everything I've read seems rather clear and straight forward, except for
> one area: How are security patches added to a running OpenBSD system.
> For example, say there is an exploit for cvs that's running on 3.5...
> how would the admin apply the patch? Can it be automated or does it
> require compiling, etc.

Patches are provided in source format only. You require a complete source
tree installed in /usr/src. Instructions for applying the patch are
included with the patch and yes, the patches do require compiling.

> I'm lazy. I want to install and setup an OS once every 5 - 7 years and I
> expect it to be smart enough to half-way take care of itself when it
> comes to patching. Is OpenBSD suitable for this type of usage/neglect?

No, patches for OpenBSD are provided only for -current, the latest release
and the previous release. IOW, you would need to update about every year.

If you want 5-7 years of support you should look into Solaris. But *no*
operating system can be expected to survive that period of time without
compromise if you neglect to maintain it.

On 2005-05-23, rbt wrote:
> one area: How are security patches added to a running OpenBSD system.
> For example, say there is an exploit for cvs that's running on 3.5...
> how would the admin apply the patch? Can it be automated or does it
> require compiling, etc.

There is a work in progress:

https://bsdupdates.com/

However the use of binary updates v source patches is a moot point.

Steve P

Dave Uhring wrote:
> On Mon, 23 May 2005 14:50:31 -0400, rbt wrote:
>
>
>>Everything I've read seems rather clear and straight forward, except for
>>one area: How are security patches added to a running OpenBSD system.
>>For example, say there is an exploit for cvs that's running on 3.5...
>>how would the admin apply the patch? Can it be automated or does it
>>require compiling, etc.
>
>
> Patches are provided in source format only. You require a complete source
> tree installed in /usr/src. Instructions for applying the patch are
> included with the patch and yes, the patches do require compiling.
>
>
>>I'm lazy. I want to install and setup an OS once every 5 - 7 years and I
>>expect it to be smart enough to half-way take care of itself when it
>>comes to patching. Is OpenBSD suitable for this type of usage/neglect?
>
>
> No, patches for OpenBSD are provided only for -current, the latest release
> and the previous release. IOW, you would need to update about every year.
>
> If you want 5-7 years of support you should look into Solaris. But *no*
> operating system can be expected to survive that period of time without
> compromise if you neglect to maintain it.
>

That's rather disappointing. I had hoped updates would be easier to do
and less frequent than once every 6 months or 1 year. Really a sticking
point for me. I may have to use Debian Linux. As much as I dislike the
hype around Linux, I have had Debian boxes on-line for 5 - 7 years...
patched and updated.

I know OBSD could do this as well. Why not combine the world-renown,
legendary security of OBSD with a top-notch update mechanism? I know
this would be a compelling reason for me (and probably others) to use
OBSD in more functions.

Cheers,

rbt

Begin
On 2005-05-24, rbt wrote:
> Dave Uhring wrote:
>>
>> If you want 5-7 years of support you should look into Solaris. But *no*
>> operating system can be expected to survive that period of time without
>> compromise if you neglect to maintain it.
>>
>
> That's rather disappointing.

Still supporting stone-age releases isn't really feasible for volunteers
that also want to support newer versions. If you really want that you
can a) use something commercial that _does_ support it (eg solaris) or
b) support your own old releases by source patching. That can be done
with all the *BSDs, at least. Probably linuces too, but I dunno that.


> I had hoped updates would be easier to do
> and less frequent than once every 6 months or 1 year. Really a sticking
> point for me. I may have to use Debian Linux. As much as I dislike the
> hype around Linux, I have had Debian boxes on-line for 5 - 7 years...
> patched and updated.

You could look at FreeBSD. Check their publicized support times and
Stuff. I don't know if you should go the debian route; they're glacially
conservative which has problems of its own. But if that's what you need,
then by all means.


> I know OBSD could do this as well. Why not combine the world-renown,
> legendary security of OBSD with a top-notch update mechanism? I know
> this would be a compelling reason for me (and probably others) to use
> OBSD in more functions.

There is quite a good update system. You just have to upgrade your
release now and then.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

rbt wrote:
> For example, say there is an exploit for cvs that's running on 3.5...
> how would the admin apply the patch? Can it be automated or does it
> require compiling, etc.

As already mentioned: Patches for the base system requires compiling.
However the OpenBSD team plugs a lot that in ten years or so the default
OpenBSD setup has only had one remote exploit. As long as you trust your
users (you and your wife, right?) and you are conservative about what ports
are left open to the World Wild Web you are probably reasonably safe, even
without applying every single patch. Also, in the last six months there has
only been released six patches for 3.6, and some of these are fixes for bugs
that are not known to be exploitable and patches for services that nobody
uses anyway (such as telnet). It is probably still a good idea to recompile
your base system once in a while, but you are not likely to have to set
aside time for this task the second tuesday of every months. Also,
recompiling the base system is actually a pretty straightforward job.
Compile kernel, reboot, compile base, done. The biggest drawback is that you
have to actually wait for the kernel to compile before you can start the
rest of the task.

As for installed ports, most ports are also released as binary packages (at
least on i386). This includes updates and patches. In 3.6 you have to
uninstall and reinstall the port _and_ all ports dependant on it, but from
what I hear this process has been simplified a lot in 3.7. Haven't been able
to actually test it though, as 3.7 is still on my to-do-list and likely to
be so for at least some time.

rbt wrote:
> Dave Uhring wrote:
>
>> On Mon, 23 May 2005 14:50:31 -0400, rbt wrote:
>>
>>
>>> Everything I've read seems rather clear and straight forward, except
>>> for one area: How are security patches added to a running OpenBSD
>>> system. For example, say there is an exploit for cvs that's running
>>> on 3.5... how would the admin apply the patch? Can it be automated or
>>> does it require compiling, etc.
>>
>>
>>
>> Patches are provided in source format only. You require a complete
>> source
>> tree installed in /usr/src. Instructions for applying the patch are
>> included with the patch and yes, the patches do require compiling.
>>
>>
>>> I'm lazy. I want to install and setup an OS once every 5 - 7 years
>>> and I expect it to be smart enough to half-way take care of itself
>>> when it comes to patching. Is OpenBSD suitable for this type of
>>> usage/neglect?
>>
>>
>>
>> No, patches for OpenBSD are provided only for -current, the latest
>> release
>> and the previous release. IOW, you would need to update about every
>> year.
>>
>> If you want 5-7 years of support you should look into Solaris. But *no*
>> operating system can be expected to survive that period of time without
>> compromise if you neglect to maintain it.
>>
>
> That's rather disappointing. I had hoped updates would be easier to do
> and less frequent than once every 6 months or 1 year. Really a sticking
> point for me. I may have to use Debian Linux. As much as I dislike the
> hype around Linux, I have had Debian boxes on-line for 5 - 7 years...
> patched and updated.
>
> I know OBSD could do this as well. Why not combine the world-renown,
> legendary security of OBSD with a top-notch update mechanism? I know
> this would be a compelling reason for me (and probably others) to use
> OBSD in more functions.
>
> Cheers,
>
> rbt

Applying patches to address realiability and security problems with
source is a piece of cake. If you download the patch and read the patch
header, it's usually as simple as:

$ cd /usr/src
$ patch -p0 < 021_bind.patch
$ cd /usr/src/usr.sbin/bind
$ make -f Makefile.bsd-wrapper obj
$ make -f Makefile.bsd-wrapper
$ make -f Makefile.bsd-wrapper install

This is the exact process I followed a few months back to patch bind.
Since the OpenBSD develoeprs take a good deal of care when developing
the operating environmnet, there seem to be far fewer devastating bugs
with the kernel and user land utilities.

On 2005-05-24, rbt wrote:
> That's rather disappointing. I had hoped updates would be easier to do
> and less frequent than once every 6 months or 1 year. Really a sticking
> point for me. I may have to use Debian Linux. As much as I dislike the
> hype around Linux, I have had Debian boxes on-line for 5 - 7 years...
> patched and updated.
>
> I know OBSD could do this as well. Why not combine the world-renown,
> legendary security of OBSD with a top-notch update mechanism? I know
> this would be a compelling reason for me (and probably others) to use
> OBSD in more functions.

I moved to obsd with 3.6 after using debian since 1996 (before that I had
slackware). One of the main reasons was because obsd is much easier to
keep secure. With debian, I had a lot of work on my hands that should
have been handled automatically by the debian team, but wasn't. Just to
give you an idea:
- the daemons (like BIND) aren't chroot'd by default, so I had to always
create my own chroot structure and modify the init script to
start/restart the daemon in that environment. I remember at least one
remote hole in BIND that could have been avoided if it was chroot'd...
- the daemons don't use priviledge separation (notable exception is
vsftpd, but it's not the default ftpd in debian for some reason...)
- there are lots of needlessly suid/sgid programs, and I had to
eventually write a script to disable all those s-bits except for the
ones that trully needed it.
- debian has no defense-in-depth unlike obsd which by default uses gcc
patches (propolice) and kernel safety mechanisms (w^x) along with lots
of thorough security audits. I ended up having to maintain my own
Linux kernel packages (different ones for each hardware), patched with
grsecurity. It was not fun at all, especially since to get the full
benefits that it offers you have to recompile all your binaries,
which isn't as simple as running "make" in /usr/src...
- finally, despite all the effort I went through to secure my Linux
boxes, they still became vulnerable when security holes in the kernel
were discovered, which seems to happen much more often than with obsd
(that's natural, after all Linux development is not as tightly
focussed, so there is more chance for bugs).

I hope this makes you think about security in more than just "security
patches" mindset. I think debian has a long ways to go before I will
consider it as easy to keep secure as obsd.

I'll also mention that many of the discussions I witnessed on the debian
mailing lists were very philosophical in nature, rather than pragmatic.
That doesn't lead to real, tangible results...