Security testing

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Fixing some spelling/grammar)
 
Line 17: Line 17:
* to list all NFS functions that could be used in a different way than designed
* to list all NFS functions that could be used in a different way than designed
* to be sure data sent by a modified client / server could not be used to access a server/client (for example : can anyone modify delegated data to create a problem on the server? )
* to be sure data sent by a modified client / server could not be used to access a server/client (for example : can anyone modify delegated data to create a problem on the server? )
 +
 +
 +
Security testing tools:
 +
http://www.opensourcetesting.org/security.php

Latest revision as of 04:29, 11 April 2006

There are mainly two way to view security on NFS :

  • Functionality of security components: kerberos, spkm, lipkey ...
  • Trust of NFSv4, with or without security components.

Each Security components (such as kerberos) should its own independant section. This section is on the second part : how can we be sure NFSv4 is secure. For now this page is mainly a reflection around this subject.

As far as I know there is one generic attack from a remote machine to a server. It uses buffers overflow/underflow to set excecutable code on the stack.

Others attacks are not generic, each attack depend on the imagination of the cracker :

  • to use a function in a different way than the function was designed.
  • to imitate the client or the server with a modified one.

In order to avoid security holes we need :

  • to be sure the size of each buffer is checked
  • to list all NFS functions that could be used in a different way than designed
  • to be sure data sent by a modified client / server could not be used to access a server/client (for example : can anyone modify delegated data to create a problem on the server? )


Security testing tools: http://www.opensourcetesting.org/security.php

Personal tools