[Security_sig] 10/28 Conf. call minutes

[Chris Wright]

Attendees:
----------
	Ge Weijers (Sun)
	Serge Hallyn (IBM)
	Chris Wright (OSDL)
	Linda Knippers (HP)
	Mary Edie (OSDL)
	Ed Reed (Novell)

Agenda:
-------
	- More on assumptions feedback
	- CGL security review work (if Joseph can make it)
	- any other business

Actions:
--------
	Ed/Chris: Polish off security assumption.

Minutes:
--------
Linda:  I'm missing some background.  Are these assumptions reflecting
normal deployments with other OSs?

Chris: Earlier rounds of similar work created something that looked
more like a security buzzword list.  This has been an attempt to
define an architecture, with an eye on where Linux may be missing
features relative to other commercial OSs, but also an eye forward
on what it takes to generally raise the bar (keeping in mind we don't
need to place it artificially high and make it too tough for vendors).
These assumptions come directly out of a conversation trying to justify
mandatory access controls.  So they should be vetted by end users based
on current industry best-practices, but also working towards Linux as
the most secure platform.

Ge: Reads very familiar to banking institutional requirements.

Mary: Apps and database server only?

Ge: Some are still applicable to edge.  2&3 fit CGL which will be very
similar to edge.  Of course, some aren't as applicable (e.g. 5 with
backups, etc).

Mary: Closing questions in assumptions, I could use more explanation.

Ed:  Those were a little round, let me flush it out.  There are both
technical and non-technial measures.  E.g. in CGL understanding that the
admin is trusted, and the box is behind lock and key.  This is
non-technical solution, guard logged access, admin had background check,
etc.

Mary:  Isn't this going to vary site to site?

Ed: Yes, certainly.  Stock certificates may need a mix, to make sure
they can be mounted and sent to a printer, but also some protection to
retrieving the paper off of the printer.  If you don't need to protect
yourself from the admin, you may not need MAC.

Mary:  Auditing had a social deterrent effect.  Is that technical?

Ed:  It's a technical solution, and you have to also consider whether
auditing is bypassable.  Assuming not, you'll need some MAC policy.
We'll likely need a way to separate privileges so that not all admins
can turn off auditing.  This is what is in 1 and 5.

Mary:  Maybe we'll have to take it offline, but want to make sure the
list of assumptions is complete.

Chris:  Mary wants to make sure those final questions need to be
answered.

Ed:  Ah, those are really my thought proceess.  Where the questions
posed are answered in a way by the assumptions.  1 and 4 are the basics,
and 5 especially hammers on those and flushes out details.

Mary:  People may not understand implications of the assumption, where
does it take us.  What feature is then required.

Ed:  Oh, I think we can drill down to that pretty quickly.  One thing,
if we say.

Linda:  I don't think we need to start with a clean slate.  What
already exists today?

Ed: Starts to get into best practices.

Mary:  What about the existing profiles?  Can we use those?

Chris:  Those won't get to the level of detail to get feature specific
gap analysis.  For example, we won't get something like CAP_SYS_AUDIT
must be enabled to turn on and off auditing.

Ed: That's the work that needs to be done, that I mentioned.

Mary:  We are trying to make a strong statement about what people need.

Ed:  In order to make distinction between solution and mechanism. We need
to make sure the LSM hook mechanism is available for policy enforcement.

Mary: Do we need to make this an assumption?

Chris:  It's a different level of detail.

Ed:  It's that what vs. the how.

Chris:  It's really just saying the vendor is shipping with a 2.6 kernel ;-)

Ed:  Well, it's a bit more than that.  It's also making sure new
subsystems have proper hooks to be protected.

Mary: Can we start writing the next level of detail?

Ed:  Here's a concrete question for end user.  Do all the help desk
operators just have root?

Mary:  Sounds like a list that should be put down and fed to end user.

Ed:  Recall the list of nine I posted?  Application lifecycle
management.  Help desk is application administartion.  audit, restore,
install, configure, start and stop system, runtime id of subsystem,
administrative privs, users of the system, backup.  This doesn't reflect
research, these are just the nine that keep popping up in my world.

Mary:  Where does the crypto key admin come in?

Ed:  Below audit.  It's an auditable subsystem.

Mary: I would like to see 'the how' assumptions, like LSM, audit,
separate roles, subsystem break down (of 9) (and MAC?).

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