i finally got to commenting on your daemon's design. comments are below.
eventually, your syntax is too limited, but for the first version and in
order to get started and getting something fast, without having to learn
lex and yacc, go ahead with this syntax.

On Mon, 7 Aug 2000, mulix wrote:

> The daemon has two purposes in life. The first is definite, the
> latter- optional.

configuration does not need to occur via a daemon, even if we have a daemon
running. configuration would be easily done using a seperate utility, that
will invoke the ioctl() calls directly. This will enable to also
add/modify/delete filtering rules without having to re-load the full
configuration. Remember that flushing all filter rules and re-establishing
them could cause loss of some system call invocations. i would want to
be ale to add a new filtering rule to the system, without loosing 
any events while doing that.

> The daemon's _second (potential) purpose in life_: to read the output
> from the module and present it to the user. (This is assuming the
> module writes to a device files. If the module writes to syslog, the
> daemon can still be useful, by reading through the syslog entries and
> alerting the administrator in special cases)

in that case, the daemon becomes optional and not realy needed.

> -validate: only validate the config file

the gnu convention is to give options either a single-letter name (and then
you can mix several options with a single '-' flag), or use a '--' prefix
for a full-word option.

> -status: is the module loaded? potentially statistics?
> 
> 	 TODO: will module loading/ unloading be on demand, or should the
> 	 daemon handle it?

In the beginning, the daemon will complain if the module is not loaded,
and exit. In an advanced version, it'll be a user-option of whether to
autoload the module or to exit.

> 	 TODO: any other switches? what switches does inetd use?

why inetd? inetd isn't very similar to this program...

> *** Config file ***
> 
> the config file will be self documenting. any line that starts with
> '#' is a comment. field separators will be any whitespace characters.

'#' signs are probably OK. I'll also suggest supporting '//' comments,
but this is not very important.

> 	 TODO: should we have names for rules?

yes. make sure they are unique, and keep them used only in user-space.
makes the user interface easier to use.

> a rule is written like this:
> <
> 	rule_number:NUMBER       
> 	syscall_name:SYSCALL_NAME
> 	rule_name:VALUE	      #optional- should we have rule names?
> 	param_location:NUMBER operator:OPERATOR value:VALUE #optional
> 	conditional: COND				  #optional
> 	process_field:PROCESS_FIELD value:VALUE		  #optional
> 	action: ACTION					  #optional
> >

i don't like this syntax, due to it being limited. however, since it's
easier to write a parser for this one, i guess you can start with 
such a parser, and later on we'll re-write the parser to support
more flexible rules.

as for the rules, don't use '<' amd '>' signs. use '{' and '}' instead.
it'll look better to C and perl programmers.

> NUMBER: any number. TODO: should we support floating point? negative?

ofcourse. we must support any value that a system call might accept. ofcourse,
rule numbers (better call them 'rule IDs') will be only positive integer
numbers.

we should also support binary, octal and hex numbers. octal and hex as in the
C language syntax. for binary - invent something.

> 	NOTE: if we want to support rule names (which I think we
> 	should) we could have rule names in the daemon only, and the
> 	daemon-module communications will be via rule id's.
> 	 That way we avoid kernel bloat. 

not just bloat - also efficiency of lookups. i agree.

> SYSCALL_NAME: the name of the syscall.
> 
> 	TODO: where do we get an authoriative list of syscall names, so we can
> 	validate at the daemon? syscalls are platform dependent. 

there are include files containing definitions of all syscall names. that
part will be kernel-version dependant, as system calls are added to newer
kernels occasionaly.

> OPERATOR:"==", "<", ">", "=<", "=>", "!="

use '<=' instead of '=<' and '>=' instead of '=>' - like in C.

> 	TODO: any other operators?

bit-mask operations ('&', '|', '^', '!'). very usefull for checking flags.

> VALUE: for integers: numbers.
>        for text: "a quoted string".

including the ability to specify a '"' inside the quoted string - you'll need
to use an escape character for that, such as '\'. '\"' is double quotes. '\\'
is a single backslash.

>        for structures: "?????" NOT IMPLEMENTED YET
> 
>        TODO: how the hell do we do rule matching for structures? for
>        arrays?

for arrays it's probably easy. for structs - we'll need to think about this.

> COND:  "||", "&&"
>        cond specifies whether we 'and' or 'or' the different
>        conditional fields in a rule. For example, a rule with two
>        param_location fields.

if COND is a seperate line here, just use the keywords 'ANY' and 'ALL'.
it's clearer, and easier to read. Also, not a good idea to call this 'COND',
since its not a condition, but rather the manner in which all sub-conditions
are to be joined.

>        TODO: what should the default be? 

no default. this is not optional, and must be supplied for each and every
rule. defaults are a great way of breaking backwards compatibility in time,
and making it harder to read the configuration.

> PROCESS_FIELD: UID, EID, PID, PPID,
>        
>        TODO: what other fields?

look at the process structure in the kernel, and choose. for the first version,
UID, EUID, GID, EGID and COMM should suffice.

> ACTION: LOG, SUSPEND, FAIL

i thought of a new actions we'll want to support (after seeing medusa's code):
enable rule and disable rule. This is useful if for example we want to
set the following scenario: if any process opens the '/etc/passwd' file for
writing, log all operations on this file descriptor, until it is
closed.

also, you forgot the 'KILL' action.

>        default is LOG, of course. 

no, no defaults. no action -> parse error.

that's it for now.

guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

--------------11D81CE8DAFDCC065600D09D--

