[cgl_discussion] Re: Latest version of security requirements document

greg k-h greg at kroah.com
Wed Oct 23 21:54:00 PDT 2002


On Tue, 22 Oct 2002 12:41:27 -0700, Makan Pourzandi (LMC) wrote:
> 
> Feel free to comment on the document.

Here's a few comments from someone outside the CGL group, take them as
you may:

I'm only commenting on the sections with "Priority 1" as those seem like
the best described ones:

Section 4.1: MAC
	- the LSM project is not "an existing solution implementing MAC in a
	  flexible way outside the Linux kernel".  LSM only provides the
	  hooks that you could then use to create a MAC implementation
	  within the kernel.  It does not provide anything at all.
	- There is also a 2.4 version of the LSM patch, if CGL is going
	  to stick with that.
	- Personally I would not recommend the LIDS project to run on
	  any CGL type machine.  If you take a look at the code, you
	  will see why.
	- Why not mention Ericsson's LSM based project (sorry, can't
	  remember the name right now.)  Isn't it also open source?
	- Stating that MAC is a "requirement" is pretty strong.  I like
	  it :)

Section 4.2: Digital signatures
	- You missed the CrytoMark Project:
		http://www.immunix.org/cryptomark.html
	  There was a USENIX paper based on it, but I can't remember the
	  date, sorry.
	  I've also published a 2.4 version of the code, which can be
	  found at:
		http://linuxusb.bkbits.net:8080/cryptomark-2.4
	  I can bring it up to date with the most recent 2.4 kernel
	  quite easily, and probably port it to the LSM interface if
	  people really care.
	  But in the end, I would not recommend this, it's a nice
	  research project, but I think I proved quite well that GPG
	  does not belong in kernelspace (too big, and too slow.)
	  Changing the crypto to use OpenSSL is a much better idea
	  (which I think WireX is working on, but am not sure.)
	- as this is a "priority 1" requirement, who is going to put the
	  resources on actually implementing this in a sane manner?
	- What is the time frame for creating and integrating this
	  requirement?
	- and finally, are people going to be willing to accept the
	  speed slow down this feature would cause to their OS?  I know
	  the document mentions "doing this in the background", do you
	  have any design documents on how this would be successfully
	  done without ever running a invalidly signed program?

Section 4.3: IPSec
	- You might want to take a look at the new crypto code going
	  into the 2.5 kernel tree next week.  I think it will provide
	  another implementation outside of the FreeSWAN project for
	  this feature.
	
thanks,

greg k-h





More information about the cgl_discussion mailing list