Security testing
From Linux NFS
(Difference between revisions)
m (Security tests moved to Security testing) |
(Fixing some spelling/grammar) |
||
| Line 1: | Line 1: | ||
| - | There are | + | 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. | 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 | + | 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 | + | 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 | + | *to imitate the client or the server with a modified one. |
| - | In order to avoid | + | 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 | + | * 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 | + | * 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? )
