[Security_sig] 4/14 Conf. call minutes

Chris Wright chrisw at osdl.org
Thu Apr 14 10:31:11 PDT 2005


Attendees:
----------
	Joseph Cihula (Intel)
	Ed Reed (Novell)
	Dan Jones (IBM)
	Chris Wright (OSDL)
	Matt Anderson (HP)
	Mary Edie Meredith (OSDL)
	Bruce Fields (CITI)
	Kevin Coffman (CITI)

Agenda:
-------
	- NFSv4 security discussion
	- CGL security spec
	- DCL security spec
	- any other business

Actions:
--------
	Mary/Bryce: Get matrix work done, and bring back to security_sig
	for review/resource allocation.  Also, remind us about nfsv4 call.
	Ed: send Chris/Mary NISCC contact info
	Matt: send Joseph updates for CGL doc
	Joseph: send updated doc to list
	Ed: begin flushing out DCL outline (talk with Emily)

Minutes:
--------

Mary: Effort to drum up folks that can help with the NFSv4 security
testing effort.

Chris: What level of security testing?

Bruce: Code auditing is one area, in the rpc code.  Usability testing.
Integrating new queueing mechanism, tag like features.  Go through
setting up/using the

Bruce: Make sure when you log in things work properly, credential
expiration behaves, etc...

Kevin: When Bruce mentioned auditing code, there's also user land side
that could use review as well.

Chris: To scope the effort, are there specific areas you're worried about?
I mean other than considering all input hostile, and making sure no
tainted data is trusted without sanity checking...

Bruce: net/sunrpc/auth_gss, for example.

Kevin: Keyring code

Chris: David Howell's code?

Kevin: yes

Bruce: nfs4xdr.c (both client and server, i.e. fs/nfs/ and fs/nfsd/)

Ed: How much peer review (arch and design review)?

Kevin: rpcsec_gss is ietf, so it's got decent peer review

Ed: separtion of state between different users?

Bruce: state code on client and server is fairly complicated

Ed: state machine or nested ifs?

Mary: does implementation make a difference for security?

Ed: yes, complex code is harder to verify security-wise

Mary: which is more complex?

Ed: deeply nested complex if/statements

Bruce: on server side it's synchronous, thread based

Ed: ah, shared thread pool, servicing requests

Bruce: client side is more async, much is done in current context, then
per-cpu threads

Ed: access controls for server enforced by nfs server itself?  or
basically setuid on the thread.

Bruce: latter.  get an rpc request, do some crypto, this is for kerberos
cred, lookup user, changes uid.

Mary:  is that good or bad?

Ed: that's good, it keeps them from re-implementing access control
internally.

Mary: three levels of security in paper, are there use cases?  seems
intent is for across internet connection, is that normal use case?

Ed: is that a proxy for saying it needs to work for NAT?

Bruce:  1) auth only (signs just header), 2) integrity (whole request)
3) privacy (data as well)

Ed: auth only, trusted cluster, no hostile users, 2) intranet, within
company, auth and integrity to make sure payload isn't manipulated
man-in-middle attacks 3) encypting data for confidential data

Mary: so privacy level for internet type connection (perf issue)

Ed: more in terms on server loading

Ed: is protocol NAT safe?

Bruce: yes, i use it at home.  delegations need callbacks, and callbacks
don't work with NAT.

Ed: no passive mode?

Bruce: no, there should be, and working group is taking it on.

Ed: auth, rpcsec does all authentication

Bruce: could require more complicated protocols on server side (ldap,
etc.)

Bruce: groups and uids are arbitrary length strings.

Mary: because earlier versions of nfs aren't secure, are there
certifications that nfsv4 will need to pass.

Ed: encryption could fall into FIPS-140 crypto cert. (could be
desirable for some customers)

Mary: distro only?

Ed: it's a function of the crypto libraries and algo's. so to extent
that it's using kerberos with AES or 3DES could be looked at.

Bruce: we use two different implementations DES (user and kernel)

Ed: same as ipsec? and what else besides

Bruce: DES is all we support now, that needs to change.

Dan:  CC needs more than FIPS.  design docs, function tests, etc.  And
other bits, like client caching (no bleeding to other clients), object
re-use (zero buffers before re-use).  access control...

Ed: Documentation set that SuSE or RH would need to include NFSv4 in CC
EAL4 level cert?

Dan: Functional spec (define interfaces), then focus on security
enforcing interfaces and extensively test those interfaces.

Dan: security target hasn't included nfs in past.

Ed: either reverse engineer docs, or work with citi to get docs up
front.  functional spec, high-level design, low-level design

Dan: EAL4 needs low-level design

Bruce:  quick crash course so that i can keep it in mind would be
helpful.

Ed/Dan:  all interfaces need to be documented (network interfaces and
api's)

Mary: flag security releated and have unit tests for those?

Dan: evaluation lab has done that part, but when doing the first pass
analysis, it helps to have the documented up front.

Mary: sounds like at minimum we need to flag those and have tests

Dan: yes, so all ACLs, etc.  crypto part can be considered outside of
nfsv4.

Ed: that's why you start with high-level block level design

Mary: do we have to do kerberos as well?

Dan: it's not in scope of nfsv4.

Mary: to help distros, we could do the nfsv4 testing, and distros can
add the crypto/kerberos as well?

Dan: yes

Mary: RH is shipping nfsv4, does it need evaluation

Chris: but it's not part of security target for evaluation

Matt: if you've not got the data going into it

Mary: all our customers are saying they want nfsv4 because of security

Chris:  that's not for evaulation purpose, that's because nfsv2/3
functionally provide no

Chris: server side requirement, and not specified in protocol

Bruce: true, but vendors are generally turning it on for v2/3

Mary: outside of certifications, and tests needed for that, other
classes of testing that we need to drill down on.  Is performance an
issue?

Ed: not from security perspective, unless you are considering DoS.  so
scaling testing is helpful.

Dan: certifications that we've done, DoS is not in scope.

Ed: right, just enterprise data center usage

Bruce: we do care that perf. regressions aren't so large to make it
unsuable, and doesn't get deployed.

Mary: do we have a hacker day?  invite whitehats to hack on it?

Ed: well, we're relying on crypto layer for man-in-middle type of
attacks.

Ed: has xdr been well-exercised in the face of buffer attacks?

Ed: NISCC has programs that help tackle these issues, perhaps useful
here

Chris: DCL/CGL...

Ed: Guilty as charged... ;-)

Joseph:  f2f is effectively rubber stamping for full review which is in
two weeks.

Matt: i have some comments/nits/additions for the docs, can get them out
shortly

Mary: i'd like to have milestone report to have for f2f.  What can we
aim at for the f2f?

Ed: Will be back home next week and buckle down to get some docs out.

Mary: loved the start...probably need to look at plan for having it done

Chris: NFSv4 will drop on floor if we don't scope things and set up
some plan.  What's our next step.

Mary: detail work and set priorities based on bryce's matrix, take each
line in matrix and get assigned to details.  bring back spreadsheet to
this group.

Chris: ok, so we'll wait to see the matrix and then sanity check and
work on allocating resources.

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



More information about the security_sig mailing list