On Wed, Oct 31, 2007 at 10:28:57PM +0100, Aniruddha wrote:

I wonder what are the security policies for openSUSE? What are the chances for malicious software (rootkits, trojans) being offered through the build service?

You have to trust the project you add the URL for.

What is the procedure for security holes and/or exploits in software offered in the openSUSE build repositories? I get the feeling openSUSE is becoming just as insecure as Windows hence the warning you get when adding repo's with 1-click install (see attachment). Or am I mistaken? Any info would be appreciated!

The openSUSE OSS and non-OSS repositories are secured as usual and the paranoid should only trust them. The buildservice repos should not be considered containing secured packages. The security fix policy for those is also left to the responsible maintainers. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, 2007-10-31 at 23:49 +0100, Aniruddha wrote:

On Wed, 2007-10-31 at 22:45 +0100, Marcus Meissner wrote:

...

On Wed, Oct 31, 2007 at 10:28:57PM +0100, Aniruddha wrote:

...

I wonder what are the security policies for openSUSE? What are the chances for malicious software (rootkits, trojans) being offered through the build service?

You have to trust the project you add the URL for.

...

...

What is the procedure for security holes and/or exploits in software offered in the openSUSE build repositories? I get the feeling openSUSE is becoming just as insecure as Windows hence the warning you get when adding repo's with 1-click install (see attachment). Or am I mistaken? Any info would be appreciated!

The openSUSE OSS and non-OSS repositories are secured as usual and the paranoid should only trust them.

The buildservice repos should not be considered containing secured packages.

The security fix policy for those is also left to the responsible maintainers.

Ciao, Marcus ---------------------------------------------------------------------

Is it just me or is this a giant step backwards? How can you trust a project when everybody can upload files with no infrastructure to check for malware? Even worse it is almost impossible to protect yourself against rootkits.

Are there any future plans to set up an security infrastructure with common rules for ensuring security?

Thinking of the average joe, openSUSE makes it so easy (with 1-Click install), that it is impossible for them to tell whether it's safe to add an repository or not. I can't even tell. On which factors should they decide? -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 31/10/2007, Aniruddha wrote:

Thinking of the average joe, openSUSE makes it so easy (with 1-Click install), that it is impossible for them to tell whether it's safe to add an repository or not. I can't even tell. On which factors should they decide?

It will still query whether to trust the repository & the key it is signed with. The same decision has to be made as when adding it manually, it is just less hassle. Now granted this "key" information isn't going to be very useful to your average person. Hopefully in the future this could be tied into a rating system which could look up how much the community trusts/recommends the packager & his/her packages. Showing a star rating in addition to the key would mean more I suspect. -- Benjamin Weber --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 31/10/2007, Aniruddha wrote:

In Gentoo/FreeBSD/Debian/Ubuntu/ you don't have to worry about that since the maintainer of that package checks this for you.

You are trusting the Gentoo/FreeBSD/Debian/Ubuntu packager to do the checks contientiously, and not insert anything malicious h(im|er)self.

Apparently in openSuSE there is no such safety precaution.

You have to trust the packager just the same. There are additional third party repositories for the other distributions too & you have to decide whether to trust those. SOme might argue that the core packages that make up the openSUSE distribution be trusted more as it is the base for SLE which has to have rigorous checks. But at the end of the day it depends who you trust. Since everything in the build service is free software you can always check the source the packages are built from yourself if you wish, and so can anyone else, which provides as much as a safeguard as possible. -- Benjamin Weber --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Дана четвртак 01 новембар 2007, Aniruddha је написао(ла):

And you don't have to trust the packager, you trust the distribution and it's security policy. And don't forget packages passes many hands before ending up in the stable tree. In Debian/Ubuntu it goes from Experimental to Unstable to Testing to Stable. I can assure that when it arrives at Stable you can trust it for 100%. Gentoo/FreeBSD is the same, they have a very, very long testing period for new packages finally arrive in the stable tree.

Compare this to the openSUSE buildservice where everyone can get an account start a repo and wreck havoc because there aren't any safety precautions.

I agree completly. Still, I would leave the build service as it is (in the end, I can make Gentoo portage overlay if I have space on web to upload ebuilds to, and since the size of such an overlay would be somewhere between 1 and 2 MB at the most, everybody can get that much online space). What I would do is add some additional rules/constraints on how to add "home:*" repositories. The rest of the repositories should be considered as something like "experimental/unstable/~x86/..." but checked for malicious code (or at least for malicious packagers). But home:* are completely free and unchecked and therefore should be at least restricted from being shown by default on the software.opensuse.org/search query tool.

