19:59 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 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 about authentication. 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #fedora-meeting 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 release 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 -- Authentication 20:05 -!- RadicalRo [n=radical@xxxxxxxxxx] 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 while 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 module. 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 important. 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 it. 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 think about. 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 anything)? 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 painful" ? 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 once 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 mentioned. 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 pretty bad. 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 auth realm 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 of it 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 elsewhere. 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 that. 20:20 < mmcgrath> The big one is things in our critical path, cvs, uploading to cvs, and koji 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 people hours. 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 yubikey" 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) problem. 20:24 < mmcgrath> Since we have no real way to verify someone is who they say they are. 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 UID/code 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 off topic. 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 in both. 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 question. 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 server.. 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 know" 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 best way. 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 sysytem 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 ["Verlassend"] 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 easier. 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 stuff' 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? doubtful. 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 contributors. 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 contributors... 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 contributors. 20:38 < mmcgrath> just our admins. 20:38 < mdomsch> and just for sudo 20:38 < mdomsch> and package signing 20:39 -!- themayor [n=jack@xxxxxxxxxxxxxx] has quit 20:39 < mmcgrath> mdomsch: although I could think of other servers that could use it 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 people. 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 original account 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 sudo. 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 scenarios now 20:43 < mdomsch> smooge, MIT had that concept too. user 'mdomsch' and user 'mdomsch.root' 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 password? 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #fedora-meeting 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, right? 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 disabled... 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 laugh> 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 mitigating risk 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 we're testing. 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 /var/lib/puppet 20:51 < mmcgrath> /usr/local/bin/syncPuppetMaster.sh 20:51 < mmcgrath> so the commit generates an email, and as part of that sudo syncs puppet. 20:51 < ricky> I don't think we have much to gain from requiring passwords there. 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 mail. 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 server off 20:52 -!- yn1v [n=neville@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit "Leaving" 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 are" 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 the floor. 20:55 < ricky> Ah, hehe. 20:55 < mdomsch> mmcgrath, could be as easy as requiring ssh+git to commit to the trees 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 tomorrow. 21:00 < ricky> (https://www.redhat.com/archives/fedora-infrastructure-list/2009-April/msg00084.html) 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
Attachment:
pgpzDzYwTqi8n.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
