[packman] Packman security policy questions

[Aniruddha]

On Sat, 2007-11-03 at 21:48 +0100, Manfred Tremmel wrote:
> Am Samstag, 3. November 2007 schrieb Andreas Schneider:
> > Aniruddha wrote:
> > > Actually this is even more easy then it sounds (and I am not a
> > > programmer). It only requires to document some simple rules for
> > > package handling (e.g. that packager should check for malware, and
> > > the monitoring of some standard security bulletins).
> >
> > It is easy? Ok.
> >
> > How should we check a new version of an application/program for
> > malware?
> 
> At the moment we do have only 3.8 GByte in our 10.3 SRPM-directory, so 
> it shouldn't be a problem to check the sources line by line.
> Next packages will be available in the year 2350 ;-)
> It's all a question of (wo)manpower and the number of packages. We do 
> have more then thousand packages and only a view sparetime packages. We 
> can trust the programers, and go on like now, or review every tarball 
> and reduce the number of packages to three or four for every packager.
> 

Pleas check my mail to Andreas Schneider for answers to your questions:


Let's first define the context

1 We trust the author of the original package.
2 Checking for malware is only to prevent the (very slight chance) that
$upstream get's hacked and it's packages are modified to provide a
backdoor (rootkit, trojan).
3 We do not want to do a complete source audit, since it's too time
consuming and probably not necessary.

Now on the the question how to check a new version of an
application/program for malware. Since I am not a programmer I do not
not know a lot of screening sourcecode. I did understand however (from
(people who do know how to program) that a malicious modification should
be easy to spot. Can you confirm this?

Here are some general ideas

-How can we make sure $upstream arrives untampered? I do think that md5
of shasum checking is essential in order to verify that a package
arrives exactly as $upstream provides it.

-Put some kind of scanning (f-prot, kaspersky) software on the Packman
repo's.

-The expertise and experience of the packagers is also an important
factor. This experience makes that packagers could potentially see
faster when something is out of the ordinary.

-Set up a testing branch that people like me can use. I use rkhunter and
chrootkit and therefor I should be able to spot problems beforehand.
When no problems have been reported for some while the rpm's can be
moved to stable.

-Set up a security announcement mailing list and recruit people who can
monitor predefined channels for security issues.


-- 
Regards,

Aniruddha