infrastructure October 2011

infrastructure@lists.fedoraproject.org

36 participants
39 discussions

[freeze break][pre-approved][bodhi] Get TurboMail 3.0 working on releng04
by Luke Macken 25 Oct '11

25 Oct '11

I just applied the following patch to get bodhi working on releng4 with the latest TurboMail API. ================================================================================ IRC Approval: 18:35 abadger199>lmacken: I +1, get nirik to say the same and you can send it to the list with "approved on IRC" just so we keep everyone in the loop. 18:36 < nirik> | yeah, +1 here. ================================================================================ commit 0fbcc438712e788d575250379a5cdc28246649a1 Author: Luke Macken <lmacken(a)redhat.com> Date: Tue Oct 25 18:35:29 2011 +0000 [bodhi] Get TurboMail 3.x working on releng4 by using the smtp transport diff --git a/modules/bodhi/templates/bodhi-masher-jobrunner.cfg.erb b/modules/bo index 55dbf2c..813f46f 100644 --- a/modules/bodhi/templates/bodhi-masher-jobrunner.cfg.erb +++ b/modules/bodhi/templates/bodhi-masher-jobrunner.cfg.erb @@ -46,8 +46,12 @@ visit.cookie.secure = True bodhi_password='<%= bodhiBugzillaPassword %>' bodhi_email = 'updates(a)fedoraproject.org' +# TurboMail 3.0 settings mail.on = True -mail.server = 'bastion' +mail.transport = 'smtp' +mail.smtp.server = 'bastion' +mail.message.encoding = 'utf-8-qp' + notice_sender = 'updates(a)fedoraproject.org' security_team = 'security_respons-members(a)fedoraproject.org' release_team_address = 'bodhiadmin-members(a)fedoraproject.org'

1 0

infrastructure meeting notes - 2011-10-20
by Seth Vidal 20 Oct '11

20 Oct '11

Summary: - dgilmore does not have enough time. - told to suck it up and get over it - lmacken putting out a new release of bodhi before the freeze - toshio is hotfixing fas very soon before the freeze - pingou was concerned about a patch for the planet css he sent that was ignored - patch was evaluated and he was told to commit it after talking with the websites people to make sure stuff wasn't obviously wrong with it. - toshio will file an easyfix ticket for adding dns aliases for our db servers - so instead of remembering that fas is on db## and wiki is on db05 we can just remember: db-fas and db-wiki and db-smolt and db-ask and what not. Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2011-10-20/infrastructure.2… Log: http://meetbot.fedoraproject.org/fedora-meeting/2011-10-20/infrastructure.2… Thanks to everyone for showing up. -sv

1 0

ssh private keys on our systems
by Seth Vidal 20 Oct '11

20 Oct '11

Hi, I'd like to put a new policy in place which goes something like this: If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS. We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it. thoughts? Thanks, -sv

13 20

Re: 2factor auth
by Dennis Gilmore 20 Oct '11

20 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inicio del mensaje redirigido: Fecha: Wed, 19 Oct 2011 18:20:09 -0500 Desde: Dennis Gilmore <dennis(a)ausil.us> Para: infrastructure(a)lists.fedoraproject.org Asunto: Re: 2factor auth El Mon, 17 Oct 2011 17:11:49 -0400 seth vidal <skvidal(a)fedoraproject.org> escribió: > > > One final thing: Ricky Zhou mentioned this group: duosecurity.com. > They have a neat system and set of apps for smart phones/devices which > circumvent the problems with otp secrets being exposed. But it > requires that the device you have is connected to the internet in > some way - which is tricky, to say the least. Implementing something > like their system should be possible - but we're going to need > someone who is an android and/or ios app developer to help. > > > So - my questions are: > 1. Is requiring an android/ios device too onerous? yes, im moving to meego at the moment. though ill likely have a android device still. my ultimate goal is to have fedora in my pocket, but thats for another place. > 2. Does the 'here's how it should work' section above make sense/seem > secure to everyone? > 3. who should we be requiring to use this? sysadmin-main? sysadmin-*, > anyone with a shell account? Would it make sense to make ssh keys + > OTP auth to get onto fedorapeople.org at all? what about fedorahosted? i think anyone who has sudo on a box. maybe excepting those who only have it on publictest boxes. I happen to use my yubikey daily. its definetly my prefered method. Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEUEARECAAYFAk6fYfAACgkQkSxm47BaWffTJgCfYxzgVPvap91oyDtoj3zx4cLN +1cAmMdtx0Sr0EAMg50zSYCBshNyyFU= =Wn1B -----END PGP SIGNATURE-----

1 0

Packages installed on app servers but not in puppet
by Stephen John Smoogen 19 Oct '11

19 Oct '11

