Tracking Security in Ports and Base System
chris at chrismaness.com
Wed Mar 1 22:21:49 PST 2006
Randy Pratt wrote:
> On Wed, 1 Mar 2006 14:31:55 -0800 (PST)
> Chris Maness <chris at chrismaness.com> wrote:
>> On Wed, 1 Mar 2006, Randy Pratt wrote:
>>> On Wed, 1 Mar 2006 10:09:51 -0800 (PST)
>>> chris at chrismaness.com wrote:
>>>>> On Wed, 8 Feb 2006, Chris Maness wrote:
>>>>>> How should I set up cvsup to just track security updates for ports. And
>>>> would the best thing to do after I synced CVS, do portupgrade -a so
>>>> that everything selected gets rebuilt.
>>>>> I'm not sure there is a way to do this for ports, other than manually
>>>> checking what's been changed and whether you consider that to be a
>>>> security upgrade, then upgrading each applicable port by hand. As far as
>>>> I understand, there is only one tag for ports ("tag=."), which gets you
>>>> the "current" ports tree. I *can* guarantee that others know more about
>>>> this than I do.
>>> There is a port which does this for you (security/portaudit):
>>> portaudit provides a system to check if installed ports are
>>> listed in a database of published security vulnerabilities.
>>> After installation it will update this security database
>>> automatically and include its reports in the output of the
>>> daily security run.
>>>>>> What is the equivalent for the base system?
>>>>> Much simpler: just track RELENG_your_release to get security updates and
>>>> bug fixes and nothing else. For example, mine is RELENG_5_4 and
>>>>> therefore tracks 5.4-RELEASE.
>>> Additionally, I'd suggest subscribing to one of these mailing list so
>>> that you are notified when a SA is issued:
>>> security-advisories at freebsd.org
>>> freebsd-announce at freebsd.org
>> Thanks, I do have port audit installed. I was refering to system
>> security. The base system + FreeBSD userland. I wanted to do this
>> because I did get a notice from the security list today. Do I do a make
>> buildworld, to update the system? Do I do this in /usr/src ?
> The only thing that portaudit does is to apprise you of potential
> problems. You would need to update ports (/usr/ports) to fix those
> issues. I probably misunderstood your question. I'll attempt to
> go into more detail.
> Just so we're talking the same language, I call anything that is
> built/installed from /usr/src the 'base system'. Some people break
> this down into kernel+userland. Perhaps this is the userland to
> which you refer.
> I call anything built/installed from /usr/ports "third-party
> applications" or the "ports tree". Some people also call this userland
> Each one is updated independent of the other.
> If you want to update the things from /usr/src (base system), refer
> to the Handbook (Chapter 21 The Cutting Edge ). In particular:
> It may appear complicated because of all the explanation given there
> and the different branches covered but its a pretty easy process once
> you work thru it. I suggest going through the document and make
> yourself a crib sheet. Here's an example of how one might
> cvsup -g -L 2 stable-supfile
> # READ this!!
> less /usr/src/UPDATING
> #If an old backup exists (/etc.old) remove it
> rm -rf /etc.old
> #Make a new backup of /etc
> cp -Rp /etc /etc.old
> adjkerntz -i
> cd /usr/obj
> chflags -R noschg *
> rm -rf *
> cd /usr/src
> make buildworld
> #Check custom kernel config for changes after cvsup
> #modify as needed. If using GENERIC kernel, just leave
> #off the "KERNCONF=CUSTOM" part.
> cd /usr/src
> make buildkernel KERNCONF=CUSTOM
> make installkernel KERNCONF=CUSTOM
> # need to be in single user mode at this point
> # either reboot to single user mode according to the handbook
> # or alternatively "shutdown now" according to the handbook
> cd /usr/src
> make installworld
> Please don't use the above as a substitute for reading the Handbook
> in detail and applying it to your own situation. In all cases, the
> Handbook takes precedence over the above. I also do not recommend
> using a scripted approach until you are comfortable with the
> Note that the preceeding does not update anyting that was installed
> from the ports tree (/usr/ports/...). The usual tool for doing
> ports updating is sysutils/portupgrade. A typical update would
> be like:
> #make sure dependencies are in order before starting
> #Fix any problems before starting an update.
> pkgdb -F
> #update the ports tree
> #Note that the ports tree uses only one tag "."
> cvsup -g -L 2 ports-supfile
> #Read UPDATING
> less /usr/ports/UPDATING
> #Backup the package database
> tar-czvf /home/username/backup_dbpkg.tgz /var/db/pkg
> #Create a ports INDEX
> cd /usr/ports
> make index
> #Create the ports database
> portsdb -u
> #Update all ports that are out-of-date
> portupgrade -a
> #Clean out old ports source tarballs
> portsclean -DD
> #Finally check that dependencies are still happy
> pkgdb -F
> It is *so important* that you read the UPDATING files that I cannot
> stress that enough. The /usr/ports/UPDATING may contain information
> that may impact the process of updating ports; ie, there may be
> special things that have to be done. Some of the most recent
> entries are examples of that. The libtool update is a example of
> a major impact.
> Normally you would only build the ports that needed updated, but
> in the case of the libtool update, its probably best to use
> portupgrade -fa
> which forces *all* ports to be rebuilt. Obviously, this can take
> a lot of time depending on the number of ports you have installed,
> and the hardware you're using.
> At other times the ports/UPDATING may contain other specific
> instructions to do before updating other ports.
> When using the UPDATING files (ports or src), they are in reverse
> chronological order (newest first). Find where you last updated (or
> installed) then read back toward the top of the file noting anything
> that may apply to your situation.
> There is also information in the Handbook regarding the ports system
> which may be of interest to you.
> As a side note, I know that there are other paths to updating
> ports and other tools that sometimes reduce the work but rather than to
> confuse the OP, I'm choosing not to mention them. If I omitted
> something in my description, feel free to jump in.
> I hope this helps give you some insight into the processes. Of course,
> in reading all the information and references, if you still have
> questions, be sure and ask the list ;-)
> Best regards,
Thanks for the blow by blow. I found a similar list in the make file,
and did the deed. Seems like every thing's working.
More information about the freebsd-questions