[Security_sig] 4/14 Conf. call minutes
chrisw at osdl.org
Thu Apr 14 10:31:11 PDT 2005
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)
- NFSv4 security discussion
- CGL security spec
- DCL security spec
- any other business
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)
Mary: Effort to drum up folks that can help with the NFSv4 security
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?
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
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
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,
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
Ed/Dan: all interfaces need to be documented (network interfaces and
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
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?
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
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
Ed: has xdr been well-exercised in the face of buffer attacks?
Ed: NISCC has programs that help tackle these issues, perhaps useful
Ed: Guilty as charged... ;-)
Joseph: f2f is effectively rubber stamping for full review which is in
Matt: i have some comments/nits/additions for the docs, can get them out
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
Chris: ok, so we'll wait to see the matrix and then sanity check and
work on allocating resources.
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
More information about the security_sig