[packman] Packman security policy questions

[Pascal Bleser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aniruddha wrote:
> On Sat, 2007-11-03 at 21:20 +0100, Andreas Schneider wrote:
>> 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?
>>
> Let's first define the context
> 
> 1 We trust the author of the original package.

Right. We can't do anything about that unless we do source code audits.

> 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).

OK.

> 3 We do not want to do a complete source audit, since it's too time
> consuming and probably not necessary.

Yes and no. It would be great to be able to do that, but we can't for
reasons explained a few times already.

> 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?

Absolutely not, it's extremely complex to spot. You have to read and
understand the complete source code (and I really mean every single line
of it). It's not like the source would contain
// hey, this is a trojan
hack_the_computer();

Another, more realistic option is to run the application in a secured
sandbox and monitor everything it's doing (file access, network access).
That's the sort of thing AppArmor and SELinux provide on the systems
that run the applications (e.g. on your PC). But it's not easy at all,
because you have to use all the features of the application and even
then, the malware might only be triggered under certain conditions (e.g.
if it's an application that listens on a network socket, when it
receives a certain request with a certain signature).

And either way, it's a huge investment of time and resources (we have
neither).

> 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.

That's something upstream has to provide in the first place. It's not
always the case. As an example, I'd say that 40-50% of the software we
package is hosted on Sourceforge. And Sourceforge doesn't provide
checksums of the tarballs.

The checksums themselves are not sufficient by any means, because if
someone hacks the server that hosts the upstream sources (say, in a
tarball), he can obviously also just replace the SHA sum file.
The checksums must be signed with the (GPG) key of the author. And that
key has to be trusted.
Have a look at "web of trust" and GPG papers on how that works.

It's a pretty secure approach, but almost impossible to set up for many
authors, many packages without doing a big project that encompasses all
distributions and almost all pieces of software produced for Linux and *BSD.

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

Not sure those are more trustworthy than upstream.
Could be an option I guess, but I really don't know whether it would
provide any benefit besides saying "our packages have been checked with
xxx". How effective are those virus scanners at detecting malware ?
Rootkits look just like normal code. One would definitely need
heuristics to detect them. And heuristics have a lot of false hits.

Who'd buy/donate an enterprise license for one of those proprietary
virus scanner applications ?

Running rkhunter and chkrootkit could be an option but again, I don't
know how good these are at effectively detecting malware. If the extra
work doesn't bring any benefits, then it's a loss.

> -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.

No, because we don't inspect the source code.
We just try to build it, then make a package out of it.
Personally, I don't even test 10% of the packages I produce (because I
don't use them and don't have the time to do so.. even a full-time job
wouldn't be sufficient for that).

> -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.

That could be an option. But it wouldn't make a difference to 99% of
people because they just want the latest version of something, period.
So you'd end up with almost everyone using the testing repository.
But well, that's probably the most interesting and realistic option, indeed.

Not easy, involves a lot of work, but probably feasible.

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

"Recruit people" ?
Whom ? We don't even have enough packagers.

cheers
- --
  -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
  /\\ <pascal.bleser at skynet.be>       <guru at unixtech.be>
 _\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHLPfLr3NMWliFcXcRAkuFAKC7pxQ68Emowsx8F/JuUe7ImKC6HwCfep2G
A+0yB5J3Mkmomzc73448s6o=
=nktS
-----END PGP SIGNATURE-----