...

Since everything in the build service is free software you can always check the source the packages are built from yourself if you wish, and so can anyone else, which provides as much as a safeguard as possible.

This can be doen for a few packages that you manually compile, however openSUSE relies so heavily on the buildservice for functionality that it becomes a daunting task to check all these packages yourself.

At this moment I am downloading 180+ packages from KDE:KDE4 repository. But I trust the KDE team and KDE:KDE4 packagers not to include malware in the source and in the packages. But, as I said, why should I trust the "home:darix" repository (if I don't know who darix is) or whoever's "home:whoever" repository by default? - -- Filip Brcic WWWeb: http://purl.org/NET/brcha/home/ Jabber: brcha@kdetalk.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHKS9teugpoxYs6H8RAr/oAKDtRabvZschW198f8jbWNbHXiB1xACfat/h tnsygwoRi9M4jH84Gva3feE= =FeVw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Nov 1, 2007 2:58 AM, Aniruddha wrote:

I wonder what are the security policies for openSUSE? What are the chances for malicious software (rootkits, trojans) being offered through the build service?

Log in to http://build.opensuse.org Check out the tarballs and spec files for any malware/trojans and report if you find some, once you are convinced about their goodness, only then use the repo. There is no security better than checking out the code yourself ;) Cheers -J --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, 2007-10-31 at 22:11 -0400, Patrick Shanahan wrote:

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

* Aniruddha [10-31-07 20:31]: [...]

...

For Gentoo/FreeBSD/Debian/Ubuntu/ there aren't additional repositories necessary since these distributions maintain 14000-22000 packages themselves. openSUSE on the other hand forces you to use 3r party repositories to get basic functionality working (see http://opensuse-community.org/Restricted_Formats/10.3 ).

But you are not 'forced' to use anything. Basic functionality is provided.

...

And you don't have to trust the packager, you trust the distribution and it's security policy. And don't forget packages passes many hands before ending up in the stable tree. In Debian/Ubuntu it goes from Experimental to Unstable to Testing to Stable. I can assure that when it arrives at Stable you can trust it for 100%. Gentoo/FreeBSD is the same, they have a very, very long testing period for new packages finally arrive in the stable tree.

Compare this to the openSUSE buildservice where everyone can get an account start a repo and wreck havoc because there aren't any safety precautions.

"Something" must be *terribly* wrong somewhere as no "problems" I am aware have been made public.

That is no argument. Right now apparently openSUSE has a big gaping security hole which can be exploited in the future. And who should make us aware of "problems" when none checks the repos' anyways?

I understand your concern, you have NO trust of anyone. I believe there is a word for that, but....

Trust is no replacement of good security policies.

btw, you have made *many* posts recently critical of the openSUSE distribution and the way that things are done. Is there *anything* you find *right* about openSUSE distributions? Because, if you cannot find anything *right*, one wonders why you remain!

Despite being off topic I will address your argument. I regard openSUSE as one of the finest distributions on the market. I plan on actively supporting it through my company. However before doing so I must be absolute certain of same aspects of which a regular user might care less. The fact that I ask questions or even criticize some aspect is because I love to see openSUSE evolve into something even better. That's why I offered to start a Dutch mailing list, help on the Dutch wiki and file extensive bugreports for problems I encounter. -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wednesday 31 October 2007 22:28:57 wrote Aniruddha:

I wonder what are the security policies for openSUSE? What are the chances for malicious software (rootkits, trojans) being offered through the build service?

What is the procedure for security holes and/or exploits in software offered in the openSUSE build repositories? I get the feeling openSUSE is becoming just as insecure as Windows hence the warning you get when adding repo's with 1-click install (see attachment). Or am I mistaken? Any info would be appreciated!

The 1-click install still asks for the root passwort, so it is as unsecure as installing rpms manually. It just helps the user to do it more easily. The "unsecure Windows" did not ask for extra permissions in the old days. But they improved also a bit more meanwhile. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 09:03 +0100, Adrian Schröter wrote:

...

And you don't have to trust the packager, you trust the distribution and it's security policy. And don't forget packages passes many hands before ending up in the stable tree. In Debian/Ubuntu it goes from Experimental to Unstable to Testing to Stable. I can assure that when it arrives at Stable you can trust it for 100%. Gentoo/FreeBSD is the same, they have a very, very long testing period for new packages finally arrive in the stable tree.

This not true .. You need to trust the packager is working according to the policy, you need to trust that the packager have reviewed the new source tar ball and you need to trust that the original authors have not build in hidden traps.

Good point I agree with you there. Although I consider chances that this will happen rather slim.

Putting lots of packages into one large repo does not help you, as long you do not add extra review mechanisms. Which can't be that extensive, if you increase the number of packages.

Since the are also different requeriments (you want to be more care full on your critical server than on your test systems) it is better to have multiple repositories with different requirements for the trust and let the user decide.

I am not sure I am getting your point.

...

Compare this to the openSUSE buildservice where everyone can get an account start a repo and wreck havoc because there aren't any safety precautions.

Right, but only stuff in home:* can get added by them. So you are already one step more secure when you do not use these repos.

Thank you. This is a very valuable lessen. What would be the best way to communicate this to the user? And does this mean that the non home:* are checked by openSUSE devs? Does this also include security fixes?

...

...

Since everything in the build service is free software you can always check the source the packages are built from yourself if you wish, and so can anyone else, which provides as much as a safeguard as possible.

This can be doen for a few packages that you manually compile, however openSUSE relies so heavily on the buildservice for functionality that it becomes a daunting task to check all these packages yourself.

All packages checked into the main distro get a review. This is also the reaons why it takes sometime until a new version appears there.

I think it would be best to enlarge the packages that belong in the main distro. Since openSUSE became open source this really should be possible (one team focus on packaging another one putting the packages together for a new distro).

What is indeed missing is a peer review and rating system to help the users to decide which repos to trust or not...

Does this have any chance to be implemented? I missed it on the roadmap ;)

