[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osiris-devel
Subject:    [osiris-devel] 3.0 features
From:       Brian Wotring <brian () shmoo ! com>
Date:       2003-12-31 22:53:30
Message-ID: 276F6522-3BE4-11D8-BF43-000393578C14 () shmoo ! com
[Download RAW message or body]


Osiris 3.0 will contain the following added features:

- monitoring user details ( /etc/passwd file or equiv ).
- monitoring group details ( /etc/group or equiv ).
- monitoring sysctl kernel variables (sysctl).
- monitoring active kernel modules or extensions.

This list is not yet final.  The only one of these that is for-sure is 
the
user/group one.  All of the others are open for discussion and more can 
be
added.

[Reasoning]

User and Group information, kernel mods, and other system state is 
important
to monitor.  It is not sufficient to simply say "/etc/passwd" changed.  
Given
the importance of this file, it makes sense to be able to report on the
specifics of any change.  Thus, the contents of the file needs to be 
stored
and subject to periodic verification.  This will greatly improve this 
software
and allow an administrator to decide if the change warrants further
investigation, or not.

[Scan Configuration]

All of these will be specified in the scan config, thus the syntax for
the configuration will need to be extended.  These features will be 
global
config directives and depending upon which ones are actually decided 
on, here
is a sample of how they would be specified:

Include users
Include groups
Include kern_state
Include kern_mods

another alternative is to create a system block but there is no real 
advantage
other than readability:

<System>
Include users
Include groups
Include kern_state
Include kern_mods
</System>

[Storage Issues]

The scan database structure already contains a sub-database called the
"system" database.  This section of the database is currently unused and
will store all of the data related to these new features.

New scan record types will need to be defined in order to store this 
new data.
This will enable each item in the system database to be identified 
easily.

[user/group files]

The user and group information will be stored on a per-line basis.  
That is,
each line in these files will be put into a scan record and stored in 
the
system database.  There will be a scan record type for user data and 
one for
group data.  For Mac OS X, this will be somewhat of a chore since this
information is stored in NetInfo.

There are a number of ways this information could be stored in the 
database
but it makes sense to store it per-line, with the username or groupname 
as the
key. These names (not the uid/gid) are unique.

This will allow the database to be traversed and each user/group entry
quickly compared for deltas and logged.  The changes will be obvious to 
users.

For Windows, it is kind of messy.  Obviously, it makes sense to only 
deal with
local users but what attributes to store is something to be determined.

[kern mods]

Each supported system deals with these differently.  Custom modules 
will need
to be developed to obtain the list.  Like the user/group entries, each 
module
will most likely have a unique name and a list of stats.   For Windows, 
a
list of services will be stored.

[kern state]

Only certain systems support this and there are really only certain
values that will be of concern.  Of all the proposed features, this is 
the
most wonky.  It may not be worth the effort to implement.

--
     Brian Wotring ( brian@shmoo.com )
     PGP KeyID: 0x9674763D


[prev in list] [next in list] [prev in thread] [next in thread]