[freeze break][pre-approved][bodhi] Get TurboMail 3.0 working on releng04
by Luke Macken
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'
12 years, 6 months
ssh private keys on our systems
by Seth Vidal
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
12 years, 6 months
Re: 2factor auth
by Dennis Gilmore
-----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-----
12 years, 6 months
Packages installed on app servers but not in puppet
by Stephen John Smoogen
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
12 years, 6 months
2factor auth
by Seth Vidal
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
12 years, 6 months
Re: 2factor auth
by Adam M Dutko
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
12 years, 6 months
audit messages to syslog
by Kevin Fenzi
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
12 years, 6 months
