19:59 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's
19:59 * ricky
19:59 * skvidal is
20:00 * nirik waves from the back of the room.
20:00 < mmcgrath> So I'm going to go quickly through some things so we can talk
20:00 * jeremy squints and tries to see if he can make out the front of the room from the
top of the cheap seats ;)
20:01 * lmacken is here
20:01 -!- mdomsch [n=Matt_Dom(a)cpe-70-124-62-55.austin.res.rr.com] has joined
20:01 < mmcgrath> First lets go through this last release
20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- The release
20:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- The preview
20:01 < mmcgrath> all in all it went well, the bit flip issue being the main issue.
20:02 < mmcgrath> we've suggested an earlier bit flip time though I don't
think we've heard that's how it will be from releng.
20:02 < jwb> i decree yes
20:02 < mdomsch> f13 wasn't excited by it
20:02 < mdomsch> but it would solve the problem at least temporarily
20:02 < mmcgrath> also interestingly was this grap -
20:02 < mmcgrath> h
20:02 < mmcgrath> http://mmcgrath.fedorapeople.org/MirrorRediness-11-Preview.html
20:02 < mdomsch> and the early fanboys will be pleased
20:02 -!- stickster_afk is now known as stickster
20:02 < mmcgrath> showing, in 3 hour intervals, mirrors being ready, then not ready,
then ready, then not ready.
20:02 * ricky doens't see why it would ever drop like that
20:03 < mdomsch> not sure either
20:04 < mdomsch> the 3-hour cycle matches that of a crawler run
20:04 < mdomsch> (which now will take <2 hours)
20:04 < mmcgrath> mdomsch: and of course my script started failing after that, but I
do have the last 24 hours.
20:04 < mmcgrath> I'll try to get that graphed and up after the meeting is up.
20:04 < mmcgrath> I accidently started appending the output from sleep :)
20:05 < mmcgrath> Ok, so all in all thats what happened there.
20:05 -!- kital [n=Joerg_Si@fedora/kital] has quit Read error: 113 (No route to host)
20:05 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure --
20:05 -!- RadicalRo [n=radical(a)18.104.22.168] has quit Remote closed the connection
20:05 < smooge> i am herew
20:05 < mmcgrath> So on to the meat of the meeting.
20:05 < mmcgrath> smooge: hey
20:05 < mmcgrath> So there's been lots of discussion on f-i-l recently and I
think it's mostly just re-hashing of stuff that's been on many of our minds for a
20:06 < mmcgrath> dgilmore and I have started looking at yubikey and lmacken is
already a user.
20:06 < mmcgrath> AFAIK, it's looking pretty solid.
20:06 < smooge> cool.
20:06 < mmcgrath> So lets flash forward and pretend we have a yubikey or some other
hardware style key thing implemented.
20:06 * lmacken would love to see yubikey's with a fedora logo on it :)
20:06 < mmcgrath> What do we want that environment to look like?
20:06 < mmcgrath> lmacken: yeah I told dgilmore we need to get mizmo to get some
stickers made :)
20:07 < mmcgrath> At the core of what *I* want
20:07 < mmcgrath> is two factor authentication.
20:07 < mmcgrath> for all of sysadmin-main.
20:07 < mmcgrath> and make it optional for others.
20:07 < mmcgrath> but what all that means is unclear to me.
20:07 < mmcgrath> So where did LDAP come in?
20:07 < smooge> hmmm at a previous place had our 2 factor item connected to the
kerberos server. This allowed us to have a 4 hour reauth time etc.. might be overkill etc
20:08 < ricky> The LDAP discussion came in as a response to the talk about a FAS PAM
20:08 < mmcgrath> I started looking at LDAP because we regularly have uses for it
but have to say no because we don't have it installed.
20:08 < ricky> Which might be a completely separate thing from 2 factor auth
20:08 < mmcgrath> And from the pam module
20:08 < smooge> so you plug in the key, do your login, and the kerberos authorizes
you, the LDAP authenticates (or vice versa)
20:08 < mmcgrath> ricky: right, completely separate but linked in this way...
20:08 < mmcgrath> If the yubikey server goes down, we can't auth.
20:08 < mmcgrath> which means our 'cached' nss setup now, isn't that
20:09 < mmcgrath> additionally.
20:09 < smooge> you then get a cookie from the kerberos server that can be cached
for X time
20:09 < mmcgrath> we can do different auth for different bits if we want.
20:09 < mmcgrath> for example ssh key to get into a server, but yubikey to auth on
20:09 < ricky> Would requiring yubikey for sudo auth be enough?
20:10 < mmcgrath> ricky: not sure, this is all the stuff we have to discuss and
20:10 < ricky> That's the main place where passwords come into play, but that
doesn't help much for SSH keys.
20:10 < mmcgrath> smooge: how do you think that type of setup would work in Fedora?
20:10 < ricky> smooge: Is there any way to make it optional without getting in the
way of non-token people (ie they don't need to go though an extra prompt or
20:10 < mmcgrath> jeremy: also, IIRC, did you mention some concerns about running
kerberos in Fedora because "clients connecting to two different kerberos networks is
20:10 < mmcgrath> or something similar
20:11 < jeremy> mmcgrath: yes
20:11 < jeremy> you can't (easily) have credentials from two kerberos realms at
20:11 < mmcgrath> so that's something to keep in mind.
20:11 < jeremy> unless you set up cross-realm auth. but that has to be done for
every domain you want to allow it with
20:11 < mmcgrath> especially since fedora is secondary for so many people. IE:
it's not their primary purpose
20:11 < smooge> well ricky we had multiple layers of authorization. Most people just
needed to use the OTP from the cryptocard for getting access. Sysadmins needed a key fob
for root access
20:11 < ricky> Something like yubikey would solve a lot of the problems of kerberos
though - passwords hashes would pretty much never get sent, correct?
20:12 < mmcgrath> ricky: correct
20:12 < smooge> mmcgrath, I would use the kerberos in the method that ricky
20:12 < mmcgrath> smooge: but what about the two kerberos realm problem?
20:12 < ricky> That is an issue worry with something like plain LDAP though,
although if somebody can get to a point where they can sniff the traffic, it's already
20:12 < smooge> Most people don't need it.. but some might and those would be
the admins etc...
20:13 < smooge> we did cross auth for zones we cared about and where we did not you
just do a kdestroy
20:13 < jeremy> smooge: constantly having to kdestroy/kinit is a royal pain
20:14 * jeremy used to do so between rht and ncsu. finally gave up on caring about
having ncsu tickets regularly
20:14 < smooge> jeremy, I don't know if I did it that many times.
20:14 < smooge> I had a script that executed that did my logins in the non-cross
20:15 < ricky> One nice thing about something like LDAP + Kerberos is that it can be
rolled out in small pieces.
20:16 < mmcgrath> So I guess my question is, what does kerberos buy us if we're
using otp keys anyway?
20:16 < smooge> I am not wedded to kerberos.. its just a way we used to get around
dealing with needing multiple cryptocard servers etc
20:16 < mmcgrath> from a security point of view, not much it seems.
20:16 < jeremy> smooge: it would cause major amounts of pain for rht devs doing rhel
builds + fedora builds (since at that point, keeping ssl certs _also_ would be kind of
overkill. at which point, we'd be using krb for koji atuh)
20:16 < mmcgrath> from the client point of view they have to use the otp more often,
but at the cost of greatly complicating any existing kerberos users (which would affect
lots of RH employees)
20:16 < jeremy> man, one of these days I need to learn how to type
20:16 < ricky> Kerberos would limit the number of services that we *really* make
sure are secure.
20:16 -!- tibbs [n=tibbs@fedora/tibbs] has quit "Konversation terminated!"
20:17 < mmcgrath> ricky: I take it you mean that as a benefit of kerberos?
20:17 < smooge> jeremy, I understand which is why I am not wed to it. Its more of a
way to deal with it without inventing kerberos lite (as I have seen a lot places do).
20:17 < ricky> mmcgrath: At least that what I thought people usually try to get out
20:18 < smooge> however, sometimes inventing kerberos-lite is what is needed
20:19 < mmcgrath> I think kerberos is going to be a non starter I'm afraid,
since it'd only work if we required it everywhere and I don't think we can do that
without making life difficult for any of our contributors who are already using kerberos
20:19 < smooge> mmcgrath, kerberos has 'single-sign-on' inconvenience with a
way to secondary log access/actions.
20:19 < jeremy> smooge: honestly, kerberos++ really needs to be done taking into
account the need of multiple identies. I don't know how much the ipa people have
thought about it, though, as I know a lot of their focus is basically "replace
AD" :) but that's probably getting way off-topic for this discussion
20:19 < smooge> jeremy, agreed (on all 3 accounts :)).
20:19 < mmcgrath> So, lets say our goal is two facter authentication using a
hardware key like yubikey.
20:20 < smooge> mmcgrath, agreed with no kerberos.
20:20 < mmcgrath> So lets leave implementation on the back burner for now and we can
think about it for next week.
20:20 < mmcgrath> And lets look at some of our services and how this would affect
20:20 < mmcgrath> The big one is things in our critical path, cvs, uploading to cvs,
20:21 < mmcgrath> I really don't think we can be in a position to require
packagers to get a hardware key.
20:21 < mmcgrath> even with an unlimited budget, I think it'd be painful without
20:21 -!- GeroldKa [n=GeroldKa@fedora/geroldka] has joined #fedora-meeting
20:21 < smooge> mmcgrath, I don't think it would buy much if we did.
20:21 < mmcgrath> anyone disagree with that?
20:21 < ricky> Agreed.
20:21 < ricky> But we still need to consider it from the perspective of people that
do need keys.
20:22 < mmcgrath> So then we'll be in a scenario where some hardware key is
supported but optional... There's a slight bootstrap problem there.
20:22 < mmcgrath> IE: If it's a checkbox in FAS to say "I want to use my
20:22 < mmcgrath> After that point, it requires the yubikey to log in.
20:23 < mmcgrath> So what do we do if they lose the yubikey?
20:23 < smooge> mmcgrath, I would say that its critical for things like people who
sign packages, people who have 'root' access, etc
20:23 < mmcgrath> smooge: by critical you mean required?
20:23 < mdomsch> smooge+_
20:23 < mdomsch> ++
20:23 < ricky> Just curious - what is the process for initializing the yubikey for
auth? Where would that fit in?
20:23 < mmcgrath> ricky: I haven't gotten that far yet actually. You can put
your own keys on there, but by default it uses the yubikey server.
20:23 < lmacken> ricky: doesn't require initialization on the key itself...
should work out of the box. It also has a write-only section that allows you to replace
the AES key
20:23 < smooge> mmcgrath, good first question. There needs to be a procedure for
deauthorizing a key tested and built before we allow for people to use them
20:24 < ricky> But somewhere, it has to be registered that this key gives access to
this user, right?
20:24 -!- philip_ [n=philip@unaffiliated/philip] has quit Read error: 104 (Connection
reset by peer)
20:24 < mmcgrath> smooge: yeah and this is a farily constant (though infrequent)
20:24 < mmcgrath> Since we have no real way to verify someone is who they say they
20:24 < lmacken> yes, just like a credit card... if you lose it, you can ensure that
the lost key can never be used
20:24 < mdomsch> FI buys the keys, distributes them
20:24 < smooge> mmcgrath, we were reauthorizing cards at places where I worked quite
a bit... it happens quite a bit.
20:24 < mmcgrath> mdomsch and I know eachother fairly well, if he tells me his
laptop has been stolen.
20:24 < smooge> it was a major cost part of my group.
20:24 < mmcgrath> It becomes very difficult for me to verify mdomsch is mdomsch
20:25 < smooge> you have to have a secondary trusted path for people.
20:25 < mmcgrath> ricky: this reminds me, we need a question and answer bit in fas.
20:25 < mmcgrath> smooge: yeah
20:25 < smooge> that would probably be a 'help' desk in the SIP section. The
person would need to dial in a code and then that would deauthorize the fas for that
20:26 < mmcgrath> Phone is a good method of verification, I don't think
we're currently using it like that.
20:26 < mmcgrath> Someone at pycon was doing something similar with asterisk.
20:26 < mmcgrath> though our asterisk setup can't dial out.
20:26 < mmcgrath> anywho, that's something that needs to get done but is a bit
20:27 < mmcgrath> So we want to be in a situation where we require yubikeys for some
subset of people.
20:27 < mmcgrath> What would our multiauth look like?
20:27 * nirik notes if you have a question and answer thing you should let the user fill
20:27 < mmcgrath> would we use password + otp?
20:27 < mmcgrath> nirik: <nod>
20:28 < ricky> Is there any option other than password + otp? That's the two
factor part, right?
20:28 < nirik> canned security questions are really nasty... especially since they
are often something someone can find out easily.
20:28 < mmcgrath> what would our other auth method be besides the otp I guess is my
20:28 < mmcgrath> ricky: I thought ssh key + otp might be good.
20:28 < mdomsch> mmcgrath, for what resources are we concerned
20:28 < mdomsch> ?
20:28 < mmcgrath> mdomsch: thats a good question as well.
20:28 < mmcgrath> obviously we wouldn't want to require otp for the otp
20:28 < mdomsch> for connecting using ssh, ssh key + otp would reduce liklihood of
stolen ssh keys being used to ssh in
20:28 < mmcgrath> Unless there's some sort of failover state.
20:29 < ricky> We can't do SSH key + OTP for sudo though
20:29 < mdomsch> ricky, right
20:29 < mmcgrath> ricky: correct, but would two factor in, and otp sudo work?
20:29 < mmcgrath> I think that seems reasonable.
20:29 < mmcgrath> although the stolen laptop bag becomes a problem.
20:29 < mmcgrath> since we still have to trust users to encrypt their ssh keys
20:29 < mdomsch> 2-factor tends to be "something I have, and something I
20:30 < mmcgrath> <nod>
20:30 < mdomsch> yubikey and/or ssh keys are "something I have"
20:30 < mmcgrath> and ssh key isn't really something you know.
20:30 < ricky> SSH keys seem too close to "two things I have"
20:30 -!- CheekyBoinc [n=cheekybo@fedora/CheekyBoinc] has joined #fedora-meeting
20:30 < mmcgrath> So we'd do fas password and otp?
20:30 < mdomsch> seemingly
20:30 < ricky> As much as I hate typing my password, that probably seems like the
20:31 < mdomsch> so again, what are we trying to protect?
20:31 < mmcgrath> mdomsch for me it's stolen credentials.
20:31 < mdomsch> sudo by someone in sysadmin-main
20:31 < ricky> What I got was "protecting against stealing passwords"
20:31 < CheekyBoinc> I've a problem with checking out a package. I had to renew
my ssh key and client cert because of hdd failure. The error is:
20:31 < ricky> sudo or any access to sensitive machines.
20:31 < mmcgrath> CheekyBoinc: please /join #fedora
20:31 < mmcgrath> CheekyBoinc: we're having an infrastructure meeting.
20:31 < CheekyBoinc> k :P
20:32 < ricky> Or you might ask in #fedora-admin if it's about the account
20:32 < ricky> **system
20:32 < mmcgrath> CheekyBoinc: yeah sorry you want #fedora-admin
20:32 < CheekyBoinc> okay thank you :)
20:32 < CheekyBoinc> #fedora-admin
20:32 < ricky> /j #fedora-admin
20:32 < CheekyBoinc> woops ^^
20:32 -!- CheekyBoinc [n=cheekybo@fedora/CheekyBoinc] has left #fedora-meeting
20:32 < mmcgrath> So would we blanket protect all servers (minus otp server)?
20:32 < mmcgrath> or pick specific ones?
20:33 < mmcgrath> for example...
20:33 < mmcgrath> trying to update and build a new package and re-typing your
password and press the yubikey becomes quite painful
20:33 < mmcgrath> you'd have to do it many times
20:34 < mmcgrath> but if we're just looking to protect sudo access it becomes
20:34 < ixs> mmcgrath: what about the low-tech approach of trusting your admins to
encrypt your keys?
20:35 < mmcgrath> ixs: we have a policy of that now, and had assumed people were
doing it but I'm not comfortable with that approach any more.
20:35 < smooge> most places I have dealt with two factor have not allowed ssh keys
because of the 'something we have' problem
20:35 < ricky> We already do that, but I now we're also considering the
situation where somebody can log keystrokes.
20:35 < mmcgrath> ixs: especially since if comsone could get their password,
they'd be able to update the ssh key in fas.
20:35 < mmcgrath> smooge: but what about ssh key to get in and do 'normal user
20:35 < ixs> mmcgrath: when I was with RH we considered smartcard auth for a
possible openvpn setup (instead of the cisco one).
20:35 < mmcgrath> but require the key to do sudo level stuff?
20:35 < ixs> mmcgrath: that would work, as it's a rather controlled usergroup
and you can force your users to do that.
20:36 < ixs> mmcgrath: sox compliance would be one possible excuse.
20:36 < smooge> mmcgrath, not really but the places with two-factor auth all are
places that don't want to be in the news (again)
20:36 < ixs> mmcgrath: for fedora contributors? never gonna work. for fedora admins?
20:36 < mmcgrath> hmm
20:36 < smooge> in this case we are looking at doing two factor auth for people who
we are giving higher levels of trust versus bottom level of trust.
20:36 < ricky> I think we've already ruled out requiring anything of all
20:36 < mmcgrath> ixs: sorry I missed something, you can "force your
users" to do what?
20:37 < smooge> in that case you usually need to work out a way for that person to
become someone else somehow.
20:37 < ricky> Does not requiring two factor auth on certain services undermine the
"something you know" part required for auth to the other services?
20:37 < ixs> mmcgrath: Red Hat IT could force all Red Hat employees to use a
smartcard based system for authentication. You probably can't do that with fedora
20:38 < ixs> mmcgrath: I couldn't think of a better way of decimating the number
of contributors... :)
20:38 < ricky> ixs: See above, we already established that we're not forcing
contributors to do this :-)
20:38 < mmcgrath> ixs: yeah we're not talking about the scope of fedora
20:38 < mmcgrath> just our admins.
20:38 < mdomsch> and just for sudo
20:38 < mdomsch> and package signing
20:39 -!- themayor [n=jack(a)22.214.171.124] has quit
20:39 < mmcgrath> mdomsch: although I could think of other servers that could use
20:39 < ricky> I'm not crazy about the idea of protecting sudo more than access
to sensitive machines.
20:39 < mmcgrath> yeah like the signing
20:39 < mmcgrath> or backup1
20:39 < mmcgrath> ricky: look at the cvs1 use case
20:39 < mdomsch> hmm
20:39 < smooge> how hard would it be to look at multiple 'roles' for
20:39 < smooge> s/roles/roles-n-accounts/
20:40 < mmcgrath> smooge: not following, give me a use case
20:40 < mdomsch> so ssh into sensitive machines could require ssh key and yubikey?
20:40 < smooge> I mean the other way I saw it done was I login in as smooge
20:40 < ixs> mmcgrath: but it applies to admins as well, to a certain degree. Two
factor auth is hard, says security-barbie, let's go shopping. And unfortunately,
it's often doubtful if the hassle of introducing it is worth it...
20:40 < ricky> ixs: If we enforce it, there's no getting around it though
20:40 < smooge> I want to become root/sign/etc I need to login to an account that is
not allowed to ssh in as. sudo/su sjsmooge
20:40 < mmcgrath> mdomsch: maybe, I'm not sure if that's technically
possible. ssh key auth is done by sshd, I'm not sure if you can mix it with pam. IE:
I think that's a "if either succeeds" not "if both succeed"
20:41 < mmcgrath> ixs: I'm pretty sure it'll be wirth it in this case.
20:41 * ricky is reminded of kerberos principals :-)
20:41 < smooge> From that account I can sudo/sign/etc but I can't from the
20:41 < mmcgrath> err worth
20:41 < ixs> ricky: I'm not talking about circumventing it... But on the other
hand, consider a local root exploit. You will be getting owned, even with a locked down
20:42 < mdomsch> mmcgrath, sshd uses pam by default
20:42 < mmcgrath> ixs: you have to remember that has never happened to us, stolen
credentials has and I'd at least like to be able to say "the way we got owned in
the past can't happen now"
20:42 < ricky> ixs: That's why I said I wasn't comfortable with just
protecting sudo and ignoring access to sensitive machines
20:42 < mmcgrath> mdomsch: but I think pam gets bypassed with ssh key auth.
20:42 < mmcgrath> smooge: that's not too hard, I believe we do that in some
20:43 < mdomsch> smooge, MIT had that concept too. user 'mdomsch' and user
20:43 < ixs> ricky: krb is great in theory. In the real world it's often useless
as people are not passing tickets but ask for the password and verify that. The
implementation is made out of fail...
20:43 < smooge> mmcgrath, it does. there is a reason why the 2 way kerberos patches
have to circumvent the ssh-key stuff
20:43 < skvidal> mmcgrath: pam is still involved with ssh_key_auth
20:43 < mmcgrath> ixs: you're a negative nancy :-P
20:43 < skvidal> mmcgrath: you can deny access to a user even though they have a
valid ssh key
20:43 < skvidal> mmcgrath: pam_access, for example
20:43 < mmcgrath> skvidal: but could you force ssh to require an ssh key and a valid
20:43 < ixs> mmcgrath: Sure, I have been around a bit doing security consluting...
20:44 < ixs> mmcgrath: the real world out there sucks. hamsters through straws.
20:44 -!- jnettlet [n=jnettlet(a)c-76-24-25-45.hsd1.ma.comcast.net] has joined
20:44 < smooge> ixs, we can always go with the RMS method. Put the root password in
/etc/motd because well someones going to find a local root exploit someday anyway
20:44 < skvidal> mmcgrath: I don't know for sure - I think I'd need to spend
some time with opensshd to figure that out
20:45 < ixs> smooge: that would be one possibility. After all, local security is
said to be non existing under unix... :)
20:45 < ixs> smooge: but I was actually thinking a bit more realisitic then RMS.
20:45 < ricky> So the main question that we have now is where we enforce it and
where we don't.
20:45 < mdomsch> smooge, that's the theory I use for my FON wireless AP at home.
guest/guest is perfectly fine by me for those users that find it...
20:45 < mdomsch> and the web page says so
20:45 < ricky> Have we decided that we want to enforce it on shell access and sudo
to sensitive machines?
20:45 < smooge> ricky, I would say that is what we should aim for
20:46 < smooge> eh.. backup... we want to enforce it for sudo normally and
shellaccess to sensitive machines
20:46 < ricky> OK, so what remains is pretty much cvs, hosted, and fedorapeople,
20:46 < ricky> smooge: Good catch
20:46 < ricky> Those are the ones that are likely to get annoying with a token.
20:47 < mmcgrath> ricky: OH! I just thought of something.....
20:47 < ixs> mmcgrath: granted, being able to say that stolen credentials will not
happen again is worth a lot. Two factor auth could offer that guarantee. Requiring the
admins to use passwords on their keys does the same with less hassle. Drawback: you cannot
enforce it. However: With smartcards you cannot really enforce it either... I've seen
people removing the password from smartcards, leave them in the reader or even better,
write nice ...
20:47 < mmcgrath> ricky: mdomsch: does the "can't use ssh_key"
scenario become easier if we use controlmaster auto ?
20:47 < ixs> ... wrappers entering the password as the pin cannot always be
20:47 -!- warren [n=warren@redhat/wombat/warren] has quit "Leaving"
20:48 < ixs> mmcgrath: users usually find a way of circumventing security
measures... be it post-its under the keyboard or smartcard systems...
20:48 < mmcgrath> it does.
20:48 < ricky> mmcgrath: that's a good point :-)
20:48 < mmcgrath> mdomsch: what do you think fo that?
20:48 < mdomsch> reading...
20:48 < smooge> ixs, that in the end is a personell matter.. no amount of technical
fixes can fix humanity.
20:48 < ricky> That reduces it to one annoying auth per bunch of commits, etc.
20:49 < smooge> however we can reduce risk
20:49 < mmcgrath> smooge: but I'm trying to fix that :) <lets out evil
20:49 < ixs> smooge: that's actually my point all along.
20:49 < mmcgrath> ricky: yeah
20:49 * mdomsch doesn't use controlmaster normally
20:49 < ricky> Short of giving your password *and* token away, it's kind of hard
to circumvent this without being being purposely evil :-)
20:49 < mdomsch> so I don't know the implications thereof
20:49 < smooge> ixs, your way of saying it comes across as we shouldn't bother
20:49 < mmcgrath> mdomsch: yeah, AFAIK it's as secure as using ssh agent
20:49 < mdomsch> yes
20:50 < mmcgrath> but becomes a problem if you drop your primary connection.
20:50 < mmcgrath> but that's an implementation detail, we can look at things as
20:50 < mdomsch> one more thought -
20:50 < mdomsch> puppet git commits
20:50 < mdomsch> don't require sudo
20:50 < mmcgrath> mdomsch: technically they do
20:50 < mdomsch> mmcgrath, ?
20:51 < mmcgrath> if you sudo -l on puppet1 you'll see -
20:51 < ricky> Everybody has sudo for the command that syncs the repo to
20:51 < mmcgrath> /usr/local/bin/syncPuppetMaster.sh
20:51 < mmcgrath> so the commit generates an email, and as part of that sudo syncs
20:51 < ricky> I don't think we have much to gain from requiring passwords
20:51 < mmcgrath> AFAIK there's no way to make a puppet update without
generating an email first.
20:51 < mmcgrath> and while that's not preventative, it is an audit trail.
20:51 < ricky> Not unless we require tokens of *all* people with access to puppet.
20:51 < ixs> smooge: not exactly. Asking for password protected ssh keys is a very
good idea. This is not very invasive. ssh-agent makes it easy. Requiring passwords
"constantly", be it short expire times or anything else, will push some people
to circumvent it. And in that case you have actually less security then before. On paper
it's looking very fine, but the reality is different.
20:52 * ricky has been wondering if there's a way to delay or get around puppet
20:52 < mmcgrath> ricky: depends on how much usability we're willing to give up
20:52 < mmcgrath> oh you mean just in normal usage.
20:52 < ricky> For example, DoS bastion and make a puppet commit to turn the mail
20:52 -!- yn1v [n=neville(a)static35-77.MAN-PI.cablenet.com.ni] has quit
20:52 < mmcgrath> ricky: yeah that'd work, it's an attack vector.
20:52 < ricky> But that's a whole other thing
20:52 -!- JukeBoxHero [n=gorillaJ@fedora/hitboxx] has quit Remote closed the connection
20:52 < mmcgrath> but still, we have to trust our admins at some point.
20:53 < mmcgrath> but I see mdomsches point about requiring sudo on puppet.
20:53 < mmcgrath> sudo would be that last "prove you are who you say you
20:53 < mmcgrath> I think it's worth thinking about.
20:53 < smooge> mmcgrath, trust but verify is my motto :)
20:53 < mmcgrath> especially since it's as easy as removing the
"NOPASSWD" line from sudo to use if we implement a hardware key.
20:53 < ricky> An attacker would be perfectly happy with abusing trust
20:54 < skvidal> smooge: thank you mr. president
20:54 < skvidal> ricky: smooge was making a joke from the gipper
20:54 < ricky> That does make sense (puppet sudo) to require auth from everybody.
20:55 < mmcgrath> Ok, so we're almost out of time and I'm sure we'll be
discussing this many more times before we do anything about it so I'm going to open
20:55 < ricky> Ah, hehe.
20:55 < mdomsch> mmcgrath, could be as easy as requiring ssh+git to commit to the
20:55 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor
20:55 < mdomsch> possibly
20:55 < mmcgrath> mdomsch: thats true
20:55 < ricky> Or just passwords on the sudo
20:55 < mmcgrath> Anyone have anything to discuss? (We can keep discussing this :)
20:55 < mdomsch> ricky, yeah, that's probably easier
20:56 -!- Sonar_Guy [n=Who@fedora/sonarguy] has joined #fedora-meeting
20:56 * ricky wouldn't mind a summary of what we've determined so far.
20:56 < ricky> It's easy to get lost in all of the side conversations
20:56 < smooge> ixs, I have found that the people who wish to circumvent passwords
are the sort to not want them for their ssh-agent either. at which point we are back to
zero. There will always be people who do not like the fact the world doesn't really
revolve around them (it revolves around skvidal)
20:56 < mmcgrath> ricky: I can write one up after the meeting.
20:56 < skvidal> smooge: and you wouldn't believe how dizzy that makes me
20:56 < ricky> Sounds good
20:58 < mmcgrath> anyone have anything else to discuss? We've got 2 minutes.
20:58 -!- Bob-Laptop [n=EvilBob@fedora/bobjensen] has joined #Fedora-Meeting
20:59 < mmcgrath> hehe boy I know how to quiet a room :)
20:59 * ricky makes a plug for people to test the anti-ctrl-c stuff
20:59 < mmcgrath> ricky: yeah send a follow up to the list about that.
21:00 < mmcgrath> ricky: I'll make sure to test it a couple of times by
21:00 < ricky>
21:00 < ricky> Will do, thanks
21:00 < ricky> If anybody has suggestions on how to make it easier for people to
test, I'm all eas
21:00 < ricky> **ears
21:00 < mmcgrath> So everyone think on this auth stuff some this afternoon. The
future is wide open there and no decisions have actually been made yet.
21:00 < ricky> We can make it open to all packagers, for example.
21:01 < mmcgrath> ricky: lets talk after the meeting.
21:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting End