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!
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 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?
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?
On 31/10/2007, Aniruddha mailing_list@orange.nl 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
Aniruddha wrote: [...]
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?
You are getting a wrong perspective here. Any software can contain malicious parts. The build service just provides a platform to create RPM packages from open source code.
Would you trust a software, that you compile yourself from source on your computer, more than a RPM package of that software that you got from the build service? How would you tell that the source does not contain malicious parts?
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 00:39 +0100, Guenter Dannoritzer wrote:
You are getting a wrong perspective here. Any software can contain malicious parts. The build service just provides a platform to create RPM packages from open source code.
Would you trust a software, that you compile yourself from source on your computer, more than a RPM package of that software that you got from the build service? How would you tell that the source does not contain malicious parts?
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.
On 31/10/2007, Aniruddha mailing_list@orange.nl 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
On Wed, 2007-10-31 at 23:57 +0000, Benji Weber wrote:
On 31/10/2007, Aniruddha mailing_list@orange.nl 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.
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 ).
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.
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.
-----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 brcha@gna.org WWWeb: http://purl.org/NET/brcha/home/ Jabber: brcha@kdetalk.net
--------------------------------------------------------------------- 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 02:44 +0100, Filip Brcic wrote:
-----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.
Great to see someone who understands my point of view.
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?
I agree completely. For example I do trust the packman repository, but indeed there are so many unknown anonymous packagers from it's difficult to determine if they are genuine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
* Aniruddha mailing_list@orange.nl [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.
I understand your concern, you have NO trust of anyone. I believe there is a word for that, but....
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!
- -- 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
--------------------------------------------------------------------- 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 mailing_list@orange.nl [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.
On Thursday 01 November 2007 09:01:27 wrote Aniruddha: ...
"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?
Not more or less than installing the software from somewhere else ...
But I agree that this could be way more transparent, we did plan to create a "trust" portal from the beginning, it is just work to do so.
As long as we want to have lots of software and always the latest version, the user needs to decide if he trust it. But we can help him here.
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.
Well, a policy helps you nothing, if you do not trust the people. They can ignore it easily.
bye adrian
On Thu, 2007-11-01 at 09:09 +0100, Adrian Schröter wrote:
On Thursday 01 November 2007 09:01:27 wrote Aniruddha: ...
"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?
Not more or less than installing the software from somewhere else ...
But I agree that this could be way more transparent, we did plan to create a "trust" portal from the beginning, it is just work to do so.
As long as we want to have lots of software and always the latest version, the user needs to decide if he trust it. But we can help him here.
Agreed, maybe it is a good idea to enhance the roadmap with planned security features. If I can help in any way (I am not a programmer) just let me know. I would love to help think about the security features enhancements for the openSUSE buildservice.
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.
Well, a policy helps you nothing, if you do not trust the people. They can ignore it easily.
Off course, however a system that moves a package form experimental to unstable etc. can be considered safer then a system that offers packages from one repository with 1-Click without such checks. That's what I meant with 'policy'.
On Thursday 01 November 2007 01:16:34 wrote Aniruddha:
On Wed, 2007-10-31 at 23:57 +0000, Benji Weber wrote:
On 31/10/2007, Aniruddha mailing_list@orange.nl 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.
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 ).
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.
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.
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.
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.
What is indeed missing is a peer review and rating system to help the users to decide which repos to trust or not...
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).
bye adrian
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.
-
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
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! :)
On 01/11/2007, Aniruddha mailing_list@orange.nl 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.
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.
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.
-- Benjamin Weber --------------------------------------------------------------------- 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 mailing_list@orange.nl 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
- 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
- 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.
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 gerberb@zenez.com 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, 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.
-- Boyd Gerber gerberb@zenez.com 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
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?
And again I don't have problems trusting repo's like openSUSE and packman etc. It's impossible to tell if you can trust some *home repo which concerns me.
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 gerberb@zenez.com 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, 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?
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 gerberb@zenez.com 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, 2007-11-01 at 14:14 -0600, Boyd Lynn Gerber wrote:
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.
--
Do you happen to know were I can find more information about the C2 security level? Maybe I can put some thing to practise in the Netherlands :)
On Thursday 01 November 2007 10:11:13 wrote Aniruddha:
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?
Hm, stability is a different topic IMHO. Because also very well trusted packagers might package something unstable, just for testing.
We need a field to be specified by the package / project owner in which state he considers his package ( something like: Alpha, Beta or Stable state )
...
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 ;)
I seriously doubt that they do this at this level as we do. And they do not have to, since there are no contracts with customers specifing this. Neither no EAL certification needs to get fullfilled.
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.
Yes, but only Novell internally atm. We can not open up these documents atm, because they specify quite a lot internal stuff, but the good thing is that with accepting source contributions via the build service early next year, this is not need anymore :)
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?
I think we look for people knowing or willing to learn ruby/rails and improving the users.o.o (and later api.o.o and build.o.o) service for allowing rating of of people.
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! :)
anyone else interessted ?
Otherwise we can discuss this personal on IRC or via mail. But you would need to become a programmer for this ;)
bye adrian
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.
Aniruddha wrote:
On Thu, 2007-11-01 at 00:39 +0100, Guenter Dannoritzer wrote:
[...]
Would you trust a software, that you compile yourself from source on your computer, more than a RPM package of that software that you got from the build service? How would you tell that the source does not contain malicious parts?
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.
I could argue that I do not trust any of the distributions you just named, because non of their developers is accountable to any organization. In contrast the core developer of openSUSE are employees and accountable to their company.
If you are really concerned about security you have to go the whole way. The first step is to make sure the source is clean. Then check that the build was done with that clean source and not manipulated. Finally that the package you are installing is really the one that got build with the build service.
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:33 +0100, Guenter Dannoritzer wrote:
Aniruddha wrote:
On Thu, 2007-11-01 at 00:39 +0100, Guenter Dannoritzer wrote:
[...]
Would you trust a software, that you compile yourself from source on your computer, more than a RPM package of that software that you got from the build service? How would you tell that the source does not contain malicious parts?
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.
Nonetheless I will address your argument. I do think that Debian (Etch) is completely unusable because of it's inconsistent and buggy nature. I think that FreeBSD is great for servers but unusable for desktop (try upgrading xorg and your in for a days work. Gentoo is fine but only useful for absolute beginners (who don't want to install software themselves) or for expert users.
I could argue that I do not trust any of the distributions you just named, because non of their developers is accountable to any organization. In contrast the core developer of openSUSE are employees and accountable to their company.
If you are really concerned about security you have to go the whole way. The first step is to make sure the source is clean. Then check that the build was done with that clean source and not manipulated. Finally that the package you are installing is really the one that got build with the build service.
That's what the package maintainers do.
Aniruddha wrote:
On Thu, 2007-11-01 at 11:33 +0100, Guenter Dannoritzer wrote:
[...]
If you are really concerned about security you have to go the whole way. The first step is to make sure the source is clean. Then check that the build was done with that clean source and not manipulated. Finally that the package you are installing is really the one that got build with the build service.
That's what the package maintainers do.
First, what makes you trust a package maintainer from any other distribution more than a package maintainer from openSUSE? Unless you know a person personally I don't see any difference.
Second, I am questioning whether there is any package maintainer that checks a software for malicious parts. There are people that check for security breaches in software, but they are not necessarily package maintainer. I would assume that the major time a package maintainer spends in getting the software to build and fit into the distribution.
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 15:29 +0100, Guenter Dannoritzer wrote:
Aniruddha wrote:
On Thu, 2007-11-01 at 11:33 +0100, Guenter Dannoritzer wrote:
[...]
If you are really concerned about security you have to go the whole way. The first step is to make sure the source is clean. Then check that the build was done with that clean source and not manipulated. Finally that the package you are installing is really the one that got build with the build service.
That's what the package maintainers do.
First, what makes you trust a package maintainer from any other distribution more than a package maintainer from openSUSE? Unless you know a person personally I don't see any difference.
Like I said; I trust the openSUSE package maintainers. I also trust packman, vlc, Nvidia & ATI repo's. However I have trouble determining whether I can trust certain (most notably the home:*) repositories. And again this isn't a problem for me, but it can be for the unsuspecting users that add repositories with '1-Clik'.
Right now I have the home:darix and the home:wberrier repos installed (I thought because I wanted kiso). How can I determine if these are safe repo's (not only in regard to malware but also in regard to breaking my system, overwriting config files etc)?
And what about the Games repo's? Who maintains these?
Second, I am questioning whether there is any package maintainer that checks a software for malicious parts. There are people that check for security breaches in software, but they are not necessarily package maintainer. I would assume that the major time a package maintainer spends in getting the software to build and fit into the distribution.
Like I said, even if this isn't the case the whole structure in which a package moves from stable to unstable should provide enough security.
Aniruddha wrote: [...]
Like I said; I trust the openSUSE package maintainers. I also trust packman, vlc, Nvidia & ATI repo's. However I have trouble determining whether I can trust certain (most notably the home:*) repositories. And again this isn't a problem for me, but it can be for the unsuspecting users that add repositories with '1-Clik'.
Right now I have the home:darix and the home:wberrier repos installed (I thought because I wanted kiso). How can I determine if these are safe repo's (not only in regard to malware but also in regard to breaking my system, overwriting config files etc)?
At the end you always can go and ask the maintainers. Get a feeling how long they have been doing the job. What guidelines are they following to build the package. How do they make sure what they provide does not break your system.
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 16:30 +0100, Guenter Dannoritzer wrote:
Aniruddha wrote: [...]
Like I said; I trust the openSUSE package maintainers. I also trust packman, vlc, Nvidia & ATI repo's. However I have trouble determining whether I can trust certain (most notably the home:*) repositories. And again this isn't a problem for me, but it can be for the unsuspecting users that add repositories with '1-Clik'.
Right now I have the home:darix and the home:wberrier repos installed (I thought because I wanted kiso). How can I determine if these are safe repo's (not only in regard to malware but also in regard to breaking my system, overwriting config files etc)?
At the end you always can go and ask the maintainers. Get a feeling how long they have been doing the job. What guidelines are they following to build the package. How do they make sure what they provide does not break your system.
Cheers,
Guenter
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'.
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, 2007-11-01 at 18:52 +0100, Guenter Dannoritzer wrote:
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
Sigh, I am getting tired of addressing your ignorant remarks. Please refrain from replying if don't have anything on topic to contribute.
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.
Furthermore I have been "doing" supporting Dutch openSUSE users though mailing list and wiki as well promoting and supporting (openSUSE) Linux through my company. I have also been participating in the organization of the recent Linux freedom day in the Netherlands. That's what I have been "doing" Guenter.
--------------------------------------------------------------------- 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 Fri, 2007-11-02 at 14:53 +0100, Guenter Dannoritzer wrote:
Aniruddha, I apologize, and I mean that sincere.
Guenter, thank you for your apologies and honesty. I really appreciate it.
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.
Me too. I think we should first focus on making the home:* repositories more secure. What would best way to push this forward?
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.
On Fri, 2007-11-02 at 19:40 -0500, Rajko M. wrote:
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.
:) That is a good solution. Which scanner could we use best to scan the repositories? (still haven't heard anything from f-prot or kaspersky :S).
Could someone who is involved with the openSUSE build service comment on this proposal?
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
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.
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 :-)".
Ciao
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."
Adrian Schröter escribió:
I personally do not like this idea much,
Me neither.
because it can cause the risk that
people believe that software is "good" if the scanner does not find anything inside.
and that's a mayor issue.. false sense of security is worst than no security at all.
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
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.
- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
* Aniruddha mailing_list@orange.nl [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
--------------------------------------------------------------------- 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:12 -0400, Patrick Shanahan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- Aniruddha mailing_list@orange.nl [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.
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 mailing_list@orange.nl [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 :)
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.
On Thu, 2007-11-01 at 16:37 +0100, Aniruddha wrote:
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.
And as a safety precaution I never compile as root and never do a 'make install' but add the binaries manually to a path in my home folder :p
Dirk Stoecker wrote: [...]
Some suggestion I got when writing this.
- Is it possible to view the packages source files from the point of non-registered users? If not, this should be possible.
Actually, how about the packager can provide a link to the original md5 checksum and if the source code used to build that package passes the md5 checksum there is some confidence LED showing up next to the 1-Click-Install button of that package.
Now that leaves the problem with applied patches and I don't know how extensive they are getting. But how about having the possibility to view the applied patches.
It would also be good to have the packager add a comment about why this patch is applied and where it comes from. That comment could also be shown to the end user.
Those measures would allow a user of a packager to trace back what got changed from the original source code.
Cheers,
Guenter
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed, Oct 31, 2007 at 11:49:22PM +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.
Adrian has wrote some points already, but we will be changing the way we sign stuff to have per-buildservice-project keys.
This will make this a per-project trust relation and not just a "trust buildservice or not" relation ship.
And as I said, as long as you use the basesystem with its just 3000+ packages available and do not add additional stuff, you have the assurance that it was done by SUSE developers ;)
Are there any future plans to set up an security infrastructure with common rules for ensuring security?
Yes.
Ciao, Marcus --------------------------------------------------------------------- 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 mailing_list@orange.nl 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 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.
buildservice@lists.opensuse.org
-
Adrian Schröter -
Aniruddha -
Benji Weber -
Boyd Lynn Gerber -
Cristian Rodríguez -
CyberOrg -
Dirk Stoecker -
Filip Brcic -
Guenter Dannoritzer -
Marcus Meissner -
Patrick Shanahan -
Pavol Rusnak -
Rajko M.