[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