[cgl_discussion] Re: Latest version of security requirements document
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
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
Section 4.2: Digital signatures
- You missed the CrytoMark Project:
There was a USENIX paper based on it, but I can't remember the
I've also published a 2.4 version of the code, which can be
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
- 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
More information about the cgl_discussion