I personally consider this approach more secure than a one large repo where everybody gets easily an account no one is really doing source reviews of new submitted tar balls. One the other hand, our modell still allows that new packagers can start immediatly and make their stuff available. It is up to the user to install it or not. (and keep in mind that downloading the source and install yourself is maybe even more unsecure, because there is not even a packager review).

You're right about that. I do think that some improvements we can greatly improve the security of the build service: -Make it more difficult to add home:* repositories -Add some kind of review and comments section to value to repositories. How should we proceed to make this happen? Thanks for addressing al my questions and for your constructive answers. - -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thursday 01 November 2007 09:33:40 wrote Aniruddha:

On Thu, 2007-11-01 at 09:03 +0100, Adrian Schröter wrote: ..

...

Putting lots of packages into one large repo does not help you, as long you do not add extra review mechanisms. Which can't be that extensive, if you increase the number of packages.

Since the are also different requeriments (you want to be more care full on your critical server than on your test systems) it is better to have multiple repositories with different requirements for the trust and let the user decide.

I am not sure I am getting your point.

I mean, each user has a different level on requirements. And he may even decides different for his different systems. This makes it hard to define one level and one single policy for us at openSUSE, since the result of the highest security requirement would be a very small distro with not really up2date software versions. There are two extrems from "highest security needed" up to to "I do not care, it is just for test or I just want the latest version". So we can not define a single policy, but we can help the users to decide themself.

...

...

Compare this to the openSUSE buildservice where everyone can get an account start a repo and wreck havoc because there aren't any safety precautions.

Right, but only stuff in home:* can get added by them. So you are already one step more secure when you do not use these repos.

Thank you. This is a very valuable lessen. What would be the best way to communicate this to the user? And does this mean that the non home:* are checked by openSUSE devs? Does this also include security fixes?

In general, each project can have its own policy. I agree the user is a bit lost atm and it is hard for him to decide how much he can trust which one. Security fixes are only done via version upgrades in the repositories atm. (unlike SLE or openSUSE distros where an extra update repo with backported fixes is available)

...

...

...

Since everything in the build service is free software you can always check the source the packages are built from yourself if you wish, and so can anyone else, which provides as much as a safeguard as possible.

This can be doen for a few packages that you manually compile, however openSUSE relies so heavily on the buildservice for functionality that it becomes a daunting task to check all these packages yourself.

All packages checked into the main distro get a review. This is also the reaons why it takes sometime until a new version appears there.

I think it would be best to enlarge the packages that belong in the main distro. Since openSUSE became open source this really should be possible (one team focus on packaging another one putting the packages together for a new distro).

