I administer a remote server and want to apply some of the security patches. (I assume this is the best way to go since I can't go into single-user mode to use CVsup). I have a couple of questions. First, I have installed one of the pgp ports to verify the patches. When I run it, I get this message:> File 'buffer46.patch.asc' has signature, but with no text. > Text is assumed to be in file 'buffer46.patch'. > signature not checked. > Signature made 2003/09/17 18:02 GMT > key does not meet validity threshold.> WARNING: Because this public key is not certified with a trusted > signature, it is not known with high confidence that this public key > actually belongs to: "(KeyID: 0xCA6CDFB2)".I guess that I need to do some additional set up to get pgp to validate this file. Can anyone tell me where to find a howto on this subject or tell me what to do? Second, Do I have apply each patch, then run make after each patch, or can I apply all the patches and just run make once? Any other advice or suggestions on updating a remote system would be appreciated.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thursday 25 September 2003 20:01, V. Jones wrote:> I administer a remote server and want to apply some of the security > patches. ?(I assume this is the best way to go since I can't go into > single-user mode to use CVsup).Why do you want to go into single user mode to use cvsup anyway? I cvsup as normal, use screen(1) to do a compile (the box is headless so I check on the compile periodically using ssh), and then only go into single user when I do the 'make installworld'. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP ID: 0x33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/cz8qF8Iu1zN5WiwRAh2xAJ46jWX6gqlUEipe2O0ngOL0ZdypFQCePW6m +o00iiNf/B2OdVSZLfCw0Eg=WmI/ -----END PGP SIGNATURE-----
V. Jones wrote:>I administer a remote server and want to apply some of the security patches. (I assume this is the best way to go since I can't go into single-user mode to use CVsup). > >First: you can update your system without booting into single-user mode. I hope I don't get chewed out for suggesting this, but if there's nobody physically *at* your server to do the update for you, you're going to have to do it yourself (see below).>I have a couple of questions. First, I have installed one of the pgp ports to verify the patches. When I run it, I get this message: > > > >>File 'buffer46.patch.asc' has signature, but with no text. >>Text is assumed to be in file 'buffer46.patch'. >>signature not checked. >> Signature made 2003/09/17 18:02 GMT >> key does not meet validity threshold. >> >> > > > >>WARNING: Because this public key is not certified with a trusted >>signature, it is not known with high confidence that this public key >>actually belongs to: "(KeyID: 0xCA6CDFB2)". >> >> > >I guess that I need to do some additional set up to get pgp to validate this file. Can anyone tell me where to find a howto on this subject or tell me what to do? > >Sure. IIRC, this just means that you've not marked the person's (KeyID: 0xCA6CDFB2) signature as trusted. You'll need to connect to a keyserver and download the information about the person with KeyID: 0xCA6CDFB2. If you trust that you've the right data, you can mark said person as trusted.>Second, Do I have apply each patch, then run make after each patch, or can I apply all the patches and just run make once? > >Any other advice or suggestions on updating a remote system would be appreciated. > >You can apply all the patches and run make one time. If you're not interested in rebuilding the entire userland (and you're not installing newer versions of userland utilities that rely on an updated kernel), you can just run cvsup, download the source, and run make from within the desired directories. The handbook recommends that one drop into single user mode to build the world. While this is certainly best practice, it is by no means absolutely necessary. I administer several servers in up to nine time zones away from me and, whenever there's a security advisory, I either a) rebuild the entire userland and kernel if I've found enough things I need to change/tune at kernel level, or b) rebuild and install the affected patches (which may actually cause option a -- rebuilding the world -- to be a necessity). Again, building the world under single-user mode is a highly suggested best practice. It is by no means absolutely necessary and I've been doing it for a good while with no problems (never had a problem with it). I'd be glad to help you out with it privately, if you so wish. --Devon
On Thu, 25 Sep 2003, V. Jones wrote:> I administer a remote server and want to apply some of the security > patches. (I assume this is the best way to go since I can't go into > single-user mode to use CVsup).I generally follow the following practice: cvsup in multiuser buildworld in multiuser buildkernel in multiuser These stages, other than impact on cpu, memory, disk i/o speed, and storage space, shouldn't interact with the running environment and so shouldn't be a problem. Then comes the slightly more tricky bit: I decide whether I'm willing to update while running multiuser. If I am: installkernel reboot installworld mergemaster reboot If I'm not, the procedure is much the same except that I boot only to single-user after the first reboot, mount -a, swapon, and proceed. Note that there are a number of risks and complications associated with the installworld and mergemaster steps, both in multiuser and singleuser mode. multiuser is typically more risky: for example, if mergemaster notices a change to MAKEDEV, it will prompt to recreate devices. DO NOT DO THIS ON A LIVE MULTIUSER SYSTEM. :-) If you do run it, it will reset all the permissions in /dev, leaving in-use ttys world readable and writable. This will permit unprivileged users to potentially sniff the I/O for more privileged users, send output to their display, etc. So it's fine in single-user, but not multi-user. Typically, that sort of change doesn't occur on the security/release branches, but will happen with moderate frequency as you track -STABLE.> I have a couple of questions. First, I have installed one of the pgp > ports to verify the patches. When I run it, I get this message: > > > File 'buffer46.patch.asc' has signature, but with no text. > > Text is assumed to be in file 'buffer46.patch'. > > signature not checked. > > Signature made 2003/09/17 18:02 GMT > > key does not meet validity threshold. > > > WARNING: Because this public key is not certified with a trusted > > signature, it is not known with high confidence that this public key > > actually belongs to: "(KeyID: 0xCA6CDFB2)". > > I guess that I need to do some additional set up to get pgp to validate > this file. Can anyone tell me where to find a howto on this subject or > tell me what to do?PGP relies on a "web of trust". Users sign each others identities to bind them to keys. Your local PGP keyring will hold any keys and signatures you've stuffed in there. PGP determines "trust" by building a path of signatures and validations between you and the target key. There are various parameters to determine the degree of transitivity to trust, etc. There's fairly extensive documentation of the PGP trust model on various web pages, but you can read the above warning as simply "There is no path of signatures between your trusted keys and the key used to sign this message/file". For the highest level of confidence, attend a USENIX or BSDCon key signing, and sign the security-officer key yourself once you've seen the fingerprint, etc. For lower levels of confidence, go to a key-signing event with someone who has signed the security-officer key, etc, etc.> Second, Do I have apply each patch, then run make after each patch, or > can I apply all the patches and just run make once?It depends a bit on the patches and the branch. If you're tracking a release/patch branch, you can cvsup forward to the head of the branch, then rebuild the identified components. Sometimes, patches and update activities coallesce well (unrelated change to unrelated binaries). Sometimes, less well -- you might have to make sure to build libraries before binaries, for example, or apply a series of sendmail or ssh patches in order. Cvsuping forward and rebuilding world and kernel is a reasonable answer for most people, and means you don't have to worry about the ordering. FYI, regarding your general interest in advice: the single best piece of advice for remotely administered systems is to get a serial console. That way if something gets messed up, you have a decent chance of being able to fix it. It means you have full access to single-user mode, you can select which kernel to run at boot, even have multiple root file systems (production, backup) and swap between them. It takes a lot of the risk out of upgrades by providing a good escape route if networking fails to come up properly, for example. With the recent ARP fix, there was a functional regression in the first version of the patch, which caused routing to fail under some circumstances. If you had access to a serial console for a remote box, you were fine because you could revert to the previous kernel once you noticed the problem. Otherwise, you might be out of luck... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Probably this should included in the FAQ, very good and detailed answer... --------- Original Message -------- From: Robert Watson <rwatson@freebsd.org> To: V. Jones <vjones62@earthlink.net> Cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Patch question Date: 26/09/03 00:15> > > On Thu, 25 Sep 2003, V. Jones wrote: > > > I administer a remote server and want to apply some of the security > > patches. (I assume this is the best way to go since I can't go into > > single-user mode to use CVsup). > > I generally follow the following practice: > > cvsup in multiuser > buildworld in multiuser > buildkernel in multiuser > > These stages, other than impact on cpu, memory, disk i/o speed, and > storage space, shouldn't interact with the running environment and so > shouldn't be a problem. Then comes the slightly more tricky bit: I decide > whether I'm willing to update while running multiuser. If I am: > > installkernel > reboot > installworld > mergemaster > reboot > > If I'm not, the procedure is much the same except that I boot only to > single-user after the first reboot, mount -a, swapon, and proceed. > > Note that there are a number of risks and complications associated with > the installworld and mergemaster steps, both in multiuser and singleuser > mode. multiuser is typically more risky: for example, if mergemaster > notices a change to MAKEDEV, it will prompt to recreate devices. DO NOT > DO THIS ON A LIVE MULTIUSER SYSTEM. :-) If you do run it, it will reset > all the permissions in /dev, leaving in-use ttys world readable and > writable. This will permit unprivileged users to potentially sniff the > I/O for more privileged users, send output to their display, etc. So it's > fine in single-user, but not multi-user. Typically, that sort of change > doesn't occur on the security/release branches, but will happen with > moderate frequency as you track -STABLE. > > > I have a couple of questions. First, I have installed one of the pgp > > ports to verify the patches. When I run it, I get this message: > > > > > File 'buffer46.patch.asc' has signature, but with no text. > > > Text is assumed to be in file 'buffer46.patch'. > > > signature not checked. > > > Signature made 2003/09/17 18:02 GMT > > > key does not meet validity threshold. > > > > > WARNING: Because this public key is not certified with atrusted> > > signature, it is not known with high confidence that this publickey> > > actually belongs to: "(KeyID: 0xCA6CDFB2)". > > > > I guess that I need to do some additional set up to get pgp tovalidate> > this file. Can anyone tell me where to find a howto on this subjector> > tell me what to do? > > PGP relies on a "web of trust". Users sign each othersidentities to bind> them to keys. Your local PGP keyring will hold any keys and signatures > you've stuffed in there. PGP determines "trust" by building apath of> signatures and validations between you and the target key. There are > various parameters to determine the degree of transitivity to trust, etc. > There's fairly extensive documentation of the PGP trust model on various > web pages, but you can read the above warning as simply "There is nopath> of signatures between your trusted keys and the key used to sign this > message/file". For the highest level of confidence, attend a USENIXor> BSDCon key signing, and sign the security-officer key yourself once you've > seen the fingerprint, etc. For lower levels of confidence, go to a > key-signing event with someone who has signed the security-officer key, > etc, etc. > > > Second, Do I have apply each patch, then run make after each patch,or> > can I apply all the patches and just run make once? > > It depends a bit on the patches and the branch. If you're tracking a > release/patch branch, you can cvsup forward to the head of the branch, > then rebuild the identified components. Sometimes, patches and update > activities coallesce well (unrelated change to unrelated binaries). > Sometimes, less well -- you might have to make sure to build libraries > before binaries, for example, or apply a series of sendmail or ssh patches > in order. Cvsuping forward and rebuilding world and kernel is a > reasonable answer for most people, and means you don't have to worry about > the ordering. > > FYI, regarding your general interest in advice: the single best piece of > advice for remotely administered systems is to get a serial console. That > way if something gets messed up, you have a decent chance of being able to > fix it. It means you have full access to single-user mode, you can select > which kernel to run at boot, even have multiple root file systems > (production, backup) and swap between them. It takes a lot of the risk > out of upgrades by providing a good escape route if networking fails to > come up properly, for example. With the recent ARP fix, there was a > functional regression in the first version of the patch, which caused > routing to fail under some circumstances. If you had access to a serial > console for a remote box, you were fine because you could revert to the > previous kernel once you noticed the problem. Otherwise, you might be out > of luck... > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to"freebsd-security-unsubscribe@freebsd.org"> > > > >________________________________________________ WEB ISP - leader in wireless/DSL/dialup services in Armenia. Go to http://www.web.am/
In the last exciting episode of the freebsd-security-request@freebsd.org saga on Fri, Sep 26, 2003 at 12:02 , freebsd-security-request@freebsd.org as heard to say:> ------------------------------> Message: 3 > Date: Thu, 25 Sep 2003 21:52:32 +0200 > From: "Devon H. O'Dell" <dodell@sitetronics.com> > Subject: Re: FreeBSD Patch question[Much deleted - wjv]> The handbook recommends that one drop into single user mode to > build the world. While this is certainly best practice, it is > by no means absolutely necessary.Can you point this out - I've just looke at the handbook and I do NOT find anything like that in there. I see installworld in single, but not buildworld. This is from the handbook - note that it >recomends< installworld in single - though on my remote machines I've not had that luxury. ======================================= Beginning with version 2.2.5 of FreeBSD (actually, it was first created on the FreeBSD-CURRENT branch, and then retrofitted to FreeBSD-STABLE midway between 2.2.2 and 2.2.5) the world target has been split in two: buildworld and installworld. As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld installs this tree on the current machine. This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is ``self hosted''. Because of this, you can safely run buildworld on a machine running in multi-user mode with no fear of ill-effects. It is still recommended that you run the installworld part in single user mode, though. Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run make buildworld and make installworld on A. B and C should then NFS mount /usr/src and /usr/obj from A, and you can then run make installworld to install the results of the build on B and C. Although the world target still exists, you are strongly encouraged not to use it. =======================================> End of freebsd-security Digest, Vol 27, Issue 4Bill -- Bill Vermillion - bv @ wjv . com
Thanks to everyone who responded - my question really had more to do with applying patches as they are presented in the various security advisories. It sounds like most of you don't do it that way; it sounds like you track freebsd-stable using cvsup. However, section 21.2.2.2 of the handbook seems to advise against doing this when all you want to do is apply security fixes: "While it is true that security fixes also go into the FreeBSD-STABLE branch, you do not need to track FreeBSD-STABLE to do this. Every security advisory for FreeBSD explains how to fix the problem for the releases it affects [1] , and tracking an entire development branch just for security reasons is likely to bring in a lot of unwanted changes as well." My intention is to apply the patches as instructed in the advisories. I'll resolve my issues with pgp so that I can validate the files first, then apply them one at a time.