On Tuesday, March 18, 2014 23:22:22 Devin Wolfe wrote: > That was not what was said. I was talking to Torrie about my prop to remove > myself from champion. I blocked it so I could leave. I am sorry it was > misconstrued. That was not my intention.
Either way, I already said earlier that I was blocking this. Until Justin, Chris, and I come to some kind of consensus about whether or not he gets access, nothing is happening. > > On Mar 18, 2014 9:46 PM, "a l" <[email protected]> wrote: > > Devin blocked this at the meeting, after 3 hours of arguments. Justin > > wants to discuss in physical form and disagrees with the consensus. Others > > also agree. > > > > On Tue, Mar 18, 2014 at 1:01 AM, Omar Rassi <[email protected]> wrote: > >> Andy, in answer to your questions by how other companies do it, I'll tell > >> you how the Army does it, > >> > >> First, you go through a 24 week long training course that takes you from > >> what is a computer, all the way to basic Cisco switch > >> deployment/management > >> (just lightly touching the surface of cisco equipment, basic LAN > >> management > >> and network topologies, windows deployment, information > >> assurance/security, > >> DoD policies, and basic active-directory concepts). I went through a > >> different but similar training program when I entered the service but I > >> was > >> able to demonstrate knowledge in all of these areas during the interview. > >> Once you complete this, you must be Security+ certified and demonstrate > >> knowledge of Windows image deployment, Active-Directory server, exchange > >> server, SCCM, troubleshooting and repair, customer service skills, LAN > >> management, and be able to hold a level-secret clearance before becoming > >> a > >> new sysadmin. A contractor must have similar credentials/experience > >> before > >> becoming a new sysadmin for DoD. And then there is a TON of on-the-job > >> training that you have to go through to include scripting. > >> > >> When it comes to the infrastructure that supports your website and your > >> central database, there is no margin for error. Many companies will > >> require > >> that you possess MSCE/MCSA, Cisco and Comptia certifications of varying > >> levels and/or a college degree in computer science and scripting/coding > >> proficiency just to get noticed, > >> > >> > >> On Tue, Mar 18, 2014 at 12:38 AM, Torrie Fischer < > >> > >> [email protected]> wrote: > >>> On Tuesday, March 18, 2014 00:21:16 Andrew Buczko wrote: > >>> > 1> do we have a processes for issuing Admin rights to new admin's? > >>> > >>> For synhak.org, it involves scrutiny, vetting, keysigning, sending a PGP > >>> signed ssh key, and a lot of proof that you know what you're doing. > >>> > >>> > 2> If no, then How do other companies bring on new admins? > >>> > >>> In most cases, see above > >>> > >>> > 3> Who are our current admins? > >>> > >>> Chris, G, Craig, and myself. Chris and I are the only active ones. > >>> > >>> > 4> What rights do they have for what services/virtual spaces. > >>> > >>> They've got complete access to the synhak.org AWS account. They're free > >>> to > >>> rack up our server bill, delete data with reckless abandon, have sudo > >>> access > >>> on all *.synhak.org machines, and get SMSs when system load is too high. > >>> > >>> If its in the physical space at 48 S Summit, thats a different topic. > >>> Anyone > >>> is free to rip open the boxes and reset the root passwords on everything > >>> as > >>> per do-ocracy. Nothing has a real connection to synhak.org except > >>> through > >>> tightly secured channels that have no chance of escalation of > >>> privileges. The > >>> Kiosk, for example, doesn't even have any access credentials to update > >>> the > >>> site. > >>> > >>> In fact, anyone can post some JSON data to > >>> https://synhak.org/auth/v1/sensor/3/, or any other sensor for that > >>> matter. > >>> There isn't a real way into the underlying linux system through any > >>> exposed > >>> endpoint. Even if they got onto the system, the services running on the > >>> web > >>> servers and the administrivia server have AWS credentials that limit > >>> them to > >>> specific operations such as creating new files on S3 (but not deleting!) > >>> and > >>> connecting to the mysql server. > >>> > >>> Actually, S3 and two tables on mysql are the only things the servers are > >>> allowed to touch. They can't kill servers, start up new ones, or wipe > >>> the > >>> database snapshots, or even see what backups we have. > >>> > >>> It is, of course, possible to limit AWS user accounts to only a small > >>> subset > >>> of permissions. For example, there exists a Treasurer role in the system > >>> that > >>> Xander previously held that only permitted viewing of the monthly bill > >>> and > >>> usage report. > >>> > >>> > On Mon, Mar 17, 2014 at 11:00 PM, Omar Rassi <[email protected]> > >>> > >>> wrote: > >>> > > As a sysadmin myself, I'd have to agree with the extra scrutiny for > >>> > > digital assets. I don't see it as a personal attack on anyone that > >>> > > regarding this scrutiny, we've spent the past three years fine > >>> > >>> tuning this > >>> > >>> > > virtual space to what it is now. Our virtual space is not like our > >>> > > physical > >>> > > space at all, you can't walk in to 48 South Summit and accidentally > >>> > >>> burn > >>> > >>> > > the whole building down with a typo or wrong command with ease, but > >>> > >>> that > >>> > >>> > > is > >>> > > MUCH easier to do on our virtual space. > >>> > > > >>> > > I've been involved with Synhak since Torrie's garage and in all this > >>> > >>> time, > >>> > >>> > > I have decided not to get involved with the AWS instances for this > >>> > >>> reason > >>> > >>> > > since I typo alot, instead I applied my talents elsewhere. Although, > >>> > >>> it > >>> > >>> > > would be nice if anyone who wanted to try their hand at improving > >>> > >>> our AWS > >>> > >>> > > instance or "Virtual Space" had sudo access to a sandbox duplicate, > >>> > >>> then > >>> > >>> > > we > >>> > > can only commit changes to the live instance that are proven to work > >>> > >>> while > >>> > >>> > > only providing read only access to the live instance. Keep in mind > >>> > >>> that > >>> > >>> > > the > >>> > > "Virtual Space" you are talking about does not just contain the > >>> > >>> website, > >>> > >>> > > as > >>> > > I understand it, Spiff is also on AWS, which handles, among other > >>> > >>> things, > >>> > >>> > > our membership database. Let's please try to keep admin rights to > >>> > >>> this on > >>> > >>> > > a > >>> > > "need to know" basis. I feel the term "positive control" (I know I > >>> > >>> use it > >>> > >>> > > alot) applies well in this scenario. > >>> > > > >>> > > On Mon, Mar 17, 2014 at 7:50 PM, Torrie Fischer > >>> > >>> <[email protected]>wrote: > >>> > >> On Monday, March 17, 2014 18:22:38 Justin Herman wrote: > >>> > >> > NOTE: Chris and Torrie were able to decrypt it with their private > >>> > >> > key's. > >>> > >> > > >>> > >> > In order to avoid extra noise and virtual conflict I have opted > >>> > >> > to > >>> > >> > >>> > >> answer > >>> > >> > >>> > >> > any questions during our meeting. I will be available to answer > >>> > >>> any > >>> > >>> > >> > questions during that time. This is equivalent in conditions met > >>> > >>> to > >>> > >>> > >> acquire > >>> > >> > >>> > >> > a Physical Space key. > >>> > >> > >>> > >> Noise implies useless information. I'm certain that SYNHAK would > >>> > >>> find > >>> > >>> > >> someone's reason for wanting access to AWS and all of our servers > >>> > >>> to be > >>> > >>> > >> useful > >>> > >> and even important information. > >>> > >> > >>> > >> I'm concerned about this "virtual conflict" you perceive. Why would > >>> > >>> you > >>> > >>> > >> think > >>> > >> that an open discussion about security would create conflict? > >>> > >> > >>> > >> You're also aware that meeting in person during a meeting aren't > >>> > >> the > >>> > >> conditions for getting a key, right? It involves a proposal for > >>> > >> Consensus. > >>> > >> There's also the fact that a physical door key is completely > >>> > >>> different > >>> > >>> > >> from > >>> > >> having administrative access to synhak.org. > >>> > >> > >>> > >> I will block any proposal to grant you AWS access on the grounds > >>> > >>> that you > >>> > >>> > >> haven't demonstrated why I should trust you, and that you're > >>> > >>> currently > >>> > >>> > >> demonstrating some interesting interpretations of protocols. > >>> > >> > >>> > >> > On Mon, Mar 17, 2014 at 6:10 PM, Torrie Fischer > >>> > >> > >>> > >> <[email protected]>wrote: > >>> > >> > > On Monday, March 17, 2014 17:05:56 Justin Herman wrote: > >>> > >> > > > SOME KIND OF BLOB > >>> > >> > > > >>> > >> > > Ok. Right. > >>> > >> > > > >>> > >> > > You sent a SSH key signed with a PGP key that I have not > >>> > >>> verified. > >>> > >>> > >> > > The > >>> > >> > > signed > >>> > >> > > key was encrypted with my public key, meaning that only I could > >>> > >> > >>> > >> decrypt > >>> > >> > >>> > >> > > it. > >>> > >> > > > >>> > >> > > Justin, are you aware that we are also asking you questions and > >>> > >>> not > >>> > >>> > >> just > >>> > >> > >>> > >> > > asking for an SSH key? I'll copy them again: > >>> > >> > > > >>> > >> > > VVVV QUESTIONS VVVV > >>> > >> > > > >>> > >> > > 1.) What is your primary purpose for requesting access to AWS? > >>> > >> > > 2.) What problems with the current website and online > >>> > >>> infrastructure > >>> > >>> > >> do > >>> > >> > >>> > >> > > you > >>> > >> > > currently see that require AWS root and sudo access to solve? > >>> > >> > > 3.) What improvements can you offer to the overall > >>> > >>> infrastructure? > >>> > >>> > >> > > 4.) Are you familiar with Ansible, the configuration-management > >>> > >> > >>> > >> software > >>> > >> > >>> > >> > > used > >>> > >> > > to configure, deploy and maintain servers? If not, do you > >>> > >>> intend to > >>> > >>> > >> learn > >>> > >> > >>> > >> > > about it? > >>> > >> > > > >>> > >> > > ^^^^ QUESTIONS ^^^^ > >>> > >> > > > >>> > >> > > In case they kept getting lost in the noise of this thread, > >>> > >>> I've also > >>> > >>> > >> > > trimmed > >>> > >> > > out the rest of the inline quotes. > >>> > >> > > > >>> > >> > > There seems to be a pattern of not answering any questions when > >>> > >> > >>> > >> directly > >>> > >> > >>> > >> > > asked. Would you prefer that I ask them in private instead of > >>> > >> > > on > >>> > >> > >>> > >> discuss@? > >>> > >> > >>> > >> > > I'm > >>> > >> > > often at the space, so I can handle either e-mail or in person. > >>> > >>> I > >>> > >>> > >> would > >>> > >> > >>> > >> > > still > >>> > >> > > need to relay the answers to a public forum such as noc@ to > >>> > >>> preserve > >>> > >>> > >> > > transparency about our site security and keep everyone else up > >>> > >>> to > >>> > >>> > >> > > date > >>> > >> > > with > >>> > >> > > who has unlimited and absolute power over synhak.org. > >>> > >> > > > >>> > >> > > If you're not able to make this work, then I can't really give > >>> > >>> you > >>> > >>> > >> access. > >>> > >> > >>> > >> _______________________________________________ > >>> > >> Discuss mailing list > >>> > >> [email protected] > >>> > >> https://synhak.org/mailman/listinfo/discuss > >>> > > > >>> > > _______________________________________________ > >>> > > Discuss mailing list > >>> > > [email protected] > >>> > > https://synhak.org/mailman/listinfo/discuss > >>> > >>> _______________________________________________ > >>> Discuss mailing list > >>> [email protected] > >>> https://synhak.org/mailman/listinfo/discuss > >> > >> _______________________________________________ > >> Discuss mailing list > >> [email protected] > >> https://synhak.org/mailman/listinfo/discuss > > > > _______________________________________________ > > Discuss mailing list > > [email protected] > > https://synhak.org/mailman/listinfo/discuss
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Discuss mailing list [email protected] https://synhak.org/mailman/listinfo/discuss
