[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#230704: zope-testcase: SOFTWARE_HOME and INSTANCE_HOME can break install.



"Donovan Baarda" <abo@minkirri.apana.org.au> wrote:

> G'day,

Hi,

> I was going to reply "this is why many packages sanitize PATH in their
> scripts", but after checking through /var/lib/dpkg/info/* it seems they
> don't.

Indeed, Policy § 6.1 says they should not:

,----
| Programs called from maintainer scripts should not normally have a path
| prepended to them. Before installation is started, the package
| management system checks to see if the programs ldconfig,
| start-stop-daemon, install-info, and update-rc.d can be found via the
| PATH environment variable. Those programs, and any other program that
| one would expect to be on the PATH, should thus be invoked without an
| absolute pathname. Maintainer scripts should also not reset the PATH,
| though they might choose to modify it by prepending or appending
| package-specific directories. These considerations really apply to all
| shell scripts.
`----

> Does dpkg do any path sanitization itself? I'm kinda surprised if it
> doesn't, because as you say many things can break.

Well, that depends on what you call sanitization. As indicated by the
paragraph I quoted from Policy, dpkg will bomb if e.g. it doesn't find
start-stop-daemon in its PATH (I've seen it happen). However, it seems
it will not set PATH to a minimum, "conservative" value.

> Most security sensitive scripts do sanitize PATH before they execute,
> because PATH munging can be used as a security attack on scripts that don't.
> I would have thought dpkg would fall into that catagory.

Well, this can only be a problem when dpkg is run by root (otherwise
maintainer scripts are not run). If root's PATH has been mangled, the
attacker is already root (he could also mangle IFS and use whatever
technique makes setuid root shell scripts very risky [and therefore not
supported under Linux]).

I suppose the current Policy wants to allow the admin to use custom
executables (e.g., compiled with SSP) instead of the canonical Debian
ones if he so desires.

-- 
Florent



Reply to: