Request For Candidates: Application Review Board

[Allison Randal]

On 28/08/10 09:22, Rick Spencer wrote:
> On Fri, 2010-08-27 at 21:18 -0700, Steve Langasek wrote:
>>
>> /etc/cron* is not the only place that a package could install files that
>> would result in untrusted code running as root.  /etc/rc*.d, /etc/init,
>> /etc/dpkg, /etc/apt,... even installing a binary that shadows the name of a
>> system binary into /usr/local/bin or /usr/bin could result in privilege
>> escalation.  To really avoid the possibility of such a package running code
>> as root, I think you have to require that it *only* ship files in /opt, and
>> not include /opt directories on root's path.

Aye, we'll be adding to the list of restrictions as we go. I like the
idea of flipping the instructions for new developers around to a DO
instead of a DON'T ("do install all your files in /opt"). But, we should
still build up the restriction list for the PostReleaseApps reviewers to
use, like a watch-list for red flags.

We already have a requirement that PostReleaseApps aren't allowed to be
duplicates or modifications of any package that is already in
main/universe, so an app doing name shadowing will be rejected.

>> If you're going to be relying on such rules to help protect the user from
>> malicious packages, I strongly recommend that this be subjected to detailed
>> scrutiny from and sign-off by the Ubuntu Security Team prior to deployment.
> 
> To me, the rules are really about helping streamline the review process,
> making the packages easier to review by reducing the kinds of
> functionality that require close scrutiny. As a reviewer, you don't have
> to consider if an app is going to do anything damaging with a maintainer
> script, because there are no maintainer scripts, for example.

Yah, these restrictions don't at all qualify as the kind of technology
restrictions that would allow us to pass packages through a lighter
review process than the current PostReleaseApps process (which includes
a security review). What we're doing here is more clearly defining what
we mean by "lightweight apps". Apps that cross over certain lines of
complexity won't be considered for PostReleaseApps, and will have to
follow the full REVU process.

I suppose I'm a bit of a security hardnose, but I'm not even comfortable
relying on root's path. There's a random chance of some other completely
unrelated package on the system opening up a security hole. (i.e.
package A adds /opt to root's path for its own innocent purposes, not
suspecting it could be any kind of security risk, and package B takes
advantage of it. Since the two are never reviewed together, the overall
threat isn't found.)

> In any case, I think a review by the security is a team is good idea.

Definitely. Kees is on the Technical Board, and carefully reviewed the
current PostReleaseApps process. I met with him a couple of days ago,
and he says he'll keep an eye on the process as it changes over time. I
trust him to let us know if it ever strays in an insecure direction, so
we can pull it back.

Allison