[Security_sig] 8/19 Conf. call minutes
chrisw at osdl.org
Thu Aug 19 10:03:14 PDT 2004
Ge Weijers (Sun)
Emily Ratliff (IBM)
Serge Hallyn (IBM)
Chris Wright (OSDL)
Joseph Cihula (Intel)
- CGL Security doc
- Review latest CGL draft
- Begin discussion of where Linux security should go from here.
Ge: Making good progress, with absolutely no input from the NEPs.
We are continuing with the assumptions w.r.t. user accounts, etc.
These make is much simpler, with DCL we'll probably hit more complex
requirements and need to spec RBAC.
Ge: More granular access control on network ports. Binding to low
numbered ports on specified interfaces.
Chris: Couple projects that do this, one is sockfs (kernel patch) which
allows you to assign group id to ports via virtual fs. Also, LSM can
support this, I believe SubDomain.
Chris: Is this an area where Linux is lacking compared with other OS's
and is already spec'd for deployed systems, i.e. feature gap, or is
this aniticpating a protection scheme.
Ge: Really anticipating a need. Although it is avaliable to some degree
in other OS's.
Chris: What's the use case.
Ge: Comes into play in the area where the security planes overlap. E.g.
the webserver that faces public network that allows indirect access to
management plane (update provisioning info, etc).
Chris: I'd like to get the specs behind us and work more towards
publicizing the group (it's open and public, just not publicized widely),
and generating the discussions around moving Linux forward to be leader
in the security space.
Ge: To a large degree, Linux is still chasing tail lights.
Chris: Discovering those gaps is one of the roles of the spec process.
But it would be useful to generate the gaps as a point of discussion.
This could help us identify work to be done, code to be merged, etc.
Ge: Don't have to follow lead, could raise the bar on security w/out
Chris: Absoultely agreed.
Ge: In fact, keeping in mind the mergeability of a feature is probably
a good idea. E.g. some security feature aking to OpenSSI which is cool
but invasive and not likely to be merged would not be that helpful.
Goal to get things upstream.
Chris: Agreed. LSM helps here to some degree. Adding new code that's
essentially modular and behind existing infrastructure is much more
palatable than invasive core changes.
Chris: Any other business?
Emily: Going to be off for a few months, Serge or Doc will represent.
Doc not likely to join us until specs are behind us.
Serge: I'll be here for these (specs) calls as well.
Ge: If any of you would like to review draft and provide feedback it
would be much appreciated. Thanks Joseph for the feedback!
Ge: Start a discussion re: where Linux needs to be going for next.
Chris: This discussion could identify content that'd be useful to go
over in a workshop env.
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
More information about the security_sig