This conflicts with high security requirements ... For example, SLES (or most secure product) has only ~ 50% of the packages of openSUSE. Simply because it is not doable to apply all required rulse for more packages. openSUSE distro has some lower riquerments, but still more than any build service project. So, if you can wait until a new version gets added there this is the most secure way. Unlike SLE and openSUSE, the build service repos just get a peer review only. This means, if there is something evil, either the packager needs to react after reporting (or we as admins, esp. if the packager is the evil guy).

...

What is indeed missing is a peer review and rating system to help the users to decide which repos to trust or not...

Does this have any chance to be implemented? I missed it on the roadmap ;)

It was unfortunatly not as important as other stuff listed there, so I can not promise any date right now. However, if someone is willing to work on it, we will help him of course !

...

I personally consider this approach more secure than a one large repo where everybody gets easily an account no one is really doing source reviews of new submitted tar balls. One the other hand, our modell still allows that new packagers can start immediatly and make their stuff available. It is up to the user to install it or not. (and keep in mind that downloading the source and install yourself is maybe even more unsecure, because there is not even a packager review).

You're right about that. I do think that some improvements we can greatly improve the security of the build service:

-Make it more difficult to add home:* repositories

Make something more difficult just creates new hazzle and bugreports, but does not really help the security.

-Add some kind of review and comments section to value to repositories.

How should we proceed to make this happen?

We have a minimal base for the trust handling with our new user directory. If someone wants to extend this, that users can be rated by other users and that a certain trusted group is allowed to change user trust leveling it would help a lot. We can automatically show the level of trust for a project afterwards, if we know how much we can trust the people with write access there. (additionally they should be allowed do downgrade their project as well, if they do not trust it much either, because they downloaded some untrusted source ;) So, if you would like to work on this, we are happy to help you. The source is part of the opensuse svn on forge already and we can make a (irc?) meeting where we discuss details and the design a bit more. Does anyone have interesst in this ? bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 09:50 +0100, Adrian Schröter wrote:

I mean, each user has a different level on requirements. And he may even decides different for his different systems.

This makes it hard to define one level and one single policy for us at openSUSE, since the result of the highest security requirement would be a very small distro with not really up2date software versions.

There are two extrems from "highest security needed" up to to "I do not care, it is just for test or I just want the latest version".

So we can not define a single policy, but we can help the users to decide themself.

Isn't possible to organize the buildservice around stability? That you get a warning that "you are adding repositories from an 'unstable' branch and is therefor untested?

In general, each project can have its own policy. I agree the user is a bit lost atm and it is hard for him to decide how much he can trust which one.

No problem, now I know I can coach my customers better :)

Security fixes are only done via version upgrades in the repositories atm. (unlike SLE or openSUSE distros where an extra update repo with backported fixes is available)

I think this is a great solution and the future for openSUSE (releases).

...

I think it would be best to enlarge the packages that belong in the main distro. Since openSUSE became open source this really should be possible (one team focus on packaging another one putting the packages together for a new distro).

This conflicts with high security requirements ...

For example, SLES (or most secure product) has only ~ 50% of the packages of openSUSE. Simply because it is not doable to apply all required rulse for more packages.

Off course it it is doable (see Debian/Gentoo/FreeBSD/Ubuntu) who support up to 22000 packages. the only question is how ;)

openSUSE distro has some lower riquerments, but still more than any build service project. So, if you can wait until a new version gets added there this is the most secure way.

Unlike SLE and openSUSE, the build service repos just get a peer review only. This means, if there is something evil, either the packager needs to react after reporting (or we as admins, esp. if the packager is the evil guy).

Are these procedures written down? I think this would be good way to start.

...

...

What is indeed missing is a peer review and rating system to help the users to decide which repos to trust or not...

Does this have any chance to be implemented? I missed it on the roadmap ;)

It was unfortunatly not as important as other stuff listed there, so I can not promise any date right now.

However, if someone is willing to work on it, we will help him of course !

What kind of help are you looking for?

...

How should we proceed to make this happen?

We have a minimal base for the trust handling with our new user directory. If someone wants to extend this, that users can be rated by other users and that a certain trusted group is allowed to change user trust leveling it would help a lot.

We can automatically show the level of trust for a project afterwards, if we know how much we can trust the people with write access there. (additionally they should be allowed do downgrade their project as well, if they do not trust it much either, because they downloaded some untrusted source ;)

So, if you would like to work on this, we are happy to help you. The source is part of the opensuse svn on forge already and we can make a (irc?) meeting where we discuss details and the design a bit more.

Does anyone have interesst in this ?

