I am new to the fedora infrastructure group. I am going throug few of the links in the site to get a feel of the work. I have submitted my .ssh_rsa_key.pub from the site. I think I will get some intimation on this. Please someone can let me know further proceedings from here onwards.
Regards & Thanks Prabir Senapati mailto: senapati2001(a)yahoo.com
AFAIK the build hosts are RHEL5 (or maybe F10 by now?). At any rate
the rpm used in rawhide is quite different than the ones from the
hosts, how has this been solved in the build hosts? Has the hosting OS
upgraded its rpm to be compatible to all hosted chroots? Or is the rpm
within the chroot used?
I'm asking in a double context: First I'd like to understand if smart
can properly handle chroots of rawhide/F11 on F10/RHEL5 hosts. Anders
Björklund (in the Cc, please keep him there on replies) has put a
great deal of effort to have smart working on F10 and F11, and a smart
version for managing F11 and later chroots on F10 or earlier would be
And second I'd like to know how to setup a build environment for F11
for getting some ATrpms packages out.
Axel.Thimm at ATrpms.net
I've been lurking on the mailing list for a while and I finally
registered for my fedora account today (username: chrisj)
I'm interested in helping out as time permits. I got on irc once
(lurking again) and haven't really logged in since. I'll try to make a
few meetings after the holidays
I'm planning to get my personal test systems setup soon. I just moved
and still getting things straight at home. Bought a 750GB drive last
night and will be installing F10 over the weekend. I had been running
the U... distro and it's time to get back to the fedora/RH rpm way of
doing things :-)
I've used RedHat since before Fedora existed (I think 6 was the first
one). Started as a hobbyist, 2 years. Then got a job as an admin and
have been doing Linux admin and Cisco networks for the last 5 years.
My current employer is a Win shop so I just get to run the DNS,
email, and network, but the network is 50 remote offices and 3
different data centers in the midwest. I don't mind the Windows too
much and can find my way around them, it's also kinda fun to get the
Linux and MS products to play nice together. I've worked with a lot of
different linux and OSS software products including: postfix,
openldap, apache, bind, samba, mailman, pam, built some custom rpm's,
etc. I use RHEL mostly at work and some fedora and Cent for testing
(some suse, deb, and slackware in the past). I used to do lots of
security firewall apliances with various linux distros (I was a big
fan of LRP when it would fit on a floppy), most of this is now done
with Cisco in my world. I can shell script pretty well and I've
written several perl scripts in the last few years (dabbled in php but
not enough to know it well). I've always been interested in python but
don't have much if any exp with it. I also don't have much experience
with SQL/DB or source control.
I was looking at the FIGs and would be interested in the base sysadmin
and sysadmin-noc for now while I figure out where everything is and
what it does. I'm also interested in more info on the sysadmin-tools
and sysadmin-web FIG.
So, next just apply for the FIGs, keep lurking, ask some questions,
show up for IRC meetings?
Name: Brennan Ashton
Fedora Account Name: bashton
Name: John Poelstra
Fedora Account Name: poelstra
Project Name: TriageWeb
Target Audience: Bug Triagers, Developers, Quality Assurance. To some
extent this might include the general public, as a way to see how
fedora is managing bugs and developing.
Expiration/Delivery Date (Required): 06/06/2009
TriageWeb is a turbogears application that automatically queries and
processes bugzilla bugs to generate user defined reports on triage
Base reports include:
* Number of bugs of each work flow status changed for Fedora product
as a whole over time
* Number of bugs of each work flow status changed for component D over time
* Number of bugs of each work flow status changed for component group
E over time
* Number of bugs of each work flow status changed by user F over time
* Number of bugs of each work flow status changed by user group G over time
Data is presented in both tabular and graphical displays (these lack
some UI changes for customizing queries):
Here are some samples:
Tabular data can be sorted and date ranges can be selected.
Graphical data can have data ranges limited, as well as statuses.
Refreshes of bug data would be updated at the end of each day, as
processing the few hundred bug reports changed each day take a fair
amount of time.
FutureFeatures (not so far away):
* Will integrate with FAS so that users can store there queries for
later, they also can create custom user and component groups here.
* Send weekly reports on rawhide bugs, and well as top reporters,
triagers, and bug closers.
* A Look Into Rawhide
--This is an idea that I discussed with jlaska, the idea is that this
is a work bench that people can visit to see how we are progressing
with blockers as milestone are reached. This would also include a
section that more effectively then bugzilla, shows the top duplicated
bugs, so that developers and traigers spend less time having to sort
through 50 dup bug reports filed when component X failed today.
*Create a section where FAS groups and users can create a monitor
goals that are compared to standard queries. What this means will be
partially determined by feedback on what people use and how they use
the core features.
* Currently the project is locally hosted and is in a nearly usable
state already. There is still one known bug in the scripts that pull
data from bugzilla, this just requires going back and tracing what
types of bugs cause the error and then fixing the script to process
* In a week or as soon as the RFR is granted, people are wanting to
start testing the app, the triage group is especially eager to start
using it, this will give me significant feedback as to what needs to
be changed or added.
*After this has become stable, I will request that the application be
pushed live as a release application.
* I need to start looking into optimizing the database queries and
format, as the application is database intensive.
* Once the core app is running smoothly I will start to integrate and
develop the tasks outlined in FutureFeatures in the order that I have
listed them. The development of these features will mostly take place
during the months of June and July, and then continue at a slower pace
during the school year where the focus will be primarily maintenance
and bug fixes as I will have more limited time.
==Specific Resources Needed==
*Webspace to run the turbogears application
*Ability to create cron jobs for daily data fetching scripts (no more
then an hour each day)
--When rebuilding the database to introduce feature requests a script
will take around 10-12 hours. This should happen only very
occasionally, and does not take much processing power as most of the
time is spent doing xmlrpc communications with bugzilla.
*Database space to store metrics data as well as user preferences.
The metrics data right now in a sqlite db is only a few MB, I would
not expect it to grow beyond 50MB even with heavy user usage. I have
no preference between MySQL and postgresql
*Package wise all dependencies are in fedora already, with the
exception of traigeweb itself.
There may be a few others, but that should be a very representative list.
The point of this project is to give the traige, packaging, and QA
groups some new tools so that they can better measure there status as
well as monitor critical areas. This should especially help with the
development cycles once some of the FutureFeatures have been
introduced. This also allows fedora to better recognize the commitment
of some members in the community who spend there time in the drudgery
of processing, reporting, and solving bugs.
* I am looking for someone in the sysadmin-web group to sponsor me.
* I have filed this as ticket #1314
Thank you for the consideration,
Hey, I'm currently testing a solution for the problem where one can
prevent CVS commit mail from going out by pressing ctrl-c during the
To do this, I built a version of CVS with signal handling disabled and
made a wrapper script for cvs server that traps SIGINT and some other
I'd appreciate if people can test and try to abuse/break this setup :-),
so I have a test repo setup. To test this, you need to be in
1. Prepend your ~/.ssh/authorized_keys file on
(make sure not to accidentally lock yourself out with this)
2. Checkout the test module with:
cvs -d :ext:firstname.lastname@example.org/home/fedora/ricky/repo co test
3. Try to make a commit without it getting logged in
Feel free to try clever/evil things to test this out.
On Mon, Apr 27, 2009 at 07:43:01PM -0800, Jeff Spaleta wrote:
> On Mon, Apr 27, 2009 at 6:30 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> > On Mon, Apr 27, 2009 at 6:26 PM, Paul W. Frields <stickster(a)gmail.com> wrote:
> >> I did two counts, one for DVD and Live without uniq'ing the IP
> >> addresses doing the retrievals (because there could be multiple
> >> downloads from people behind firewalls), and one with. In both cases
> >> I think the numbers are very significantly higher than our current
> >> stats show. The raw numbers per day since F10 release are attached.
> > All those numbers in the txt use the "corrected" approach?
> Just to be clear.. what where the stats showing before? Just the
> unique DVD counts?
The download numbers before were using the direct download command
shown on this wiki page:
There was at least one major problem with that command; the Fedora 10
Live ISO filenames don't start with "Fedora-10," they start with
"F10," meaning we weren't counting them *at all*. So I've included
two counts, one for the DVD and one for the Live ISO as clicked from
the get-fedora page. (Other spins, as far as I can tell, are done via
torrent and we're capturing those statistics from the tracker
The second problem may not be a real problem -- it's that we are
uniq-ing the IP addresses doing the downloading. That method has the
potential to cut out legitimate, repetitive downloads from inside a
firewall. I'd feel better cutting those ticks out if they were
separated by a very short timeframe. Then we could be reasonably
certain they were caused by repeated clicks, rather than actual
separate downloads. In the interest of a conservative approach, I'm
willing to stick with uniq-ing the stats, but I produced both sets of
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
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(a)cpe-70-124-62-55.austin.res.rr.com] 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(a)188.8.131.52] 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(a)184.108.40.206] 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(a)c-76-24-25-45.hsd1.ma.comcast.net] 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(a)static35-77.MAN-PI.cablenet.com.ni] 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/msg...)
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
We need to do the bit flip sooner. The announcement is out, I've sent
over 600 requests and not a single one has come back a success. I know
work is being done to change this whole mechanism now, but we still should
be flipping the bit sooner.
I'd like to schedule a half hour of downtime for our netapp in PHX. This
should only impact some nfs related stuff (primary mirror and things like
images on the wiki).
I'd like to do this before the final freeze, RH's storage team will
actually be performing the work, I just want to find a time that will work
for everyone. Does sometime next week work?