[Security_sig] 11/11 Conf. call minutes

[Chris Wright]

Attendees:
----------
	Serge Hallyn (IBM)
	Joseph Cihula (Intel)
	Chris Wright (OSDL)
	Matt Anderson (HP)
	Philip Peake (OSDL)
	Slav Inger
	Ge Weijers (Sun)

Agenda:
-------
	- Run through feedback from end users
	- Run through feedback from DCL F2F
	- any other business

Actions:
--------

Minutes:
--------

Chris: Feedback from endusers pointed out something that we'd discussed
here as well, but didn't get into the assumptions.  Audit is a
requirement, and it's not called out in assumptions.  Having a protected
audit trail is at least as important, if not more important that
separating administrative duties.  In some cases system security is
aided by stipping OS, and providing minimal install.  This, to me, falls
inline with something that looks like namespace separation (whether it's
done via chroot, linux namespaces, SELinux, etc, isn't critical for this
point).  There was a very keen senstivity to changing the environment,
where the applications working set of assumptions could violate security
policy, but enabling policy will thus break the applications.  And also,
a point on network infrastruction being untrusted.  Here we agreed that
securing network infrastructure is outside of scope, but recognizing
that the network (even internal) may be considered hostile.

Joe: Separation of duties.  What was the feedback.

Chris: At least a prioritization issue, where audit was higher priority
than privsep.

Slav:  We require and use both.

Joe: Application separation.

Phil: An alternative would be using virtual machines.

Chris: Yes, certainly building traction within Linux.

Matt: Network problem, agree to punt on it, but put in some
recommendation to authenticate with your timeserver.

Chris: Should be covered under network is hostile.

Matt:  Agreed.

Joe: More secure default installs?  Something like Bastille?

Chris: Closest we got was descriptions of users stripping down their own
OS, to minimal needed installs.

Joe:  Was this acceptable?

Chris:  Didn't get that level of detail, my assumption is people would
rather not do that, but it's not been clearly stated.

Ge:  Minimal configurations can become a support issue.

Chris:  Part of why I assume this to be some level of headache.

Slav:  Not uncommon to build into support contract support for
customized OS.

Chris: Feedback from DCL was largely focused on audit mechanism.
The disussion boiled down to tamper-proof vs. tamper-evident.  And where
is MAC required.  And we just touched on if it's used, will it interfere
with future rollout of MAC, for example.

Ge: FreeBSD has stacking, and seems to work well, the MLS module is
only about 3000 lines.

Chris:  LSM doesn't really support this feature.  Serge is doing some
work in that area.

Chris: Tamper-proof vs. tamper-evident, thoughts?

Ge: Bruce Schneier, authentication information with each log, and roll
your keys.

Chris: So tamper-evident is better first target?

Ge:  Nice to have both, but tamper-evident is the lower hanging fruit.
Keep design simple to make sure you can explain it to a judge.

Chris: Other issues?

Ge: CGL current deadline is end of year, need to focus somewhat on that
again.

Chris: What's needed from this group?

Ge: Aiming to have security document done, so need assumptions.

Chris:  OK, that's quite close.

Ge:  Probably won't have to adjust much, only add if there's a need for
RBAC, for example.

Chris:  The assumptions aren't likely to call that out.  They'll stay at
a higher level stating administartive duty separation, but not call out
mechanism.

Ge: For securing existing mechanisms, current Linux may be sufficient,
for a newly written application.  But protecting an existing application
can still benefit from some type of containment mechanism.  But then we
start to talk in circles.

Joe: Timesys CGL compliance, can be found from OSDL website, link to
Timesys, and drill down to see how they are compliant.  For audit,
it's syslog-ng.

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