I certainly hope so! As I said I am not a programmer but I am willing to help i any way I can to make the openSUSE buildservice more secure. An irc meeting to discuss ideas and setup a plan would be a great start! :) -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 09:25 +0000, Benji Weber wrote:

On 01/11/2007, Aniruddha wrote:

...

Off course it it is doable (see Debian/Gentoo/FreeBSD/Ubuntu) who support up to 22000 packages. the only question is how ;)

Partly because they have a lot of people producing the packages, and if One were cynical One could suggest because they don't do so much security & quality checking compared to RH/SUSE etc whose businesses depend on it. That would be very cynical since Debian and Gentoo have very high security standards on whom large companies (e.g. hyves.nl) place their trust: http://www.linux.com/feature/118799

http://www.gentoo.org/proj/en/hardened/

You are trusting the packagers from Gentoo/Ubuntu etc because they are associated with the project, not because you know that they are in fact doing their job properly. That is the point, you choose who you wish to trust. The valid problems here are

1) There are not separate keys for each repository - this is on the roadmap to be fixed by year end. http://en.opensuse.org/Build_Service/Roadmap

2) There is no way to tie a packager's key to peer ratings/comments etc. This will be easier to implement once the user database which stores identity & other information about users & packages is ready.

We can make it easier to make an informed decision about who One wishes to trust, but the choice about who to trust still has to be up to you.

I agree 100%. These two suggestions should make it a lot easier to determine whether a repo is trustworthy.

Making home: repositories harder to add doesn't solve any problem, and anyone can make use of the one click install mechanism for repositories that arn't even in the build service.

Maybe a better warning message instead of the the current 'malicious package' package warning could improve the situation. -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Aniruddha wrote: [...]

I think it would be best to enlarge the packages that belong in the main distro. Since openSUSE became open source this really should be possible (one team focus on packaging another one putting the packages together for a new distro).

No way. Now you are digging the security hole. What you have now is a fairly secure distribution with a set of core packages. Every repository you add from the build service is up to your trust. I see that as a security policy. The big point is that I trust the core distribution. If you now add more packages to the core distribution, it will suffer in quality and security unless you increase the core team to handle the increased number of packages. Instead it would be rather good to add some review policy for the build service, independent of the core distribution. That review team would give some quality and security certificates to packages. Cheers, Guenter --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 11:50 +0100, Guenter Dannoritzer wrote:

Aniruddha wrote:

[...]

...

I think it would be best to enlarge the packages that belong in the main distro. Since openSUSE became open source this really should be possible (one team focus on packaging another one putting the packages together for a new distro).

No way. Now you are digging the security hole. What you have now is a fairly secure distribution with a set of core packages. Every repository you add from the build service is up to your trust.

Again it's impossible to tell if you can trust some *home repo. Off course I trust the build service repo's as wel packman repo's. For me this isn't a problem but for other users it might be. Let's for example take an executive that uses it's laptop to work at home, listen to mp3's and watch dvd's. His laptop contains sensitive data. To be 100% secure either: -He ends up with 'barenaked version' on which he only can work. -Adds some trusted repositories (buildservice, packman) to get additional functionality It would not be advisable for him to use openSUSE buildservice and it's 1-Click install service.

I see that as a security policy. The big point is that I trust the core distribution. If you now add more packages to the core distribution, it will suffer in quality and security unless you increase the core team to handle the increased number of packages.

Since openSUSE is opensourced that would be the way to go (attract more devs & support more packages)

Instead it would be rather good to add some review policy for the build service, independent of the core distribution. That review team would give some quality and security certificates to packages.

That would be a great step forward. -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 1 Nov 2007, Aniruddha wrote:

On Thu, 2007-11-01 at 11:33 +0100, Guenter Dannoritzer wrote:

...

...

In Gentoo/FreeBSD/Debian/Ubuntu/ you don't have to worry about that since the maintainer of that package checks this for you.

Apparently in openSuSE there is no such safety precaution.

It appears to me that you are not worried about security, but driven by affection to a certain distributions.

Off course this isn't a valid argument. Even if I am 'driven by affection to a certain distributions' this has no effect on the validity of my arguments.

