[Security_sig] 6/24 Conf. call minutes

Chris Wright chrisw at osdl.org
Thu Jun 24 10:48:53 PDT 2004

	Ge Weijers (Sun)
	Emily Ratliff (IBM)
	Ed Reed (Novell)
	Chris Wright (OSDL)
	Mary Edie Meredith (OSDL)

	- Input from DCL re: next capabilities document
	- Continue towards defining/refining our methodology for threat
	  analysis and protection profile generation.
	Chris: final mail list switchover.
	Ge: work on CGL doc for next meeting (July 15th)

Mary: Next update to DCL capabilities document is looming.

Chris: Can use some interfacing to discuss deployment models to get a
handle on assumptions, etc.

Mary: We have broken down the models into edge, infrastructure and
database server.  Perhaps this will help define deployment models.

Chris: What is the timeframe?

Mary: November publish, contents solidified in October.  If not ready,
some kind of descriptive statement describing the change of direction
and new methodologies.

Ge: CGL due in August for Sept. F2F, and should probably take precedence
over DCL.  So Sept. could be good for writing.  Looking at dates for
getting on DCL agenda.

Mary:  Perhaps mid-July with DCL tech board.

Ge: Hopefully this will work and could include a view of current CGL

Mary:  Also, the DCL F2F is at the same time as CGL, so might be a
useful time to have folks in same place.

Chris: Mail list is open (or should be by this morning).  Will double
check, and then send out email with status.  You should have received
email regarding the groups.osdl.org website.  This has calendar, doc
sharing, minutes, action items, etc.  I think we'll continue status quo,
using the list for primary communication, but can use groups.osdl.org as
we find it useful.

Emily: Can we use the calendar for security SIG meetings?  Didn't see
them on the calendar.

Chris:  Yes, they were there last time I looked.
Mary: Yes, it's just broken at the moment, fix up is underway.

Chris: Alright, on to the methodology...reviewing last week's minutes.

Ge: Start writing publish early, publish often. And look for feedback. Cgl
tech board described control plane separation for cgl deployment models.
Out-of-band signalling, databases are deep inside controlled networks.
Different from DCL where everything is live and online.

Ed: Appreciate Ge's description of CGL assumptions.  Helps focus the

some back and forth on descriptions of sepecifc assumptions (4 and 5.1)

Ed: These are at odds.  Can the system be on the network?  And even if
the system doesn't have network facing root services, does it have any.
A service compromise could be used to leverage a local exploit to get a
root shell.

Chris:  I think it depends on the system, but primary concern doesn't
appear to be security, more like keep trusted admin from shooting one's

Ge:  NEP may have a shell for admin, but customer typically on has
application admin shell.  So shooting foot could look like downing all
T1 spans accidentally.  Priv sep could be helpful, so that you can do
equiv. of ifconfig up/down w/out need full privs.  Could be best served
by simple "Are you sure?" prompt.

Ed: Alright, but do you want it or not?  People complain about deploying
it.  Have to have separation of duties which may require extra steps
for administration (using different tools, and differenct auth, etc.)
If intention is to keep admin safe from accident this is similar to
securty concerns, getting at the intention here is difficult.

Emily: Sound like CAPP assumptions.

Ge: Yeah, much more like CAPP than other profiles.  Not assuming
environment is malicious.  Trusted admin.

Chris:  Emily, you bring this up as suggestion that we should we use that?
Or just an observation?

Emily:  More of an observation.  Well, at least look at CAPP.  Anything
beyond "Are you sure?"  prompt, gets out of realm of CAPP.

Ge:  Many CGL systems do not need to be hardened against network
atttacks.  Only those in control plane.

Chris:  Ericsson has done work on clusters and distibuted security
infrastructure.  So there is some assumption that the network is unsafe.
I don't believe thes are deployed on public network, but internal network
isn't assumed completely safe.  In black and white terms, it would
have to be considered hostile.  This requires different protection from
switch room.  Not all  the deployment models are the same.

Ge:  I've seen call center with VOIP and call center workstations on common
PC on network.  This means the infrastructure can include things like
explorer and worms/viruses.  Very different from switchroom.

Chris:  I agree, I've seen similar.  But it's not clear that this is
being spec'd out by CGL.  At least we can lead the requirements with
description of assumptions, so it's clear what's being assumed and
what's being protected.

Emily:  Sounds like there are possibly many different models.  Reminds me
of the kickoff for this meeting.  Ross said something like 'No spam
fighting solutions' which clearly indicates an email service, etc.  But
this may not be true of all DCL systmes.

Chris:  Yes, having usages helps identify the assumptions and threat.

Ge: Can't make call in two weeks.

Emily: Can we do anything while you're out?

Ge: Going to read ITU doc, and go from there.

Chris:  So getting systems descriptions would be helpful.

Ge: yes.

Chris:  This has historically been difficult.  DCL had discussed using
use case scenarios.

Mary: Actually created some of these at one point in the past.  But not
with security in mind.

Chris: Even having detailed description is useful.  Shall we meet in
three weeks, 15th?

Agreed.  Move out to 15th, bi-weekly from there.

Ed: OLS BoF plans?

Chris: gotten word from a small handful of folks that they will attend.

Emily: Doc will be there from IBM.

Chris:  Description was written before this meeting was clear, so it's
broad.  Should have some SIG folks, also some general security interest,
some SELinux folks, SubDomain folks, etc.  We can take it wherever
useful...discussing Ge's doc...grabbing DCL/CGL folks and running
through usecase scenarios, just meet and putting face to name...

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

More information about the security_sig mailing list