[Security_sig] 01/20 Conf. call minutes

[Chris Wright]

Attendees:
----------
	Ge Weijers (Sun)
	Emily Ratliff (IBM)
	Serge Hallyn (IBM)
	Joseph Cihula (Intel)
	Slav Inger
	Andy Murren
	Matt Anderson (HP)
	John Cherry (OSDL)
	Chris Wright (OSDL)


Agenda:
-------
	- DCL doc review needs more input (and upcoming F2F).
	- DTL doc status
	- CGL spec review, hoping it'll be posted soon (and upcoming F2F).

Actions:
--------
	Mary/Lynn: DCL document to list
	Phil/Slav: DTL document to list
	Ge/Chris: CGL review

Minutes:
--------

Emily: DCL doc, securing one server in the data center.  DTL doc puts
requirements on the data center.  Do we need another doc, fall through
cracks, DTL doc as environmental.

Slav: Did my reply on list clarify?

Chris: I think we should place these as envrionmental assumptions in the
DTL doc.  Let's

Chris: Remote authorization done by which projects?

Emily: Access Manager from Tivoli

Slav: Active Directory

Ge: NFSv4

Slav: CIFS shares, local uses local engine, if GPO in effect, all goes
to server.

Emily: Do we have a volunteer to get the envirnomental pieces into the
DTL doc?

Ge: Integration between client and server should mirror on both sides.

Slav: Client piece of TLS, certificate revocation on server side, etc.

Andy: Recommendations for securely coding the applications?  Dialog box
that can take shell commands because it's not securely written, for
example.

Chris: Mostly pointers to existing docs.

Ge: How do I justify openSSL by itself?  IPSec, same.

Chris: Start with network being hostile.

Ge: But it's requirement on the application.  It's not making the OS
more secure.

Chris: Take ssh vs. telnet.  Authentication tokens in the clear could
break system security.

Andy: Audit logs off the box.

Chris: Infrastrucutre library.  Makes sense for OS to provide it.

Joe:  I like the application tools requirements.  This security part is
just one part

Ge: Audit requirements don't currently have any justification.  Auditing
doesn't keep the box more secure.  

Joe: Auditing is called for in O.DETECT-SOPHISTICATED, etc.

Ge: Containment is a new requirement.

Chris: I look at it like, physical separation, then chroot/jail/namespace,
then MAC based ala SELinux.

Ge: Pushes burden onto customer.  And full, secure configuration is
still very non-trivial.

Joe: It does shift the burden.  But it's a chicken and egg issue, where
if it's never provided by the OS, the problem will never be solved.

John: Containment seems reasonable since it could be done via chroot-ish
way or SELinux, and since we don't know what the complexity of the
application looks like, we can't make assumptions about the solution.

Joe: Perhaps we can break it down into pieces.  Simple vs. complex
containment.

Ge: Is it OK to have objectives with no requirements?

ran out of time...

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net