No. None of the distributions you mention has a way to prevent the basic idea, that you need to trust somebody (and this multiple somebodies). Some years ago I got maintainer of the "pavuk"-package. I did major changes in the source code which resulted in a nearly 100% code reworking. Now my pavuk version is in all the major packages (Debian, BSD, SUSE, ...). If I would have included a malicious tool, the chances to detect it are very low except you are highly experienced and I'm to dumb to write such code (as I'm programming nearly 20 years now, already wrote virus checkers and analyzed virues and do networking programming for 10 years now, I doubt that). So when using pavuk, you need first to trust me. There are probably 3 to 5 people on the world, who did have a deeper look at the source code. Probably 2 of them still are active (one of them am I). Next you need to trust the package maintainers. E.g. for Debian Petr Czech is probably the only one caring for it. He has little time and for sure does not look at the code I change. Nobody else at Debian looks at the stuff I think. If he would add a security hack, the changes would be very high nobody could detect them (at least for a long time). So you need to trust him also, when you use pavuk. And when you install it, you probably do not even know, that you need to trust me, him and all the previous pavuk authors (and also the server maintainers, the build server maintainers and lots of other people). So the idea you describe will only work for commercial companies and also only for a small number of packages and also only to some extend (full code reviews are much to expensive). The way openSUSE is going now (individual keys, a network of trust, ...) is the best possible solution, as it's the only working way. Some suggestion I got when writing this. 1) Is it possible to view the packages source files from the point of non-registered users? If not, this should be possible. 2) I would like a "package is downloaded unmodified from xxx" flag for the source packages. 3) A malware code scanner could be introduced, which from time to time scans all the build-service stuff and searches code, which is know to be malware (rootkits, ...) Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 15:41 +0100, Dirk Stoecker wrote:

On Thu, 1 Nov 2007, Aniruddha wrote:

...

On Thu, 2007-11-01 at 11:33 +0100, Guenter Dannoritzer wrote:

...

...

In Gentoo/FreeBSD/Debian/Ubuntu/ you don't have to worry about that since the maintainer of that package checks this for you.

Apparently in openSuSE there is no such safety precaution.

It appears to me that you are not worried about security, but driven by affection to a certain distributions.

Off course this isn't a valid argument. Even if I am 'driven by affection to a certain distributions' this has no effect on the validity of my arguments.

No. None of the distributions you mention has a way to prevent the basic idea, that you need to trust somebody (and this multiple somebodies).

Some years ago I got maintainer of the "pavuk"-package. I did major changes in the source code which resulted in a nearly 100% code reworking. Now my pavuk version is in all the major packages (Debian, BSD, SUSE, ...). If I would have included a malicious tool, the chances to detect it are very low except you are highly experienced and I'm to dumb to write such code (as I'm programming nearly 20 years now, already wrote virus checkers and analyzed virues and do networking programming for 10 years now, I doubt that).

So when using pavuk, you need first to trust me. There are probably 3 to 5 people on the world, who did have a deeper look at the source code. Probably 2 of them still are active (one of them am I).

Next you need to trust the package maintainers. E.g. for Debian Petr Czech is probably the only one caring for it. He has little time and for sure does not look at the code I change. Nobody else at Debian looks at the stuff I think. If he would add a security hack, the changes would be very high nobody could detect them (at least for a long time). So you need to trust him also, when you use pavuk.

And when you install it, you probably do not even know, that you need to trust me, him and all the previous pavuk authors (and also the server maintainers, the build server maintainers and lots of other people).

So the idea you describe will only work for commercial companies and also only for a small number of packages and also only to some extend (full code reviews are much to expensive).

The way openSUSE is going now (individual keys, a network of trust, ...) is the best possible solution, as it's the only working way.

Thanks for replying, you brought some interesting points from an inside perspective :). As stated in my precious mail I think the biggest problems is with the home:* repo's. How can we ensure security for these?

Some suggestion I got when writing this.

3) A malware code scanner could be introduced, which from time to time scans all the build-service stuff and searches code, which is know to be malware (rootkits, ...)

