[Security_sig] [Reminder] Security SIG conf. call - 1/20

Cihula, Joseph joseph.cihula at intel.com
Fri Jan 21 13:23:34 PST 2005

My comments: 

>-----Original Message-----
>From: security_sig-bounces at lists.osdl.org 
>[mailto:security_sig-bounces at lists.osdl.org] On Behalf Of 
>Makan Pourzandi
>Sent: Friday, January 21, 2005 12:56 PM

>SEC 1.1:
>Should we still keep this requirement? LSM is already in all 2.6.X
>kernels. Sorry for my naive question, do we expect CGL 3.0 to run on
>any 2.4.X kernel?

I had similar confliction but when I asked internally it was pointed out that similar situations exist for requirements in some of the other specs and that it is best to keep it as a requirement until it is very obvious that the support is available by default (specifically, I was given the example that MV CGE 3.0  is 2.4 based).

>SEC 3.1, 3.2
>Objectives Satisfied: None
>Should we replace None by O.OBSERVE-TOE?

Agreed.  Some of the sub-item objectives were left off simply for time reasons.

>SEC 3.3:
>Should we replace None by  O.DETECT-SOPHISTICATED?
>SEC 3.4:
>Idem as above.



>SEC 7.1:
>Can somebody please elaborate on this? I'm a little confused.

Section 7.0 is meant to satisfy the resource control objective.  7.1 addresses the file system aspect of this (may seem unnecessary, but see previous comment about LSM).  Ge will be adding another requirement about VM limits.  Granted these are incomplete mitigations but they provide a good first step to satisfying the objective.

>SEC 8.1:
>I have a possible reference:
>Marcel Selhorst, Christian Stueble,  "Linux Kernel Module for the
>Infineon Trusted Platform Module SLD 9630 TT",

This was intentionally left blank ;-) because it refers to the Hardware spec header requirement and we didn't want to duplicate any of the info.  Appendix A of the HW spec lists TPM references.  However, it doesn't reference this and so this would be good to get added to the HW spec (perhaps for the 3.1 version).


Thanks for the comments.

Joseph Cihula
(Linux) Software Security Architect
Intel Corp.

*** These opinions are not necessarily those of my employer ***

More information about the security_sig mailing list