Tracking Security in Ports and Base System

[Chris Maness]

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
>>>
>>> HTH,
>>>
>>> Randy
>>> -- 
>>>
>>>       
>> 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
> applications.
>
> 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:
>
>   http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
>
> 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
> look:
>
> 	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
>
> 	mergemaster
>
> 	reboot
>
> 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
> process.
>
> 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 "."
> 	#/usr/share/examples/cvsup/ports-supfile
> 	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,
>
> Randy
>  -- 
>   
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.