This would be great. I already contacted several vendors to ask if they provide malware protection (specifically rootkits). OSS Clamav only viruses Commercial - gratis f-prot ( http://www.f-prot.com/products/home_use/linux/ ) Might work against rootkits. I'll contact them. Commercial Kasperksy ( http://www.kaspersky.com/anti-virus_linux_workstation#av ) Contacted them several weeks ago still no response -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Aniruddha [11-01-07 11:07]: [...]

This would be great. I already contacted several vendors to ask if they provide malware protection (specifically rootkits). [...]

rkhunter, free 1:09 wahoo:~ > webpin -d 10.3 rkhunter Query URL: http://benjiweber.co.uk:8080/searchservice/SearchService/Search/Simple/openS... * rkhunter: Rootkit Hunter Scans for Rootkits, Backdoors, and Local Exploits - 1.2.8 [suse-oss] {noarch} @ http://download.opensuse.org/distribution/10.3/repo/oss/suse >> /etc/cron.daily/suse.de-rkhunter - 1.2.9 [BS::home:/lemmy04 | BS::home:/lrupp] {noarch} @ http://download.opensuse.org/repositories/home:/lemmy04/openSUSE_10.3 @ http://download.opensuse.org/repositories/home:/lrupp/openSUSE_10.3 >> /etc/cron.daily/suse.de-rkhunter .... It's on your install dvd - -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHKezTClSjbQz1U5oRAvJOAKCAV+Q1jp3LzcRZoEL1xOITrFJ5OgCdFGib 63fzstK550G/0MQBrL2dfBM= =cAEC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 16:21 +0100, Aniruddha wrote:

On Thu, 2007-11-01 at 11:12 -0400, Patrick Shanahan wrote:

...

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

* Aniruddha [11-01-07 11:07]: [...]

...

This would be great. I already contacted several vendors to ask if they provide malware protection (specifically rootkits). [...]

rkhunter, free

I know ;), rkhunter, aide I have them already installed. But If I am not mistaken these are meant for scanning workstations not repositories.

And there is Osiris: http://osiris.shmoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Aniruddha wrote:

And there is Osiris: http://osiris.shmoo.com/

But there are no packages for Osiris in BuildService. Should I package it to my home project? Just kidding :) -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 2007-11-01 at 16:34 +0100, Pavol Rusnak wrote:

Aniruddha wrote:

...

And there is Osiris: http://osiris.shmoo.com/

But there are no packages for Osiris in BuildService. Should I package it to my home project? Just kidding :)

Lol :D. I am compiling osiris right now. -- Regards, Aniruddha Please adhere to the OpenSUSE_mailing_list_netiquette http://en.opensuse.org/OpenSUSE_mailing_list_netiquette --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 1 Nov 2007, Aniruddha wrote:

On Thu, 2007-11-01 at 09:50 +0100, Adrian Schröter wrote:

...

I mean, each user has a different level on requirements. And he may even decides different for his different systems.

This makes it hard to define one level and one single policy for us at openSUSE, since the result of the highest security requirement would be a very small distro with not really up2date software versions.

There are two extrems from "highest security needed" up to to "I do not care, it is just for test or I just want the latest version".

So we can not define a single policy, but we can help the users to decide

...

Off course it it is doable (see Debian/Gentoo/FreeBSD/Ubuntu) who support up to 22000 packages. the only question is how ;)

Every Distribution/Unix/Linux variant has constraints. I have seen exploits in all of them. Someone has to do the programming and checking. There are not enought paid people on any of the Distribution or OS's to really bring security to a C2 level(US). Novell/SUSE has done a lot in getting security to a great level. Many of the packages in the 22000 have not had a security audit. You still have to trust. I have worked with the Devs on all the BSD variants. Just because they are in the distribution does not make them more secure. I know. I have placed reports and the authors have acknowlegded that no security audit has been preformed. So please do not make general noise about how great the security is. It is not there. -- Boyd Gerber ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Aniruddha wrote: [...]

Again it's not about me, I'll manage and I am not afraid to b0rk my system. It's about unsuspecting users that add those repositories with '1-Click'.

When you are so worried about them, why don't you do anything about it? At the end, that is how Linux got there where it is, by people not talking, but doing things. Cheers, Guenter --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 1 Nov 2007, Aniruddha wrote:

On Thu, 2007-11-01 at 10:36 -0600, Boyd Lynn Gerber wrote:

...

...

Off course it it is doable (see Debian/Gentoo/FreeBSD/Ubuntu) who support up to 22000 packages. the only question is how ;)

Every Distribution/Unix/Linux variant has constraints. I have seen exploits in all of them. Someone has to do the programming and checking. There are not enought paid people on any of the Distribution or OS's to really bring security to a C2 level(US). Novell/SUSE has done a lot in getting security to a great level. Many of the packages in the 22000 have not had a security audit. You still have to trust. I have worked with the Devs on all the BSD variants. Just because they are in the distribution does not make them more secure. I know. I have placed reports and the authors have acknowlegded that no security audit has been preformed. So please do not make general noise about how great the security is. It is not there.

Interesting view from the inside :). I can imagine that devs don't have time for a full fledged security audit (reviewing all code manually). And I don't think this is necessary, correct me if I am wrong. Are your only experienced with 'BSD or also with Gentoo/Debian?

