[Security_sig] 9/2 Conf. call minutes

[Chris Wright]

Attendees:
	Ge Weijers (Sun)
	Serge Hallyn (IBM)
	Chris Wright (OSDL)
	Joseph Cihula (Intel)
	Slav Inger
	Ed Reed (Novell)

Agenda:
	- Security Spec review
	- Japan F2F
	
Actions:
	- Ge will send out next CGL draft.
	- Ed will send out static roles (and perhaps his quick list of
	  deployment scenarios).  Discussion on list, and pick up in one
	  month after F2F.

Minutes:

Ge:  Thanks to Joseph for fedback.  Will be incorporating feedback for
the upcoming spec, and generating another snapshot soon.

Ge:  DCL needs attention, and is much closer to general purpose security
improvement (unlike embedded telecom security).  Pushing out another
draft.

Chris:  F2F in Japan, three basic pieces.  First is overview of security
SIG.  Description of starting with Common Criteria, backing off a bit
due to being bogged down in details.  Work from assumptions directly,
and generate a profile that's in the vein of a protection profile.  I'm
anticipating the question of what are the gaps and what are the
projects.  Other two bits are specific to CGL/DCL specs.  Will have
phone numbers for folks to call in.

Chris:  After that we get back to the discussions of general improvement
of Linux security.

Ed:  What's the scope?  Do we talk about sepcifics and generate tarball
names and version numbers?  Do we look at 5 year timeline?

Chris:  Should be up to group.

Ed:  We've done this before and got shotdown by customer requests for
packages.

Chris:  Hope this wasn't me shooting things down.

Ed:  No, from the working groups.

Chris:  Ah, yes.  We've been doing the specs, and they're looking for
that level of detail.  But that's not our only charter.  It's a public
forum, and getting past the specs we can bring in people from outside
and decide on whether we care about 6 month define projects scope, or 5
year horizon.  Personally, I think some of both is helpful.  Linux works
on shorterm needs.  Scratch itch, and do it simply now.  Having some
notion of being informed on a timeline can be helpful.

Ed:  Just wondering if this is the right group?  Who decides that?

Chris:  I think it can be.  We should decide with concensus.  But we
aren't solely driven by wg needs.

Ge:  Agree.  Sometimes we get into solution looking for problem too.

Chris:  Example?

Ge:  Well, for example SELinux is out there, so people consider it as
the solution.  But we don't have good details of what the problem is.
And SELinux is way too difficult to use.

Ed:  We should start with half-dozen deployment models to show what the
problem is.  Then works towards the solution.  SELinux is too hard to
use.  It's an assembly language geared to describe what the
application's intentions are.  This is way too low level, and difficult
to use.

Ge:  You create all these profiles, but then you have to determine if
it's even safe.

Chris:  There's actually ongoing work in that area.  SELinux is meant
to be general.  Bad analogy...So, like a general purpose OS, it's a
solution where you don't know how people will define the problems.
The primitives are low-level (akin to syscalls), and you depend on
libraries to simplify the low-level interface for specific applications.
So one direction is effectively libraries for SELinux, to move away from
the low-level interface.

Ed:  Starting with deoployment models we can work towards determining
the security needs.  Flushing out all the models could take 6-9 months.
This is before we start listing security needs, and certainly won't be
able to point at rpm's anytime soon.

Chris:  While 6-9 months sounds long, I think this is a fine approach
for this group, as long as others agree.

Ed:  We move slowly, so it's realistic.  Question is, does it happen
here?  I think we could get the list of half-dozen deployment scenarios
quickly.  But if we can't even describe them, we can't secure them.

Ge/Ed discuss some deployment scenarios.  Ed quickly itemizes 7.

Chris:  Separate models...I quickly get to the box that serves multiple
models.

Ed:  No problem with your composition, but w/out basic models we can't
even begin to discuss the composition.

Chris:  I agree, just see that this becomes the interesting area.  If
we have security modules for different deployment models, for example,
then it stresses the LSM system (but Serge is working on that ;-).  And
if we use SELinux with some set of deployment specific libraries they
have to interact.

Serge:  What's the stress on LSM?  And I can't see composing models that
way with SELinux as being very easy.

Chris:  The need to do stacking.  And, yes I agree.

Some more dicussion of starting the process, where it's appropriate,
what questions do we ask (i.e. stop running everything as root?).  Leads
to interesting discussion of 9 static roles (configurator, installer,
restorer, application, administartor...probably got these wrong, Ed is
sending to list).  We can discuss these onlist and pick up after the
F2F.

thanks,
-chris