summaryrefslogtreecommitdiff
path: root/source3/modules/vfs_smb_traffic_analyzer.c
diff options
context:
space:
mode:
Diffstat (limited to 'source3/modules/vfs_smb_traffic_analyzer.c')
-rw-r--r--source3/modules/vfs_smb_traffic_analyzer.c126
1 files changed, 12 insertions, 114 deletions
diff --git a/source3/modules/vfs_smb_traffic_analyzer.c b/source3/modules/vfs_smb_traffic_analyzer.c
index 4465425927..7d7332e1b9 100644
--- a/source3/modules/vfs_smb_traffic_analyzer.c
+++ b/source3/modules/vfs_smb_traffic_analyzer.c
@@ -21,123 +21,13 @@
#include "includes.h"
#include "../lib/crypto/crypto.h"
+#include "vfs_smb_traffic_analyzer.h"
/* abstraction for the send_over_network function */
enum sock_type {INTERNET_SOCKET = 0, UNIX_DOMAIN_SOCKET};
#define LOCAL_PATHNAME "/var/tmp/stadsocket"
-
-/**
- * Protocol version 2.0 description
- *
- * The following table shows the exact assembly of the 2.0 protocol.
- *
- * -->Header<--
- * The protocol header is always send first, and contains various
- * information about the data block to come.
- * The header is always of fixed length, and will be send unencrypted.
- *
- * Byte Number/Bytes Description
- * 00-02 Contains always the string "V2."
- * 03 This byte contains a possible subrelease number of the
- * protocol. This enables the receiver to make a version
- * check to ensure the compatibility and allows us to
- * release 2.x versions of the protocol with bugfixes or
- * enhancements.
- * 04 This byte is reserved for possible future extensions.
- * 05 Usually, this byte contains the character '0'. If the
- * VFS module is configured for encryption of the data,
- * this byte is set to 'E'.
- * 06-09 These bytes contain the character '0' by default, and
- * are reserved for possible future extensions. They have
- * no function in 2.0.
- * 10-27 17 bytes containing a string representation of the
- * number of bytes to come in the following data block.
- * It is right aligned and filled from the left with '0'.
- *
- * -->Data Block<--
- * The data block is send immediately after the header was send. It's length
- * is exactly what was given in bytes 11-28 from in the header.
- *
- * The data block may be send encrypted.
- *
- * To make the data block easy for the receiver to read, it is divided into
- * several sub-blocks, each with it's own header of four byte length. In each
- * of the sub-headers, a string representation of the length of this block is
- * to be found.
- *
- * Thus the formal structure is very simple:
- *
- * [HEADER]data[HEADER]data[HEADER]data[END]
- *
- * whereas [END] is exactly at the position given in bytes 11-28 of the
- * header.
- *
- * Some data the VFS module is capturing is of use for any VFS operation.
- * Therefore, there is a "common set" of data, that will be send with any
- * data block. The following provides a list of this data.
- * - the VFS function identifier (see VFS function ifentifier table below).
- * - a timestamp to the millisecond.
- * - the username (as text) who runs the VFS operation.
- * - the SID of the user who run the VFS operation.
- * - the domain under which the VFS operation has happened.
- *
- */
-
-
-/**
- * VFS Functions identifier table. In protocol version 2, every vfs
- * function is given a unique id.
- */
-enum vfs_id {
- /*
- * care for the order here, required for compatibility
- * with protocol version 1.
- */
- vfs_id_read,
- vfs_id_pread,
- vfs_id_write,
- vfs_id_pwrite,
- /* end of protocol version 1 identifiers. */
- vfs_id_mkdir,
- vfs_id_rmdir,
- vfs_id_rename,
- vfs_id_chdir
-};
-
-/*
- * Specific data sets for the VFS functions.
- * A compatible receiver has to have the exact same dataset.
- */
-struct mkdir_data {
- const char *path;
- mode_t mode;
- int result;
-};
-
-struct rmdir_data {
- const char *path;
- int result;
-};
-
-struct rename_data {
- const char *src;
- const char *dst;
- int result;
-};
-
-struct chdir_data {
- const char *path;
- int result;
-};
-
-/* rw_data used for read/write/pread/pwrite */
-struct rw_data {
- char *filename;
- size_t len;
-};
-
static int vfs_smb_traffic_analyzer_debug_level = DBGC_VFS;
static enum sock_type smb_traffic_analyzer_connMode(vfs_handle_struct *handle)
@@ -277,13 +167,21 @@ static char *smb_traffic_analyzer_create_string( struct tm *tm, \
char *usersid = NULL;
const char *total_anonymization = NULL;
const char *anon_prefix = NULL;
+ /*
+ * first create the data that is transfered with any VFS op
+ * These are, in the following order:
+ * number of data to come [6 in v2.0]
+ * 1.vfs_operation identifier
+ * 2.username
+ * 3.user-SID
+ * 4.affected file + full path
+ * 5.domain
+ * 6.timestamp
+ */
- /* first create the data that is transfered with any VFS op */
opstr = talloc_asprintf(talloc_tos(), "%i", vfs_operation);
len = strlen(opstr);
buf = talloc_asprintf(talloc_tos(), "%04u%s", len, opstr);
- len = strlen( username );
- buf = talloc_asprintf_append(buf, "%04u%s", len, username);
/*
* Handle anonymization. In protocol v2, we have to anonymize