All the various *BSD's and Debian, a little Gentoo, but mainly SUSE. A audit is necessary for C2. It even requires the HW to be auditted. The cert is for exactly the system. -- Boyd Gerber ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, 1 Nov 2007, Aniruddha wrote:

On Thu, 2007-11-01 at 12:15 -0600, Boyd Lynn Gerber wrote:

...

...

Interesting view from the inside :). I can imagine that devs don't have time for a full fledged security audit (reviewing all code manually). And I don't think this is necessary, correct me if I am wrong. Are your only experienced with 'BSD or also with Gentoo/Debian?

All the various *BSD's and Debian, a little Gentoo, but mainly SUSE. A audit is necessary for C2. It even requires the HW to be auditted. The cert is for exactly the system.

You mean 'Trusted Computer System Evaluation Criteria' ( http://en.wikipedia.org/wiki/TCSEC )? I didn't know that one. Is actually used outside the army?

Yes, it is. I am not able to go into any detail. But C2 is needed for some things I support. -- Boyd Gerber ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Aniruddha wrote: [...]

For the last time I will address your off topic remark. As you might know the first phase in problem solving is to identify the problem. That is what we are "doing" right now. And I offered to help materialize these solutions.

Aniruddha, I apologize, and I mean that sincere. I got offended by your claim that packager for other distributions take more security considerations than is done for the openSUSE packages. That should not let me defer you from your effort to improve security around the build service. I am looking forward seeing this effort develop. Cheers, Guenter --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Friday 02 November 2007 12:32:03 pm Aniruddha wrote:

I think we should first focus on making the home:* repositories more secure. What would best way to push this forward?

Initial phase: Scanning binaries for known problems using some antivirus/rootkit software, before actually publishing, even in home:* repositories. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Saturday 03 November 2007 01:40:54 wrote Rajko M.:

On Friday 02 November 2007 12:32:03 pm Aniruddha wrote:

...

I think we should first focus on making the home:* repositories more secure. What would best way to push this forward?

Initial phase: Scanning binaries for known problems using some antivirus/rootkit software, before actually publishing, even in home:* repositories.

I personally do not like this idea much, because it can cause the risk that people believe that software is "good" if the scanner does not find anything inside. However, any scanner what helps manually reviewing is of course very helpfull. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Sunday 04 November 2007 04:37:10 am Adrian Schröter wrote:

On Saturday 03 November 2007 01:40:54 wrote Rajko M.:

...

On Friday 02 November 2007 12:32:03 pm Aniruddha wrote:

...

I think we should first focus on making the home:* repositories more secure. What would best way to push this forward?

Initial phase: Scanning binaries for known problems using some antivirus/rootkit software, before actually publishing, even in home:* repositories.

I personally do not like this idea much, because it can cause the risk that people believe that software is "good" if the scanner does not find anything inside.

However, any scanner what helps manually reviewing is of course very helpfull.

The scanner solution will remove some number of possible attacks. Though, they will not help for mentioned in this mail: http://lists.opensuse.org/opensuse/2007-11/msg00422.html This is out of scope of scanners, but number of people able to create it is smaller than for known attacks. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Sunday 04 November 2007 02:32:03 pm Dirk Stoecker wrote:

On Sun, 4 Nov 2007, Rajko M. wrote:

...

...

...

Scanning binaries for known problems using some antivirus/rootkit software, before actually publishing, even in home:* repositories.

I personally do not like this idea much, because it can cause the risk that people believe that software is "good" if the scanner does not find anything inside.

However, any scanner what helps manually reviewing is of course very helpfull.

The scanner solution will remove some number of possible attacks. Though, they will not help for mentioned in this mail: http://lists.opensuse.org/opensuse/2007-11/msg00422.html This is out of scope of scanners, but number of people able to create it is smaller than for known attacks.

Such a scanning system from my point of view is no public interface. This should run in background by server administrators (either scanning binaries or sources).

The build service users should only get to know it, when he tries nasty things and an administrator is contacting him to tell him, that he has been discovered (or else circumvention is no problem).

So it gets an aditional security improvement without negative side effects. Like in "We trust you, but a bit control can't be wrong :-)".

Good point of view. Now is the question how to discuss security issues? Discussing security elements in public, helps normal users to feel better, but gives information malicious users where to look for cracks in the wall. How to tell normal users with good questions about security: "We have some measures in place and Build Service is not a jungle where any predator can jump in and wreck havoc, but also it is not save haven, where you can forget to keep an eye on security." -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org