So when I reinstalled app04 I found that its packages differed from all the app servers by quite a bit. I hand installed the django packages but then saw that not all the same packages are on the app servers.. app01, app02, app03 PyYAML bzr bzrtools git libprelude-python libpreludedb-python mercurial perl-Git php-bcmath pysvn python-demjson python-lxml python-markdown2 python-openid python-pydns python-twisted python-twisted-conch python-twisted-lore python-twisted-mail python-twisted-names python-twisted-news python-twisted-runner python-twisted-words subversion app07 had some of these but not the twisted.. there are also a lot of gnome packages on the app servers which iam not sure were needed. -- Stephen J Smoogen. "The core skill of innovators is error recovery, not failure avoidance." Randy Nelson, President of Pixar University. "Let us be kind, one to another, for most of us are fighting a hard battle." -- Ian MacLaren

3 4

Plan for tomorrow's Fedora Infrastructure meeting (2011-10-20)
by Kevin Fenzi 19 Oct '11

19 Oct '11

The infrastructure team will be having it's weekly meeting tomorrow 2011-10-20 at 1900 UTC in #fedora-meeting on the freenode network. NOTE that I will be out tomorrow/friday, hopefully someone else can run the meeting in my absense. ;) Suggested topics (suggested by whom): * New folks introductions and Apprentice tasks. * Upcoming Tasks/Items 2011-10-20 - 2011-10-21 - kevin out on PTO. 2011-10-24 - send out nag about pass/keys change 2011-10-25 - 2011-11-08: Final change freeze 2011-11-01 mail fi-apprentice folks. 2011-11-08: Fedora 16 release. * Meeting tagged tickets: https://fedorahosted.org/fedora-infrastructure/report/10 Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 0

2factor auth
by Seth Vidal 19 Oct '11

19 Oct '11

Hi all, I've been reading and noodling around with some of the 2factor auth (2fa) mechanisms available - trying to figure out which ones fit for our users, our use case, and our mandate (open source ftw). OTP (TOTP or HOTP) appears to be the most common type. TOTP is what google authenticate uses and is more or less what the rsa securids, etc use. The biggest problem with OTP is that it's a symmetric key that both ends have to know (in the clear) to generate or validate the password. This means that if your server side gets compromised then everyone's keys are immediately invalidated. The second problem is that you need some sort of device that can run either an ios or an android app to generate the passwords from the secrets. ( Curiously enough you don't really need that - you can use the secret on your computer to make the passwords too using some really simple code - especially the TOTP ones. However, at that point it is not 'something you know and something you have (on another device that is not connected to your computer) it is something you know and a piece of software you run on your computer which, obviously, anyone who cracks your computer can then use to login as you - but I digress) Yubikeys - which we are already using - not fabulously, is a combination of an assortment of those. The biggest problems with the yubikeys is: 1. getting them into people's hands 2. getting another one into their hands when they lose or break the last one. 3. the company who makes them being relatively small and afaict the only company who makes them. 4. kinda fiddly. Now - we could just use the tools that google offers - which are open source - at: http://code.google.com/p/google-authenticator/ but the problem there is that it requires storing all of the secrets on any/every machine you would need to login to. Since the secrets in OTP are clear and vulnerable it makes that an unacceptably high risk, imo, to put them on all of our machines. So I started hunting around and I think I have some of a solution to this part of the problem: Here's how it should work: - you go to login - you're prompted to supply your normal/regular password + your one-time-password(otp) (all on one line - which means not having to hope that the apps can cope with this) - you go to your phone or other ios/android device. Open the app that gives you your otp and input that with your password. - the login is passed to a pam module which relays this auth-attempt to a cgi housed on our fas servers (or potentially in multiple locations for network-dispersal) (the cgi runs over https, obviously - maybe authenticated with client-side ssl cert?) - the cgi checks the otp and replies 'yay, nay, or broken'. - you are logged in or reprompted or whatever.; linotp implements most of this -but they've added a lot of bits to it that we probably don't need and their pam module looks to be about 90%+ of what we do need. So that might be where we go from here. Now - how do we get people their otp secrets, etc: That depends on who 'people' is - if people is really only people who can sudo places then, imo, we do them all by hand - generating them (or regenerating them) as we go. This is mainly b/c setting up too much infrastructure to support this is just a fools errand if we're only talking about 50-100 people to deal with and having a human in there tends to make it harder to spoof. If 'people' is everyone who can commit to fedora then we've got to figure out how to do it nicely: one option could be something like: https://github.com/nathforge/pyotp integrated into fas. Another option might be to send out OTP secrets encrypted to each user using their gpg identity. One final thing: Ricky Zhou mentioned this group: duosecurity.com. They have a neat system and set of apps for smart phones/devices which circumvent the problems with otp secrets being exposed. But it requires that the device you have is connected to the internet in some way - which is tricky, to say the least. Implementing something like their system should be possible - but we're going to need someone who is an android and/or ios app developer to help. So - my questions are: 1. Is requiring an android/ios device too onerous? 2. Does the 'here's how it should work' section above make sense/seem secure to everyone? 3. who should we be requiring to use this? sysadmin-main? sysadmin-*, anyone with a shell account? Would it make sense to make ssh keys + OTP auth to get onto fedorapeople.org at all? what about fedorahosted? need input. :) -sv

