Security testing

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Fixing some spelling/grammar)
Line 1: Line 1:
-
There are mainely two way to see security on NFS :
+
There are mainly two way to view security on NFS :
-
*Security functionnalities and components : [[kerberos]], [[spkm]], [[lipkey]] ...
+
* Functionality of security components: [[kerberos]], [[spkm]], [[lipkey]] ...
-
*Knowing if we can trust on NFSv4, with or without security components.
+
* Trust of NFSv4, with or without security components.
Each Security components (such as kerberos) should its own independant section.
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''.
This section is on the second part : ''how can we be sure NFSv4 is secure''.
-
For now this page is mainely a reflexion around this subject.
+
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.
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 generics, each attack depend on the imagination of the cracker :
+
Others attacks are not generic, each attack depend on the imagination of the cracker :
-
*to use a function in a different way the function was designed.
+
*to use a function in a different way than the function was designed.
-
*to imitate the client / the server with a modified one.
+
*to imitate the client or the server with a modified one.
-
In order to avoid securities hole we need :
+
In order to avoid security holes we need :
* to be sure the size of each buffer is checked
* to be sure the size of each buffer is checked
-
* to list all NFS functions that could be used on a different way there was 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 modifie delegated datas 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? )

Revision as of 20:00, 18 May 2005

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? )
Personal tools