Advisory/AMinutes20090206

Present: PG, PD, iang Location: Moebel

background check

discussion on board list
- bgc is to be a "practice" but not a policy
how to advance the background check forward
teus has asked for a BGC on a new sysadm
according to the practice, this is handled before an Arbitrator
teus has filed dispute?
- by implication, yes
Philipp Dunkell should take it through the first time
- so as to establish a precedent / pro forma ruling that expresses the result
- much easier for other Arbitrators to follow practice + ruling
- Philipp D to volunteer as Arbitrator
posted into SecurityManual
all sysadms to be background checked
- disputes to be filed
- PD is away for a week, when back, monday

policy decision is that all past ones have lost their status
however it is left open for board
updating is done by how?
- members ... have points up to 150
- 200 super assurers
- 300 board members
- 400 sysadmins
let's get a list of superassurers
- and then turn them off
this is a decision?
- the decision was already made by policy or board
- "send me an email with that decision"
- PD to dig out that decision and send it to sysadms/philipp G
Assurances can be revoked
- then they are deleted from the database
- or can they be negative?
- apparently they can't be negative
we shouldn't delete assurances
- how? is an implementation issue
- file a feature request ...
discussion morphed into discussion on logs

a better idea is to make proper logs of the actions
- we need the log for arbitrations
- better idea than not deleting them
- this is code that needs to be added
can we generate the log with what we have now
- "no, ... not much, ... maybe"
- if we cannot re-create this for a later time, over the past, this is priority #1
- if we can, no problem
what is the status of logging?
- a few things are logged
- no cohesive module for logging
- some additions to the database structure
what are the actions?
- certificate issuance and revocation
- account creation? why is that critical?
- changing and viewing of personal details
- assurance, changing up or down
what are the admin actions?
- changing the name
- setting a password
- activating code-signing
all these should be logged
how is log is done?
- into flat files?
- then import into SQL
- or into SQL and then exported out
- rotation of files?
important things are logged
- except for deleted Assurances (how to get supers dropped)
are accounts deleted?
- yes, because Arbitrator ordered it
- no, because accounts should not ever be deleted but should be zeroed!
- they are deleted as account
- but in future should be zeroed out?

Assurance Handbook
- => ted needs new minds on the job
- iang thinks it is ok for now
- maybe at Assurance events we can do recruiting
Code-signing
- should be easy
- insist on Assurer
- 100 points covers the identity
- Arbitration covers the enforcement
- should Arbitration be used to control it?
- this ensures that the Arbitration is agreed as the forum
- Does this scale? there are hundreds of code-signing certs, maybe 1000s?
- Shouldn't it be automatic?
- PD to look at it.
disaster recovery
- Rasika has provided a start at DisasterRecovery deriving from work done on BusinessProcesses using the framework of CISA.
- PD to look at it.
3rd party vendor agreement
- not looked at
CPS
- teus posted comments on CPS, mostly fairly light
- change in format from HTML to OO will slow down readership, cause name change problems and have to go back to HTML anyway
- typos, formatting, suggestions changes copied back to svn.cacert.org/CAcert/policy .htm HTML of CPS
- Evaldo is reading it
- need more readership, is it ready for policy group?
- discussion on use of IP from xkcd.com, basically good but should clarify the rights, iang

PG raises apps admins
- there should be OS/hardware admins managing the hardware and OS
- then there should be apps admins who update and manage the apps
old system is that
- CVS repository on primary online website system (not a daemon/online CVS)
- manual copy of approved source code to the online server
- (by apps administrators)
- checked in manually, checked out to online running code
in new arrangements
- critical systems admins need access
- approvals administrators do not
- systems admins should do the svn update from remote repository
- do a diff of the cvs copy
- pass the diff back to approvals team
- when the approvals team approves the diff, systems admins can do the cvs upgrade
but, svn is unreliable / insecure
- svn is not a security project!
- svn isn't watching for security like the openssh project is
- ok, so the method of transfer is not specified
- but the point is that the system administrators do it
sysadms have to develop a procedure for this
- to transport it securely, as well as other parts
- detail transfer method is not really to be in the SM
- either way the systems administrators on the critical team have this responsibility
Wytze loves diffs
- should be able to produce a set of diffs on the critical server
- match that to the set of diffs on the development server
- diff the diffs
- when the diffs match, let's go
- sysadms could get approval of the diffs?

should not be more than 3-4 paras
- does not cover tools
- (see above comments about method of transfer of patches)
Software is handed over to Systems team
joining is done by
- inside team has to propose and ask
- inside team is to do the preparation and interview
- initiate the background check / Arbitration
- board signs off on it
concept from past:
- anyone can contribute the code
- team is primarily auditing, verifying
- team is not developing
- therefore the name code audit team or code verification team
- "code improving team" or approval team
- this gives us a way for 3rd party code...
how do we define the systems administrators
- are the systems administrators
- since we have virtualised
- application administrators who operate the apps on the machines
  - e.g., DB is an app admin for email
which team does what?
- the critical systems admins currently also manage the apps
- the hardware access team is defined with MoU
- as the access list in Appendix B
- Wytze is currently managing both of these teams
- whether these are the same or different is irrelevant
roles
- approve software
- manage non-crit
- manage the app
- access the hardware
- support person
perceived difference between Group view and alternate Roles view
iang to review this content for SM