Request For Candidates: Application Review Board

[James Westby]

On Thu, 26 Aug 2010 11:32:18 +0200, Stephan Hermann <sh at sourcecode.de> wrote:
> So, what James and you are thinking about is something like Slackwares tgz format,
> it's a prebuild binary packaged with tar.gz and put a wrapper around which installs the 
> simple app under $HOME/Apps/ (example!!!) for user only installations. Therefore the install script 
> (maintainer script) only needs user permissions. 

No, as I understand it, it is a .deb, but without maintainer scripts
(with triggers to take care of things, rather than arbitary code), and
any other restriction that we wish to place, such as no /etc/cron*
files. (I'm not sure I agree with pitti that we should go outside the
standard FHS here, but it does have a nice fail-closed property.)

This is still a .deb that is installed normally, but it removes one
mechanism by which the package can run things as root, and so gives a
smaller area to audit. As a bonus we get fewer issues from wonky
maintainer scripts, and the ability to rollback their installation.
The aim is to have all manipulations at install time be done by known
code, dpkg, and not arbitrary code in the package.

Scott is absolutely correct that it does nothing to protect user data,
and that is not the intent. We need other approaches for doing that, but
it does reduce the code review burden, as we can be fairly confident
that the package can do nothing nasty as root at install time, or via
means such as installing a cron job to run as root. We still have to
audit the application code, which may attack user data, or attempt
priveledge escalation.

A secondary benefit is that such packages would perhaps be easier to
install with user priveleges for those that wish to do that. However,
it's not just maintainer scripts that are an issue here, it's also
providing parallels for everything such as .desktop files in the users'
homedir, and remapping paths as needed to support that. Plus, as Marc
says, it's not necessarily a wise idea to use the homedir for that
anyway. Looking at a per-user installation area that is not directly
writeable by that user could be a better way to go. We first need the
discussion over whether we want per-user, or system-wide install of
these things, and then we look at the mechanism. Those who are keen on
homedir installs for other reasons, this is not the answer you are
looking for.

Thanks,

James