CAcert System Admins discussion list

[Wytze van der Raay <wytze AT cacert.org>]

Op 18-5-2011 6:46, Ian G schreef:
> On 16/05/11 6:51 PM, Wytze van der Raay wrote:
> 
>> While we are losing Stefan as critical sysadmin, it would seem to us
>> that he
>> could be *very* useful for the critical sysadmin team in a new role,
>> namely
>> as (Oophaga) Access Engineer. Stefan is quite willing to pick up this new
>> role. An initial float of this idea among two existing Oophaga access
>> engineers raised considerable enthousiasm with them too. So unless
>> someone
>> can bring up serious reasons why this would *not* be a good idea, I would
>> like to propose this to the CAcert board.
> 
> Let me play the security devil's advocate here.

Always a good exercise, but I'll supply some counter arguments below.

> Is there a conflict between his access as a BIT employee, and his access
> as an Access Engineer?
> 
> One of the things that made BIT work was that they have no general
> reason to access the rack [1].  All the staff know this.

That's correct, but not specific to CAcert. The BIT employees will
generally only access a specific rack if their datacenter operation
requires it, security or otherwise (funny smoke coming out of the
cabinet etc.).

> So any attempt
> by any party to bypass our access engineers by using BIT employees will
> be something that is against our rules.  They all know it is a CA, it is
> a high-security rack.  (It might be the only one!)

Here you are overestimating things I think. The CAcert rack does not
stand out at all in the sea of racks in the hosting room, and I doubt
very much that all BIT employees will recognize it immediately as such
(they can look it up of course in their plans of the room).

> Knowing that no staff member should ever be in there is a big protection
> for us.  It means that all the other staff members will know something
> is wrong ... and report that person.  There are lots of Assurers in that
> building, so they have some incentive to do the right thing.

I'm afraid there is no such effect at all.

> This effect may be lost if staff members are also in there accessing the
> machines.  With or without anyone else... There is no need to report, as
> the staff member is supposed to be in there.  Meanwhile, we might not
> know... as he might not be working to our interests.

I don't think this is different from the situation now. This is also
possible without a BIT engineer being an Access Engineer. The only
thing that may stand out is the fact that the BIT engineer is accessing
equipment in a customer cabinet while there doesn't seem to be a BIT-
operational requirement for it like I described above. That's the same
in both cases.

> Another way of looking at this.  If the principle is good, if BIT
> employees can be Access Engineers, then why haven't we recruited the
> other Assurers in there to be our AEs?

I don't know, did you ever try? It doesn't seem a convincing argument
to me ...

> Indeed, do we even need AEs?

We definitely do need AEs as it's not the job of BIT employees to help
customers access their equipment. A BIT employee acting as an Access
Engineer is operating as a volunteer at the moment he is doing AE work.

> The answer to that is probably that we don't want anyone from BIT having
> access.  On a logical basis, as once they have some access, it can be
> easily argued as some other access.  This is how SP is written.

I'm not sure what you mean here. This is only physical access of course.
Let me give a counter-example that has raised no objections in the past.
Two of our AEs have also access to BIT for another project. This means
they can enter the server room and manipulate the server of that other
project, but nothing prohibits them from accessing the CAcert cabinet
at the same visit. This won't be logged as a CAcert visit. Are they now
disqualified as AEs? (Well, if they misuse this capability, they should
of course, but note that we have no way of checking on this). Again it's
only physical access that they'll have of course.
> 
> A third way:  are there other ways to help?  I've always felt that the
> channel to BIT was choked and unavailable to CAcert.  We had to ask
> questions of Oophaga who would sometimes not respond.  E.g., I
> frequently asked what the situation was with keys, never got a real
> response.  It took a couple of years to find out what their audit was
> about.  Having someone inside BIT who we can talk to directly would make
> matters much easier.  Just a thought.

I think it's more CAcert's own clumsiness rather than BIT unwillingness
to deal with questions. But formally Oophaga is the BIT customer, so yes
any formal questions and answers should pass through Oophaga. I'm sure
that we may be able to get some quick answers from Stefan on operational
issues, but it won't have an official status. That is still useful, but
having him available as Access Engineer seems to me a lot more useful.

Regards,
-- wytze

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature