>Number:         23048
>Category:       pkg
>Synopsis:       pkg_install fails to ensure integrity of symbolic links
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 03 19:49:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Klaus Klein
>Release:        NetBSD 1.6ZC
>Organization:
Frobozz Magic Standards Company
>Environment:

>Description:
	pkg_install does not ensure the integrity of symbolic links;
	this is a bit surprising since it does, on the other hand,
	record digests of regular files installed.

	Consider the following (arbitrarily chosen) scenario:

	lrwxr-xr-x [...] lib/librecode.so@ -> librecode.so.0.0
	lrwxr-xr-x [...] lib/librecode.so.0@ -> librecode.so.0.0
	-rwxr-xr-x [...] lib/librecode.so.0.0

	This results in the following packaging list fragment:

	lib/librecode.so
	lib/librecode.so.0
	lib/librecode.so.0.0
	@comment MD5:b3939cd72cd6d481f0f7f18b5f740245

	That is, only the regular file has an integrity record.
	Now, consider dynamic linking characteristics:

	$ ldd bin/recode
	bin/recode:
		 -lintl.0 => /usr/lib/libintl.so.0
		 -lrecode.0 => /usr/pkg/lib/librecode.so.0
		 -lc.12 => /usr/lib/libc.so.12

	It sufficient to compromise the unprotected symbolic link
	in order compromise applications depending its original,
	integrity-checked target.

>How-To-Repeat:

>Fix:
	Create a record of symbolic links' targets.  In terms of simplicity,
	creating a new packaging list directive for symbolic links seems
	attractive, which would also have the advantage of marking them
	distinct from regular files in an obvious way.

	An alternative approach could be to record the link target in a
	comment directive similar to the current MD5 comment record.
>Release-Note:
>Audit-Trail:
>Unformatted: