Re: Packages' use of dpkg-statoverride
On Thu, Jan 11, 2001 at 01:17:59PM -0500, Joe Drew wrote:
> On Thu, Jan 11, 2001 at 12:12:27PM -0500, Matt Zimmerman wrote:
> > Yes, but this is while the package is in the 'unconfigured' state. It is
> > not unusual or unacceptable for a package to be somewhat broken when it has
> > just been unpacked and not configured.
>
> It's not a question of broken; making a lot of programs (like mine for
> instance, lxdoom) suid could be a security risk. The window Wichert talks
> about is a window of opportunity where a binary is installed suid and can be
> exploited, before the system administrator decides (for whatever reason -
> bugtraq or otherwise) to remove the suid bit. That's why I ship lsdoom by
> default as not suid, and then enable the suid bit later at the request of the
> sysadmin.
As I said in my original message, to avoid a problem like this, all binaries
should be shipped non-suid, and optionally overridden to suid. The worst that
could happen if a binary that should be suid is not is that it will not work
correctly. There should be no security risk.
If the package asks whether to set an override (i.e., whether to make a binary
suid), the user can easily check before installing the package
(dpkg-preconfigure) whether it contains such a binary (unfortunately, this
involves running a package-supplied script, but one could also extract the
templates and read them). This gives them the opportunity to create their own
override before unpacking the package, which the maintainer scripts should then
leave alone.
--
- mdz
Reply to: