Re: COPR
On 09/02/2013 04:29 AM, Miroslav Suchý wrote: On 08/30/2013 10:01 PM, Jay Greguske wrote: I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion. Koji builder has somewhere stored certificate. This certificate authorize him to Koji hub. Whoever has this certificate can act as Koji builder. Koji builder builds using mock, which means in chroot. There are known some exploits, which allows you to run out of chroots. Now imagine evil package, which will run out chroot, read that certificate and deliver it to attacker. He now can build evil builder and start building modified packages. While there are known exploits to affect host machine of VM, it is definitely harder than running out of chroot. If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue. - Jay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: COPR
On 09/03/2013 12:29 PM, Michael scherer wrote: On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote: On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgreg...@redhat.com wrote: If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue. In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode). With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs. Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm. the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look. Please post it. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: COPR
On 09/03/2013 11:48 AM, Peter Robinson wrote: On Tue, Sep 3, 2013 at 3:10 PM, Jay Greguske jgreg...@redhat.com mailto:jgreg...@redhat.com wrote: On 09/02/2013 04:29 AM, Miroslav Suchý wrote: On 08/30/2013 10:01 PM, Jay Greguske wrote: I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion. Koji builder has somewhere stored certificate. This certificate authorize him to Koji hub. Whoever has this certificate can act as Koji builder. Koji builder builds using mock, which means in chroot. There are known some exploits, which allows you to run out of chroots. Now imagine evil package, which will run out chroot, read that certificate and deliver it to attacker. He now can build evil builder and start building modified packages. While there are known exploits to affect host machine of VM, it is definitely harder than running out of chroot. If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue. koji already uses VMs for x86. Peter Not for RPM builds. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: COPR
On 08/30/2013 05:39 AM, Miroslav Suchý wrote: Hi, I would like to get your feedback about COPR [1] [1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_koji/index.html http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs/index.html I would like to ask *you* what is your opinion? Hi Miroslav, I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion. - Jay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Builder update
On 08/29/2013 01:10 PM, Kevin Fenzi wrote: On Thu, 29 Aug 2013 09:05:24 +0300 Panu Matilainen pmati...@laiskiainen.org wrote: ...snip... Let me say AWESOME one more time :) :) I actually didn't know that this was so much of a bottleneck for you folks. ;( Anyhow, glad we can move forward and hopefully get things rolling faster. Of course it does mean we could run into breakage if there's breakage in Fedora land, but thats good to know and fix too. Yes, dogfooding on the builders can IMO only be a good thing for overall stability of Fedora, even if it might initially cause some extra hickups. Breaking the builders a couple of times and getting scolded for that ought to make people think a bit more about pushing potentially destabilizing updates :) Exactly. kevin I'm not saying this was a bad idea, but the Koji developers now have to test on both RHEL 6 and Fedora now. Let this message serve as a warning to them if they did not already know. ;) - Jay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Builder update
On 08/28/2013 10:42 AM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I wanted to let everyone know that as of last night all of the buildvm builders were moved from RHEL 6 to Fedora 19. We do still have some rhel6 builders. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIeDGQACgkQkSxm47BaWfdgqQCfek4ZWmq5pd2UNc26LlQwhIi3 kZUAnRvGevZKjj1KBEnWU2UejqcXmhGw =Ytlw -END PGP SIGNATURE- Are the buildvm builders the bare-metal image builders? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libcdio update coming to rawhide
On 11/15/2011 03:52 AM, Adrian Reber wrote: I will soon update libcdio to 0.83 in rawhide which requires a rebuild of following the packages: audacious-plugins cdw gvfs kover libcddb oxine pragha pycdio qmmp xmms2 I will rebuild these packages if the corresponding maintainers do not object. Adrian I own pycdio; build away! :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libcdio update
- Adrian Reber adr...@lisas.de wrote: On Tue, Jan 19, 2010 at 11:31:50AM +0100, Michael Schwendt wrote: On Tue, 19 Jan 2010 09:43:49 +0100, Adrian wrote: I would like to update libcdio to the latest version (0.82). This requires a rebuild of its dependencies: audacious-plugins gvfs kover libcddb oxine pycdio qmmp xfce4-cddrive-plugin xmms2 If the maintainers of the above packages do not object I would do all the necessary rebuilds. Only in Rawhide I assume. No objections wrt audacious-plugins (with the caveat that I don't know about the changes in libcdio 0.82 yet). Sure. Only rawhide. Forgot to mention that. F-12 would be a different case. No intention at all. Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I maintain pycdio; no objections here. - Jay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
