[cgl_discussion] Re: Latest version of security requirements document

[Makan Pourzandi (LMC)]

Hi Greg, 

Thanks for your comments, I believe that it's a good thing that we have
input from different people on this docuemnt. Definitely, there is much that
needs to be done to have a reliable set of requirements. 

See my comments in the text:  

>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.

100% right, it seems that I made a mistake. I am going to correct that. For
me, LSM and MAC are so closely tied together that I missed to show the
difference. I'll rephrase the whole thing. 

>	- 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.

I believe this is a very valid comment. For time being, we only try to
enumerate different projects. Later, we'll choose the valid candidates. 

>	- Why not mention Ericsson's LSM based project (sorry, can't
>	  remember the name right now.)  Isn't it also open source?
>
Well, the name is DSI and it is open source (sorry, shameless advertisement:
www.linux.ericsson.ca/dsi, I am the responsible of the project). Ericsson's
LSM module, called DSM - for time being - concerns mainly network operations
and processes access priviledges/transitions. There will be another release
of DSM by December this year, but we don't go further than networking,
specially file system MAC is missing and I don't plan to do it for near
future. BTW, many nodes in Telecom servers are diskless. I am going to add
it into the list, becasue we only enumerate different projects for now. 

>	- Stating that MAC is a "requirement" is pretty strong.  I like
>	  it :)

I consider splitting requirement into 2: one requirement regarding LSM and
one requirement regarding MAC module. Any comment on this? 


>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.)
>
Thanks for the info, I'll add the project into the list. 

Am I right to believe that you want to have digital signature in kernel
space for all binaries as a must? I don't believe that we wrote that the
digital signatures must be verified at kernel level for all binaries.
Actually, there are different possible solutions with different degrees of
security. For example, one easy solution is that digital signatures can be
verified as a cron task for all binaries (i.e. when the server's load is low
and at user level, background task), and alarms sent if any invalid
signature detected. This can be implemented using tripwire for example.
Notice that we are talking carrier-grade server, we do not talking about
wild downloads from web and binaries installed or updated every day.
Generally, the binaries on these servers change slowly compared to many
other servers. As a first step, it seems to me that this solution is
accpetable. 

On the other hand, one step further can be to verify the signatures only
when we load a binary from hard disk for the first time and not verifying
the signatures when forking.Once more, my understanding from a carrier-grade
server is that the server does not run a wide range of binaries but rather a
limited number of binaries, this is a dedicated machine to run only one or
few applications. 

Perhaps more on this when I read the paper you mentioned above. 


>	- 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?

c.f. my comments above. If we use a step wise approach, we can implement an
easy solution using the existing open source projects for the first
releases. Later on, we can complete that solution. what do you think about
this approach? 

>	- 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?
>
I believe you have a very important issue here. There is a price to pay for
security. 
IMO, some issues are to take into account: 

-  There is a cost from extra devlopment time, to longer reposne time,
etc... IMHO, till the hardware crypto becomes part of commodity CPUs, there
will be always a slow down when turning the security on. we need to convince
the marketing/sales people to accept this. Till the moment, that the clients
don't want to pay for security, it is hard to make marketing/sales people to
accept this. Things budge slowly, and definitely there is more and more
attention paid to security. 

- we need to make security mechanisms flexible, providing different security
levels to allow the client to choose its security level (meaning the client
chooses/accepts the tradeoff between security and cost according to his
needs). Not everybody wants the security or willing to pay for it, on the
other hand there are people willing to pay for securing all or parts of
their communications. 

>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, sure I'll monitor this. 

Regards,
Makan