On Tue, 3 Apr 2012, William Heinbockel wrote:
On Tue, Apr 3, 2012 at 1:23 PM, <david(a)lang.hm> wrote:
> On Tue, 3 Apr 2012, William Heinbockel wrote:
>
>> I just updated the Lumberjack Field List on the wiki to start unifying
>> the field names based on the nxlog, libumberlog, and some of the
>> auditd fields.
>>
>> I tried to keep the list minimal and have at least enough support for
>> syslog compatibility.
>>
>> <
https://fedorahosted.org/lumberjack/wiki/FieldList>
>
>
> knee jerk reactions
>
> I don't think that there should not be an endtime tag as such, it's not very
> common (apps are about as likely to have time + duration as start + end)
Not all events are instantaneous.
We should support at least one of the two, if not both (time+dur or end-start)
>
> I repeat my arguements (by reference to save space :-) that we should not
> have srcIP, dstIP, etc instead we should have src: {ip:}, dst: {ip:}
> instead.
Need to roll this into the namespace and field structure conversation
-- how do we utilize the structure?
You seem to favor more of an OO approach; I prefer to keep things flat
the problem with keeping things flat is that the permutation of all
contexts and all field types results in such a long list of possible
values that the programmer's eyes will glaze over just seeing the size of
the list and the chance of them picking the right one are low.
For your approach, we would need a src and dst structure which is no
big deal.
However, there would be no easy way to limit or enforce the contents
of those structures.
I don't understand why there would be a problem enforcing the context of
structures any mroe than there would be of enforcing flat names?
I wonder if there is a hybrid approach here. We could organize the
atomic fields by object/structures in addition to some "core" fields.
What I do not want to see are fields like "ipv4" that appear without
any context.
I agree, everything needs to have some context, I just think that it
should be based on structure rather than just name.
part of this goes back to the type discussion, using fewer names results
in fewer type definitions (partially offset by the need to define
structures)
> login events should not have a separate user loginuser field,
they should
> re-use the user name. There are many cases where we may want to know the
> user that is requesting something, the user being affected by a change, etc.
> we don't want to end up creating lots of different *user tags to cover all
> of these, instead have one user tag and use the structure to indicate when
> it's the metadata for the running process vs something relavent at the
> application level
>
The context needs to be maintained -- either through field names or structure
I agree with you in general, though I disagree with the specifics for
login events.
User generally relates to a specific user account. In the case of
login, you are providing a name that may or may not coincide with an
account.
We need a way to search for "attempts to login as user *" versus
"events performed as user *"
In these situations "user" has different contexts
and sometimes you want to see anything related to the user, login attempts
or actions after logging in.
which is easier to do, get a complete list and then narrow it based on
fields in the messages (filter out login attempts), or combine several
lists that are each part of the data?
My heartache with the second approach is how do you make sure you have
included all the possible fields? If the list of possible fields is large,
it's very hard to be sure.
As a result, I like the first approach.
Along similar lines, in security I frequently want to find all instances
of an IP address, I don't care if it is the source, the destination, the
proxy, or something else. having IPv4 in several structure based contents
should let me find it much more easily than having to figure out all the
field names that it may be and searching across all of them.
> similar objections to LSPP adding new uid and gid fields, ui/gid
may be part
> of the running process metadata, file permissions, lspp log, etc. re-use the
> same tag and let the structure identify the different contexts rather than
> encoding the context in the field name.
>
This will work if there is an "lspp" structure that contains the
subject, object, object uid/gid fields.
lspp should probably be combined with selinux, apparmor, and other
security frameworks into some normalized, common definition, and then
there may need to ba a 'native' object to contain the specific details
(very similar to the severity/facility discussion)
David Lang