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

John Cherry cherry at osdl.org
Thu Jan 20 11:17:28 PST 2005

Comments on the CGL Security Requirements Definition - v3.1

Ge and Joseph, the first draft of this document is very good and the
organization of the document is very logical.  We will be able to use
this as the basis for discussion at the CGL f2f meetings.

General comments
  - We should merge the CGL security (draft) with this requirements
    document, since the assumptions in the CGL security document are
    referenced in the requirements document.
  - Since several of the requirements are dependent on how applications
    use them (as we discussed in the meeting this morning), we should
    add a best practices section or a security guidelines section at
    the end of this document.  Topics such a creating a secure physical
    environment, configuring applications in a chroot/jail/selinux
    environment, setting up secure authentication, etc. would be

Topics for CGL f2f
  - Security objectives that are NOT met by the requirements
  - Requirements that do not relate directly to existing security
    objectives (i.e. authentication, log analysis, etc.)

    Clustering will not address most DOS attacks, especially in cluster 
    configurations where the DOS mechanism is distributed across the

  - Page 9 SEC.1.1
    Generic Kernel Security Modules -> Dynamic Security Module Mechanism
    The requirement is not for generic security modules, but for a
    mechanism to support the dynamic loading of modules which implement
    some security control policies.

  - Page 9 SEC.1.2
    Split this into two requirements.  The first could be met by a
    generic containment mechanism such as chroot or jail.  The second
    by MAC-based systems such as SELinux.  We may also want to consider
    tools which could be run to determine process containment attributes
    for MAC-based systems.

  - Page 10 SEC.1.4
    There is something odd about a requirement that describes
    capabilities specified in the withdrawn POSIX 1003.1e draft.  Could
    we just describe the "functionality" that is required?

  - Page 10 SEC.2.0
    Description could be something like: OSDL CGL specifies that carrier
    grade Linux shall provide secure authentication and the ability to
    apply new authentication mechanisms.

  - Page 11 SEC.2.1 and SEC.2.2
    To be consistent with LSM, describe the infrastructure first
    followed by the modules.  Essentially, switch the order of SEC.2.1
    and SEC.2.2.

  - Page 12 SEC.3.2
    Log Information Confidentiality and Integrity --> Secure Transport
    of Log Information.  Just a more descriptive title for the 

  - Page 13 SEC.3.3 and SEC.3.4
    Change Names to:
        SEC.3.3 Periodic Automated Log Analysis
        SEC.3.4 Real Time Automated Log Analysis

  - Page 14 SEC.4.1
    Even though the network confidentiality and integrity provided by
    IPv6 is already manditory, this requirement should cover both IPv4
    and IPv6.

  - Page 16 SEC.6.0 and SEC.6.1
    SEC.6.1 is the only subrequirement for SEC.6.0.  Should we combine

  - Page 16 SEC.7.0 and SEC.7.1
    Same thing.  Should we combine them?

  - Page 17 SEC.8.0 and SEC.8.1
    Same thing.  Shoule we combine them?

  - Page 18 Section 3
    Should say Security Roadmap (cut and paste problem)

  - Page 18 Appendicies
    References are redundant to those at the beginning of the document
    and the ones in A.2 do not appear to be security related.

John Cherry
Open Source Development Lab
CGL - Roadmap Coordinator

More information about the security_sig mailing list