11 26

احصل على امكانية الوصول الى صوري وأكثر من ذلك
by Karm Al-Bustany 18 Oct '11

18 Oct '11

مرحبا، لقد انشات صفحة شخصية على Netlog مع صوري وملفات الفيديو والمدونات والفعاليات و اريد اضافتك كصديق و يمكنك مشاهدة صفحتي الشخصية .في البدايه تحتاج للتسجيل على Netlog ! عند تسجيلك للدخول، يمكنك انشاء صفحة شخصية خاصة بك. إلقاء نظرة: http://ar.netlog.com/go/mailurl/-bT0yMTk5MTYxNDEwJmw9MSZnbT0xMiZ1PSUyRmdvJT… تحياتي ، Karm ---------------------------------------------------------------- لا تريد تلقي دعوات من اصدقائك بعد؟ http://ar.netlog.com/go/mailurl/-bT0yMTk5MTYxNDEwJmw9MiZnbT0xMiZ1PSUyRmdvJT… Don't want to receive invitations from your friends anymore? http://ar.netlog.com/go/mailurl/-bT0yMTk5MTYxNDEwJmw9MyZnbT0xMiZ1PWh0dHAlM0…

1 0

Re: 2factor auth
by Adam M Dutko 18 Oct '11

18 Oct '11

These problems we are discussing are difficult. The somewhat obvious part is that I think in the end no single solution will be the best. Using a phone based solution is scary. I cannot understand why one would want to base their security on a transient and expensive device. Such devices are easily lost, easily damaged, and as crackers are discovering, breakable, just like any other software based system. These same reasons are why I believe "fobs," "tokens" or whatever you want to call them, are also not an optimal solution. However, unlike phones, they are inexpensive, disabled with minimal pain/inconvenience as compared to wiping a phone, and although potential targets for theft, not as big of a target as a much more expensive devices like phones. Likely fob thieves would know what they are doing (which is scary in itself), but they are most likely less numerous than would-be phone thieves. The primary concerns I have about any system relate to how easy is to "rebase" aspects of the solution when different pieces are compromised; how expensive is the solution in terms of total cost expressed in dollars (new phone or token), time (administrative, transit, etc.) and resources (recreating the environment from scratch). Some of the suggested solutions rely on third parties so minimizing these dependencies when possible is probably a good idea. What happens if Oracle succeeds and Android is hosed in a few years (highly unlikely but possible)? What happens when YubiCo dissolves? What happens when Google pulls support for their OTP system (again unlikely, but possible)? What happens when solution x is compromised like the recent RSA breaches? We obviously cannot predict the future, so I guess I'm wondering what matters the most to those who will actively be using the solution? Like Seth, and other mention, what groups are we covering? and what can we require of each of those groups? Is it fair to say if you want to be an admin you have to have the dough to pay for a phone and pay for a service plan? I don't know, but it will shape the demographic in certain, and possibly, unfortunate ways. I also had a discussion with a friend who does a lot of reverse engineering. He mentioned the YubiKey hardware is trivial and that it would probably be more difficult to reverse engineer the algorithms involved in generating the OTP. -- Take care! -Adam

2 1

audit messages to syslog
by Kevin Fenzi 16 Oct '11

16 Oct '11

Greetings. I'd like to try stopping auditd and having selinux audit messages go to rsyslog (and thus be captured over on log02). This way we can have epylog process those logs, they can be remote so we can have a remote copy of them. This may result in some noise, but I think we can improve the epylog selinux module and fix things, and it gives us another audit trail of things happening on the machines where selinux is enabled. I think this should do it (in such a way we can easily back it out): diff --git a/modules/audit/manifests/init.pp b/modules/audit/manifests/init.pp index 30f19c7..ced28a1 100644 --- a/modules/audit/manifests/init.pp +++ b/modules/audit/manifests/init.pp @@ -6,8 +6,8 @@ class audit::auditd { include audit::package service { auditd: - ensure => running, - enable => true, + ensure => stopped, + enable => false, require => Package['audit'] } Thoughts? downsides? Alternate plans? kevin

4 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure October 2011