Assurance measures: ADV (what we are really bad at)
Hi!
The saga continues. Now we look at the development assurance
measures. Unfortunately this part is where open source is
not good at (not saying that closed source is better).
This is because writing documentation is quite
boring, and ADV is about writing design documentation.
I personally think that the mental activities behind this
assurance class are done in most part, and most of the
information is available scattered throught mailing lists
and documentations. Also, the code speaks for itself:)
Unfortunately this is not an excuse.
I would be happy to find that my assumptions are false, so
feel free to correct me.
I will only list requirements corresponding to EAL3 where
they are not easily met.
ADV_FSP.1 Informal functional specification (EAL1-3)
ADV_FSP.1.1D The developer shall provide a functional specification.
(Well, this is lacking for the distribution as a whole,
and for most of the packages.)
ADV_FSP.1.1C The functional specification shall describe the TSF and
its external interfaces using an informal style.
(The trusted security functions aren't identified.
However if they would be identified, the corresponding manpages
would more than suffice.)
ADV_FSP.1.2C The functional specification shall be internally
consistent.
(I think the manpages meet this)
ADV_FSP.1.3C The functional specification shall describe the purpose
and method of use of all external TSF interfaces, providing
details of effects, exceptions and error messages, as
appropriate.
(Also, man pages meet this)
ADV_FSP.1.4C The functional specification shall completely represent
the TSF.
(If we would know what the TSF is...)
ADV_FSP.2.5 is EAL4, and more with the following requirement:
ADV_FSP.2.5C The functional specification shall include rationale
that the TSF is completely represented.
(I guess it would be easy to do if we could define the TSF).
ADV_HLD.2 Security enforcing high-level design (EAl3, EAL4)
ADV_HLD.2.1D The developer shall provide the high-level design of the
TSF.
(Some packages have developers' guide. Some don't. Those
which have may or may not give an appropriate high level
design.)
ADV_HLD.2.1C The presentation of the high-level design shall be
informal.
(well, if they have, it is informal)
ADV_HLD.2.2C The high-level design shall be internally consistent.
(sometimes...)
ADV_HLD.2.3C The high-level design shall describe the structure of the
TSF in terms of subsystems.
(some do, some don't)
ADV_HLD.2.4C The high-level design shall describe the security
functionality provided by each subsystem of the TSF.
(maybe pam does this, rsbac and selinux does this,
others don't I'm afraid)
ADV_HLD.2.5C The high-level design shall identify any underlying
hardware, firmware, and/or software required by the TSF
with a presentation of the functions provided by the
supporting protection mechanisms implemented in that
hardware, firmware, or software.
(the identification is done in the dependencies. the
presentation of supporting protection mechanisms is
very rare.)
ADV_HLD.2.6C The high-level design shall identify all interfaces to the
subsystems of the TSF.
(back to man pages. I think it is in better shape than the
other parts)
ADV_HLD.2.7C The high-level design shall identify which of the
interfaces to the subsystems of the TSF are externally visible.
(if the interfaces are described, it most probably does)
ADV_HLD.2.8C The high-level design shall describe the purpose and method
of use of all interfaces to the subsystems of the TSF, providing
details of effects, exceptions and error messages, as
appropriate.
(some do, some don't)
ADV_IMP.2 Implementation of the TSF (EAL5)
(Yes, we are good at it. This is what open source is about.)
ADV_IMP.2.1D The developer shall provide the implementation
representation for the entire TSF.
(Use the source, Luke!)
ADV_IMP.2.1C The implementation representation shall unambiguously
define the TSF to a level of detail such that the TSF can be
generated without further design decisions.
(run debuild, and do not think even a bit:)
ADV_IMP.2.2C The implementation representation shall be internally
consistent.
(It would not compile othervise. Okay, some packages need
code cleanup.)
ADV_IMP.2.3C The implementation representation shall describe the
relationships between all portions of the implementation.
(The Depends: et al control fields)
ADV_IMP.3, which is EAL7, is more with:
ADV_IMP.3.4C The implementation representation shall be structured into
small and comprehensible sections.
(I don't know if having several packages or having several
source files in packages counts as an answer to it.)
ADV_INT.1 Modularity (EAL5)
(If we take packages as modules, we are good at it. I would not say
the same for modules of all packages though.)
ADV_INT.1.1D The developer shall design and structure the TSF in a
modular fashion that avoids unnecessary interactions between
the modules of the design.
(This is a practice of open source developers. We could not
work otherwise.)
ADV_INT.1.2D The developer shall provide an architectural description.
(some do, some don't)
ADV_INT.1.1C The architectural description shall identify the modules of
the TSF.
(some don't, some don't)
ADV_INT.1.2C The architectural description shall describe the purpose,
interface, parameters, and effects of each module of the TSF.
(manpages)
ADV_INT.1.3C The architectural description shall describe how the TSF
design provides for largely independent modules that avoid
unnecessary interactions.
(some do, some don't)
ADV_RCR.1 Informal correspondence demonstration (EAL1-4)
ADV_RCR.1.1D The developer shall provide an analysis of correspondence
between all djacent pairs of TSF representations that are
provided.
(It should not so hard, but don't know what counts as analysis
of correspondence. Should look it up in CEM.)
ADV_RCR.1.1C For each adjacent pair of provided TSF representations,
the analysis shall demonstrate that all relevant security
functionality of the more abstract TSF representation is
correctly and completely refined in the less abstract TSF
representation.
(hmmm.)
--
GNU GPL: csak tiszta forrásból
Reply to: