Mailinglist Archive: opensuse-factory (471 mails)

< Previous Next >
[opensuse-factory] Security Implications of opening Factory
  • From: Marcus Meissner <meissner@xxxxxxx>
  • Date: Wed, 10 Jun 2009 17:02:35 +0200
  • Message-id: <20090610150235.GA11060@xxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >