[Security_sig] [Reminder] Security SIG conf. call - 1/20
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.
- 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.)
- Page 8 (O.DENIAL-SOPHISTICATED)
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
- 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
- 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.
Open Source Development Lab
CGL - Roadmap Coordinator
More information about the security_sig