[redhat-lspp] LSPP work items

[George Wilson]

On Wed, 2005-10-05 at 10:08 -0500, serue at us.ibm.com wrote:
> Quoting Steve Grubb (sgrubb at redhat.com):
> > On Tuesday 04 October 2005 23:11, James Morris wrote:
> > > > 3 Kernel - Audit related
> > > > 3.1 Create new audit record types for: rlimit violations, lspp subject,
> > > > lspp object, crypto, anomolies, and response to anomolies.
> > >
> > > What do you mean by crypto here?
> > 
> > I am wanting to start getting the hooks in place for Medium Robustness. It 
> > says: Cryptography Admin role shall exist, Anything that inits the crypto, 
> > changing any of its params, algorithm modes, and selection of the algorithm 
> > shall require Crypto Admin role.
> 
> Given that linux can't meet mrmlospp (iiuc), are you just planning on
> meeting whatever requirements are possible, or do you have some other
> Master Plan?
> 
> Don't get me wrong, I'm all for a crypto admin role, I'm just wondering
> what the long term plans are.
> 
> thanks,
> -serge
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
> 

Decomposing administrative roles is a generally a good thing where we
can do so meaningfully.  And no doubt certain MLOSPP features, such as
trusted path, would be useful to have on an MLS system.  But if I read
MLOSPP correctly, it isn't easily achievable without meeting onerous
FIPS crypto requirements and adding integrity labels.  Moreover, the new
draft is not yet complete and validated.  I'm not convinced that it is
worthwhile to make numerous changes to meet additional requirements if
that work diverts our energy from meeting LSPP/RBACPP in the nearterm.
I'm not saying we should box ourselves in.  It is desirable to meet
LSPP/RBACPP with an eye toward the future.  However, let's please not
take on too many requirements for a protection profile that is in
motion, very difficult to meet, and not our current goal.

-- 
George Wilson
IBM Linux Technology Center
<ltcgcw at us.ibm.com>