[Security_sig] 10/14 Conf. call minutes

Chris Wright chrisw at osdl.org
Thu Oct 14 11:47:32 PDT 2004


Attendees:
	Ge Weijers (Sun)
	Slav Inger
	Doc Shankar (IBM)
	Serge Hallyn (IBM)
	Chris Wright (OSDL)
	Mary Edie (OSDL)
	Ed Reed (Novell)
Agenda:
	- Feedback from Japan F2F
	- Assumptions feedback
	- CGL security review work (Joseph)
	- any other business
Actions:
	Chris: New round of assumptions
	 	- Admin trust is wrong
		- Need audit
		- Need audit protection (MAC fallout)
		- When application breaks it can do no more damage than
		  it could while running normally.
	Ed/Chris: Function specific LSMs
	Mary/Chris: Get together re: DCLs capability doc needs
	Chris: LSM registry for existing modules.
Minutes:

Chris: Rundown on Japan F2F.  Mostly nods on the assumptions, and most
importantly agreement from DCL folks to get time with user-facing groups.

Ed: Access to backup tapes has information access which is normally protected
via security of live system, but could be used in test systems, etc.

Chris: Physical access to the machine is clearly required.

Ge: Edge from DCL is similar for CGL.

Mary: DCL is working hard to update the capabilities document.  Need
sigs help to get the security bit done.  At least the content.  Written
down for draft document.  Nov. 9th-10th is F2F.  Idenfity short list
questions instead of full assumptions.

Chris: DCL assumptions...

Doc: Start from different angle.  Not MAC, vs. DAC.  Look for audit log
for privileged users.

Mary:  Auditing may provide some social engineering effect for
preventing attacks. assuming the audit logs can't be tampered by the
user.

Doc: That was implicit in what I meant.  We

Slav:  We use SeOS, which has functionality similar to something like
SELinux or LIDS.  And we specifically 

Doc: SELinux has this property but is too complex.

Slav: Layers of authority, not implicit trust in admin.  Sarbanes-Oxley,
HIPPA, etc. were drivers of this.

Chris:  Assumption that there's implicit trust in authorized administrator
is false.

Slav: It's also ability to collect audit logs.

Ge: What kind of mechansim is used?

Slav: Policies restrict executing binaries, r/w on files/dirs.  In
other words, built-in access controls were insufficient.

Doc: How do you describe the policy?

Slav: Similar to LIDS or SELinux, policy database which is loaded upon
initialization.  Problem is SELinux is too complex to deploy.

Doc: Orthogonal roles, sysadmin, audit admin.

Ed: Cryptographic key administrator.

Doc: Maybe we should make specific LSM's to just protect audit
subsystem.

Ed: Agree, small LSM

Chris: What does this look like?

Ed: Audit framework, generate LSM that protects audit framework, then
show that it can protect all of these.  To do this right, generate a
protection profile.

thanks,
-chris



More information about the security_sig mailing list