[redhat-lspp] Requirements gathering

[James Morris]

I'd like to kick off a more formal requirements gathering process.

It's a bit of a chicken and egg situation at the moment as we don't have 
an ST defined.

>From a high level, what we'd be looking at from the point of view of 
integrating MLS support into RHEL is to provide an MLS _capable_
distribution.

That is, enough MLS support to allow the distro to be certified LSPP/EAL4+
and also to be procurable.  Initially, we'd likely want to limit the scope
of MLS coverage to a minimal, server oriented system, suitable for
developing into guards and similar types of products.  An MLS desktop is
too far off, and we're not sure if it's something we want to get involved
at all, in any case.  We'd also like to think about SLOS and MLOS down the
track, with LSPP as a stepping stone.

We'd also want to do our development in Fedora (and are looking at 
possible ways of having MLS enabled by default in there).

The following is a list of high level requirements which we've already
gathered and discussed.  Some are requirements for Fedora adoption (which
also implies later RHEL adoption), others for LSPP, and others for
procurability.

(Note: 'updated' here means 'updated to support MLS').

1) Standard/reference MLS policy (for Fedora initially).

2) Updated SELinux system tools (e.g. runcon).

3) Updated libraries (label handling APIs, LEF glue, etc).

4) Updated OS utilities (e.g. cron).

5) Updated applications (e.g. MTA?).

6) Directory polyinstantiation (via namespaces?).

7) Labeled networking (via IPsec).

8) Polyintstantiated ports (via redirection).  Still not entirely sure how
important this is.

9) Improved SAK support.

10) Labeled printing.

11) Device allocation support.

12) Network filesystem support: not needed for LSPP but SMB probably 
useful, less complicated than NFS.

13) More direct object labeling supoprt, e.g. for network interfaces.

14) Updated audit support.

15) Better revocation (e.g. for mmap'd files).

16) Extendsion of RBAC support has been discussed.


While many of these items need to be expanded into greater detail, can we 
initially focus on gathering more requirements at this level?

Please provide input on these items and propose any which you feel may be 
missing.

I know IBM has submitted some LSPP requirements via IT.  Could they 
instead be listed here and added to this list?

Once we've captured all of the high-level components, we can drill down
and expand them out, assigning risk, importance, effort, who's responsible 
etc. and also tracing each requirement to specific LSPP or other 
specifications as needed.


- James
-- 
James Morris
<jmorris at redhat.com>