[osiris-devel] 3.0 features

[Alexei_Roudnev]

I agree with an idea, but I do not like a method.

1) Why do not allow to specify 'COMPARE' mode for ANY file, so that system
compare files line by line,if checksum changes, and reports a 'diff'. We
have a lot of such files:
- groups
- shadow
- password
- tacacs_plus.conf
- Apache/passwd
etc etc

So, an idea to have a specific commands, such as 'monitoring user details'
looks very bad; it is much better tospecify something like:

 set details_maximum 2000 (means that if file is longer than 2000 lines, it
is not monitored in detail mode).

 monitor details USERS     "/etc/passwd" "/etc/shadow"
 monitor details GROUPS "/etc/group"
 monitor details TACACS "/etc/tac_plus/tac_plus.conf"

meaning that first word is just report identifier, and then I can specify a
list of files, which will be compared 'line by line' .
May be, users/ groups should be exception, because they are an exception in
Windows.

For Windows, it is better to specify a registry as a 'files', and use
standard syntax (as it was done in Tripwire), using special prefix (instead
of C:, D: they use HKEY_USER: or HKEY_LOCAL: etc...) and reuse 90% of the
scanner code.

2) I recommend to create a <System> block. Reason is simple. I am 100% sure,
that you will allow to specify different notification e-mails in some future
(as it is implemented in tripwire), because it is inevitable - if I scan the
whole system, I have a different people to be notified, if application
changes (it is application engineer) or if system directory changes (it is
security officer) or if password file changed (it is account manager). I do
not intend to implement it just now, BUT having specific block allows to
group scans into the groups and add options into the block.
If you use this commands outside of ANY block, you can not apply any options
to thic command (except global options, which is not a good idea).

Other option is to allow this commands inside any block.

But see _1_ - I do not like the whole idea. For password and group scan, we
do not need separate commands, we just need 'diff' (detail) mode for this
files. I have another (that passwd / group) files here, so I can not use
'monitor users' in some cases (and my FreeBSD is doing it all for me - scans
aliases and passwd and report me all changes every day).

For Windows, it is appliable - users and groups are not a files, so it is
very useful to have embedded commands.


----- Original Message ----- 
From: "Brian Wotring" <brian at shmoo.com>
To: "Osiris Developers" <osiris-devel at lists.shmoo.com>
Sent: Wednesday, December 31, 2003 2:53 PM
Subject: [osiris-devel] 3.0 features


>
> 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 at shmoo.com )
>      PGP KeyID: 0x9674763D
>
> _______________________________________________
> osiris-devel mailing list
> osiris-devel at lists.shmoo.com
> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>