On 29 November 2017 at 12:29, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: > > > On 11/29/2017 11:34 AM, Stephen John Smoogen wrote: > >> In security, no one is trusted. I am not trusted, Kevin is not >> trusted, Patrick is not trusted. Dennis and Mohan are not trusted. >> This is because we are foolable and fallible. Even worse our accounts >> are not ourselves and could be used to look like us but not be us. >> This gives us each a potential reliability of 0.8 and a combined >> reliability of 0.1 (aka 90% of the time our root powers combined will >> cause things to be worse.) >> >> Second our infrastructure is very much an organically grown ball of >> kerosene soaked yarn. You get root on box A and magically you can >> affect something on box C because someone decided that <<fill in funny >> named service of the week>> needed to be used for our brand new << >> fill in feature that we try in Fedora N and shoved aside in N+2 >> and >> both systems use it. And we can't remove that feature or tool because >> oh someone built it into koji or fas or some other critical tool to >> cut down development time because it needed to be 'working' now. [Most >> of our services are 0.95 reliable but combined in their myriad ways it >> is probably a combined total of 0.4 -> 0.6. In another words 40-60% of >> the time something is not working right for someone] >> >> The two systems you are wanting root access to are some of the most >> interconnected in the kerosene level. Everyone who does have root on >> them has accidentally mangled all of Fedora in some way for several >> hours or days because we were trying to fix something and broke >> something else. > > So let's develop a set of sudo rules so I can only run certain commands? > That sounds good but isn't what you asked for. This may sound like a "but it should be clear that isn't what I wanted" but it isn't. Most requests for root from various projects has been for complete root and any amount of sudo rules gets them cranky. Which makes us reflex to assuming that a person is asking for what they know they require. Writing limited sudo commands is also hard because it is very easy to leave something open which goes BOOM.. we have done it to ourselves a lot and found that there is no shortcut to writing a command. It usually means making it very very limited and then opening it up slower and slower until it does what the person wants while we have a limited amount of risk. We can do this but expect that there will be a long period of "it doesn't do X", "ok try now" "I have lost Y" "ok why do you need Y?" "well it needs to get W working". And then a bunch "oh huh, I never knew it used Z" That requires a lot of documentation on processes all around. >> And when things fail, those of us in root are the ones who >> collectively get blamed for it. > > Possible blame is definitely something I worry about when requesting > access like this. I do propose that I work with some bumpers (i.e. > only doing things after I get someone to review it, announcing things > i'm going to do). Basically I would be in FBR mode all the time, except > after I get reviewed I can actually do the work myself. > I am not clear on FBR means in this context. I am used to the context Full Blown Root which is not what you are meaning. > Why did you let smooge have rights to >> the system? Why did you not check his actions before he did them. How >> did you not catch a ... in that line of code? It may all sound like >> reasonable questions but to the people who are dealing with the >> problem it gets picked up as "How did you let this moron ever do >> this?" And because things fail so much.. it eventually comes across as >> "You people are completely inept". >> >> All of this: >> * High chance that someone as root is going to make a mistake and the >> more people who have it more likely. >> * High chance that some systems will catch fire through all the rest >> of infrastructure >> * Perceived blame >> >> makes that adding anyone else a very difficult process. We can be >> prickly because of 3 and should mitigate it, but the real problem are >> the first two in the list. >> > > yes, hopefully the infra becomes less kerosene over time, but I'd like to > be part of the solution there rather than just someone waiting on it to I think infrastructure will always be keroseney by the nature of trying to make radical changes every 6 months. The best we can hope for at times is that a contained fire will take out enough old stuff we can build the new refinery on top of it. > happen. I'm mostly here to offer help and also deliver/release atomic host > every two weeks. Often times this means I find issues before anyone else > does (because I'm releasing tomorrow and not 6 months from now). This translates > mostly into: I help fix problems before other people even notice they are > problems. This translates into: I think I do more good than harm. The > jury is out on that, though. I am not sure I want the jury's opinion on myself. > Dusty -- Stephen J Smoogen. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
