[opensuse-factory] Security Implications of opening Factory
Hi, As you have read, Factory is opening for more Community Contributions. Henne explained it already in his post how this works: Basically several Topic Groups are founded consisting of Packagers who are the reviewers / maintainers of the packages in this group. The Topic Groups maintainers have full authority of what goes in in their part of openSUSE Factory, either maintain packages themselves and review contributions to their group. We will be boostrapping those groups with Novell employees. The groups themselves will then decide whom to accept into their ranks. So for the first time, we will have non-Novell employees submitting packages to openSUSE:Factory without being sourcelevel reviewed before. So what should you be aware in regards of Security of as topic group members? 1. Every single package can disturb / destroy the integrity of the whole openSUSE Factory distribution. (As in "install trojans, rootkits, etc.") Even if a package is not meant to be installed by default or by patterns, by specific RPM magic it could be pulled in into every install. So every package needs to be reviewed! 2. Reviewers have a way more difficult task than Packagers, and more responsibility The new submission model turns a lot of packagers into packager reviewers. As a packager you previously did: - Take a tarball from a known good mirror (e.g. ftp.gnu.org for GNU Hello), or built your tarball from a CVS/SVN/GIT checkout from a known good server. (If possible checking md5/sha1 sums of the tarballs) - built it, reviewed logoutput, did some tests. - submitted it. As a reviewer you however have different stuff to do (besides all usual technical review stuff of course): - Need to review the spec file and the patches for malicious code. Not so hard fortunately, but .spec files give best attack possibilities so every line needs to be reviewed. - Review tarballs for malicious code. Very hard. You get tarballs from an unknown source and have to find out if this is is not infected by backdoors or similar. The submission might say "This is GNU hello-3.1.tar.bz2 from ftp.gnu.org", but you cannot be sure. How to find out? You either trust the submitter, you review the tarball (or its diff) or replace it with a known good one (from the original server). - The security team still reviews all security relevant changes that we previously reviewed, like: * new and largely changed daemons * new and largely changed setuid / setgid binaries * new and largely changed network services * new world writeable directories. So please involve us if you see something matching. 3. Have a look at your projects Buildservice permissions. There are 2 kinds of permissions. Project permissions and package permissions. Check and have an eye on each and every instance of the <person> tags in the different meta files (osc meta prj PROJECT and osc meta pkg PROJECT PACKAGE) because as we stated in 1. a single package an disturb / destroy the integrity of the whole 4. Usernames or E-Mails may look deceiving. Slightly misspelled usernames or e-mails of known good submitters could be used to gain your trust. Cross check. Improvements to user management probably can / need to be done here. 5. Easy thinkable attack scenario is people who behave good for a while, but after some months of doing occasional good submits start submit bad code. This counts more for group members but also for developers submitting regulary to groups. Or a known submitter whose account was hacked. -> Always keep such a thing in the back of your head and watch for behavioural changes. Trust your gut feeling and check twice if in doubt! Likely I forgot stuff ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
- Review tarballs for malicious code. Very hard.
The to be used tarball often has md5 sum or other hash on project downloadpage, why not introduce a hashfield for every source in the spec that needs to match the hashsum of the tarball, so a reviewer only needs to verify the hashsums in the .spec files match the ones from project download page, then the ball about malicous code is upstream =) Karsten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 10 June 2009 01:22:19 pm Karsten König wrote:
then the ball about malicous code is upstream =)
Which doesn't help much to have dependable distro. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 10 of June 2009 20:22:19 Karsten König wrote:
- Review tarballs for malicious code. Very hard.
The to be used tarball often has md5 sum or other hash on project downloadpage, why not introduce a hashfield for every source in the spec that needs to match the hashsum of the tarball, so a reviewer only needs to verify the hashsums in the .spec files match the ones from project download page, then the ball about malicous code is upstream =)
There's a planned feature of BuildService - it will be able to download source code directly from upstream. Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 10 Jun 2009, Karsten König wrote:
The to be used tarball often has md5 sum or other hash on project downloadpage, why not introduce a hashfield for every source in the spec that needs to match the hashsum of the tarball, so a reviewer only needs to verify the hashsums in the .spec files match the ones from project download page, then the ball about malicous code is upstream =)
With FreeBSD we have been doing this for ages, including MD5 and SHA hashes as well as the file size as part of the equivalent of spec there. It's been working pretty well, so I recommend we do this for openSUSE, too. Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Product Management T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex
On Fri, Jun 12, 2009 at 12:24:15PM +0300, Gerald Pfeifer wrote:
On Wed, 10 Jun 2009, Karsten König wrote:
The to be used tarball often has md5 sum or other hash on project downloadpage, why not introduce a hashfield for every source in the spec that needs to match the hashsum of the tarball, so a reviewer only needs to verify the hashsums in the .spec files match the ones from project download page, then the ball about malicous code is upstream =)
With FreeBSD we have been doing this for ages, including MD5 and SHA hashes as well as the file size as part of the equivalent of spec there.
It's been working pretty well, so I recommend we do this for openSUSE, too.
Well, the only way to be doing this effectively is to make it mandatory. If we enforce this to be mandatory there will be quite an outcry, because we did not do this before and it actually causes even more work. Also it does not address the issue here tarballs are taken from SVN/GIT/etc checkouts. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Moin, Am Freitag, 12. Juni 2009 11:26:31 schrieb Marcus Meissner:
Well, the only way to be doing this effectively is to make it mandatory.
For the main repository, I think the other obs repos don't really need such a level of integrity check
If we enforce this to be mandatory there will be quite an outcry, because we did not do this before and it actually causes even more work.
How does this cause more work then " You either trust the submitter, you review the tarball (or its diff) or replace it with a known good one (from the original server)." The first one is easiest, but might not fit everytime, reviewing tarball or diff isn't something feasable, and just upping a knowing good one, well the reviewer could have done that in the first place. Another idea would be to display md5 / sha1 etc sums for all the files in osc and web interface so people can quickly review manually where it makes sense (as in: tarball used)
Also it does not address the issue here tarballs are taken from SVN/GIT/etc checkouts.
Gah, right, but again you don't want to review the whole version? People with higher credibility ranking could sign off the submit + hash sum? Regards, Karsten PS: As Gerald lined out FreeBSD is doing that, Arch Linux is doing that as well =) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 12 juin 2009, à 11:26 +0200, Marcus Meissner a écrit :
On Fri, Jun 12, 2009 at 12:24:15PM +0300, Gerald Pfeifer wrote:
On Wed, 10 Jun 2009, Karsten König wrote:
The to be used tarball often has md5 sum or other hash on project downloadpage, why not introduce a hashfield for every source in the spec that needs to match the hashsum of the tarball, so a reviewer only needs to verify the hashsums in the .spec files match the ones from project download page, then the ball about malicous code is upstream =)
With FreeBSD we have been doing this for ages, including MD5 and SHA hashes as well as the file size as part of the equivalent of spec there.
It's been working pretty well, so I recommend we do this for openSUSE, too.
Well, the only way to be doing this effectively is to make it mandatory.
(we could make this "recommended" for one cycle, and then mandatory, I guess)
If we enforce this to be mandatory there will be quite an outcry, because we did not do this before and it actually causes even more work.
Sure, it'll be painful. But if it's worth it for security, then we could do some experimentation with volunteers to see if this is something they can handle. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Marcus Meissner wrote:
4. Usernames or E-Mails may look deceiving.
Slightly misspelled usernames or e-mails of known good submitters could be used to gain your trust. Cross check.
Improvements to user management probably can / need to be done here.
This risk can be drastically reduced by making use of GPG signatures a must. Can osc be enhanced to sign the commits and submitrequests with user's GPG key? -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)---
participants (8)
-
"Karsten König"
-
Gerald Pfeifer
-
Jano Kupec
-
Karsten König
-
Marcus Meissner
-
Michal Vyskocil
-
Rajko M.
-
Vincent Untz