AUDIT_NETFILTER_PKT message format

AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

Hi,

I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
event messages and it is not quite as straightforward as I had expected.

It is being tracked here:
	https://github.com/linux-audit/audit-kernel/issues/11
and refers to a previous posting from Mr. Dash Four from four years ago
to which there was no reply.

The example given in the tracker above for "frag=" is fairly
straightforward, but digging more, there are a number of others that are
not quite so obvious.

How many different combinations of fields is acceptable?  Can we create
new message types for each one, or is there a preferred way to indicate
which sub-type it is other than implicit from the arguments given?

Others that are straightforward:
- The first "truncated=" gets pulled in with "0".

- "mark=" gets pulled in with "0".

Ones that are not so straightforward:
- "secmark" depends on a kernel config setting, so should it always be
  present but "(none)" if that kernel feature is compiled out?

- ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
  to "(none)" to indicate that type isn't present.

- audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
  adds "ipid=", which would be set to "(none)" for ip6.

- audit_proto() pulls in "truncated=" again, then either "sport=" and
  "dport=" OR "icmptype=" and "icmpcode=".

If all fields are pulled in, we end up adding 10 fields beyond a
standard well-formed packet, and 15 beyond a truncated packet.

Note: In the cases of "mark" and "secmark" both are unions.  In the case of
"mark", I don't see a problem since it isn't conditionally compiled out
and won't be mis-interpreted.  In the case of "secmark=", it could be
mis-interpreted as offload_fwd_mark if that field is even compiled in,
but that would be addressed in the compiler directive...


One last question: Does anyone have a test suite that can generate any
or all of these types of packets?


Thanks!


- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> event messages and it is not quite as straightforward as I had expected.
> 
> It is being tracked here:
> 	https://github.com/linux-audit/audit-kernel/issues/11
> and refers to a previous posting from Mr. Dash Four from four years ago
> to which there was no reply.
> 
> The example given in the tracker above for "frag=" is fairly
> straightforward, but digging more, there are a number of others that are
> not quite so obvious.
> 
> How many different combinations of fields is acceptable?  Can we create
> new message types for each one, or is there a preferred way to indicate
> which sub-type it is other than implicit from the arguments given?

That would be preferential to swinging fields in and out. But we also don't 
want to add too many new types. If two protocols look almost identical, I'd 
try to coerce them to be the same. If adding 2 new types solves the problem 
just do it. If it takes 10, then maybe we should understand why.

> Others that are straightforward:
> - The first "truncated=" gets pulled in with "0".
> 
> - "mark=" gets pulled in with "0".
> 
> Ones that are not so straightforward:
> - "secmark" depends on a kernel config setting, so should it always be
>   present but "(none)" if that kernel feature is compiled out?

If this is selinux related, I'd treat it the same way that we do subj 
everywhere else.

> - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
>   to "(none)" to indicate that type isn't present.

"(none)" is for character fields that have nothing. Typically we set -1 for 
numeric fields that are unset. If numbers are expected, its going to get the 
strtol() treatment and "(none)" will cause a conversion error.

> - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
>   adds "ipid=", which would be set to "(none)" for ip6.

That is numeric. -1?

-Steve

> - audit_proto() pulls in "truncated=" again, then either "sport=" and
>   "dport=" OR "icmptype=" and "icmpcode=".
> 
> If all fields are pulled in, we end up adding 10 fields beyond a
> standard well-formed packet, and 15 beyond a truncated packet.
> 
> Note: In the cases of "mark" and "secmark" both are unions.  In the case of
> "mark", I don't see a problem since it isn't conditionally compiled out
> and won't be mis-interpreted.  In the case of "secmark=", it could be
> mis-interpreted as offload_fwd_mark if that field is even compiled in,
> but that would be addressed in the compiler directive...
> 
> 
> One last question: Does anyone have a test suite that can generate any
> or all of these types of packets?
> 
> 
> Thanks!
> 
> 
> - RGB
> 
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 08:55, Steve Grubb wrote:
> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> > event messages and it is not quite as straightforward as I had expected.
> > 
> > It is being tracked here:
> > 	https://github.com/linux-audit/audit-kernel/issues/11
> > and refers to a previous posting from Mr. Dash Four from four years ago
> > to which there was no reply.
> > 
> > The example given in the tracker above for "frag=" is fairly
> > straightforward, but digging more, there are a number of others that are
> > not quite so obvious.
> > 
> > How many different combinations of fields is acceptable?  Can we create
> > new message types for each one, or is there a preferred way to indicate
> > which sub-type it is other than implicit from the arguments given?
> 
> That would be preferential to swinging fields in and out. But we also don't 
> want to add too many new types. If two protocols look almost identical, I'd 
> try to coerce them to be the same. If adding 2 new types solves the problem 
> just do it. If it takes 10, then maybe we should understand why.

Ok, I'll have a go at mapping some out and see where we end up...

> > Others that are straightforward:
> > - The first "truncated=" gets pulled in with "0".
> > 
> > - "mark=" gets pulled in with "0".
> > 
> > Ones that are not so straightforward:
> > - "secmark" depends on a kernel config setting, so should it always be
> >   present but "(none)" if that kernel feature is compiled out?
> 
> If this is selinux related, I'd treat it the same way that we do subj 
> everywhere else.

Ok.

> > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
> >   to "(none)" to indicate that type isn't present.
> 
> "(none)" is for character fields that have nothing. Typically we set -1 for 
> numeric fields that are unset. If numbers are expected, its going to get the 
> strtol() treatment and "(none)" will cause a conversion error.

Ah, ok.  I certainly don't want to break the parser, so I'll use -1 or
find another way to indicate it.

> > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> >   adds "ipid=", which would be set to "(none)" for ip6.
> 
> That is numeric. -1?

Yup, 16-bit.  I'll make it -1.

> -Steve
> 
> > - audit_proto() pulls in "truncated=" again, then either "sport=" and
> >   "dport=" OR "icmptype=" and "icmpcode=".
> > 
> > If all fields are pulled in, we end up adding 10 fields beyond a
> > standard well-formed packet, and 15 beyond a truncated packet.
> > 
> > Note: In the cases of "mark" and "secmark" both are unions.  In the case of
> > "mark", I don't see a problem since it isn't conditionally compiled out
> > and won't be mis-interpreted.  In the case of "secmark=", it could be
> > mis-interpreted as offload_fwd_mark if that field is even compiled in,
> > but that would be addressed in the compiler directive...
> > 
> > 
> > One last question: Does anyone have a test suite that can generate any
> > or all of these types of packets?
> > 
> > 
> > Thanks!
> > 
> > 
> > - RGB

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 11:12, Richard Guy Briggs wrote:
> On 2017-01-17 08:55, Steve Grubb wrote:
> > On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> > > event messages and it is not quite as straightforward as I had expected.
> > > 
> > > It is being tracked here:
> > > 	https://github.com/linux-audit/audit-kernel/issues/11
> > > and refers to a previous posting from Mr. Dash Four from four years ago
> > > to which there was no reply.
> > > 
> > > The example given in the tracker above for "frag=" is fairly
> > > straightforward, but digging more, there are a number of others that are
> > > not quite so obvious.
> > > 
> > > How many different combinations of fields is acceptable?  Can we create
> > > new message types for each one, or is there a preferred way to indicate
> > > which sub-type it is other than implicit from the arguments given?
> > 
> > That would be preferential to swinging fields in and out. But we also don't 
> > want to add too many new types. If two protocols look almost identical, I'd 
> > try to coerce them to be the same. If adding 2 new types solves the problem 
> > just do it. If it takes 10, then maybe we should understand why.
> 
> Ok, I'll have a go at mapping some out and see where we end up...
> 
> > > Others that are straightforward:
> > > - The first "truncated=" gets pulled in with "0".
> > > 
> > > - "mark=" gets pulled in with "0".
> > > 
> > > Ones that are not so straightforward:
> > > - "secmark" depends on a kernel config setting, so should it always be
> > >   present but "(none)" if that kernel feature is compiled out?
> > 
> > If this is selinux related, I'd treat it the same way that we do subj 
> > everywhere else.
> 
> Ok.
> 
> > > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set them
> > >   to "(none)" to indicate that type isn't present.
> > 
> > "(none)" is for character fields that have nothing. Typically we set -1 for 
> > numeric fields that are unset. If numbers are expected, its going to get the 
> > strtol() treatment and "(none)" will cause a conversion error.
> 
> Ah, ok.  I certainly don't want to break the parser, so I'll use -1 or
> find another way to indicate it.
> 
> > > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> > >   adds "ipid=", which would be set to "(none)" for ip6.

I assume that v4, v6 and mac address fields count as text?

> > That is numeric. -1?
> 
> Yup, 16-bit.  I'll make it -1.
> 
> > -Steve
> > 
> > > - audit_proto() pulls in "truncated=" again, then either "sport=" and
> > >   "dport=" OR "icmptype=" and "icmpcode=".
> > > 
> > > If all fields are pulled in, we end up adding 10 fields beyond a
> > > standard well-formed packet, and 15 beyond a truncated packet.
> > > 
> > > Note: In the cases of "mark" and "secmark" both are unions.  In the case of
> > > "mark", I don't see a problem since it isn't conditionally compiled out
> > > and won't be mis-interpreted.  In the case of "secmark=", it could be
> > > mis-interpreted as offload_fwd_mark if that field is even compiled in,
> > > but that would be addressed in the compiler directive...
> > > 
> > > 
> > > One last question: Does anyone have a test suite that can generate any
> > > or all of these types of packets?
> > > 
> > > 
> > > Thanks!
> > > 
> > > 
> > > - RGB
> 
> - RGB
> 
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Tuesday, January 17, 2017 11:29:43 AM EST Richard Guy Briggs wrote:
> On 2017-01-17 11:12, Richard Guy Briggs wrote:
> > On 2017-01-17 08:55, Steve Grubb wrote:
> > > On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > > > I'm just starting to look at the normalization of AUDIT_NETFILTER_PKT
> > > > event messages and it is not quite as straightforward as I had
> > > > expected.
> > > > 
> > > > It is being tracked here:
> > > > 	https://github.com/linux-audit/audit-kernel/issues/11
> > > > 
> > > > and refers to a previous posting from Mr. Dash Four from four years
> > > > ago
> > > > to which there was no reply.
> > > > 
> > > > The example given in the tracker above for "frag=" is fairly
> > > > straightforward, but digging more, there are a number of others that
> > > > are
> > > > not quite so obvious.
> > > > 
> > > > How many different combinations of fields is acceptable?  Can we
> > > > create
> > > > new message types for each one, or is there a preferred way to
> > > > indicate
> > > > which sub-type it is other than implicit from the arguments given?
> > > 
> > > That would be preferential to swinging fields in and out. But we also
> > > don't
> > > want to add too many new types. If two protocols look almost identical,
> > > I'd
> > > try to coerce them to be the same. If adding 2 new types solves the
> > > problem
> > > just do it. If it takes 10, then maybe we should understand why.
> > 
> > Ok, I'll have a go at mapping some out and see where we end up...
> > 
> > > > Others that are straightforward:
> > > > - The first "truncated=" gets pulled in with "0".
> > > > 
> > > > - "mark=" gets pulled in with "0".
> > > > 
> > > > Ones that are not so straightforward:
> > > > - "secmark" depends on a kernel config setting, so should it always be
> > > > 
> > > >   present but "(none)" if that kernel feature is compiled out?
> > > 
> > > If this is selinux related, I'd treat it the same way that we do subj
> > > everywhere else.
> > 
> > Ok.
> > 
> > > > - ARPHRD_ETHER pulls in 3 fields, I would pull them all in and set
> > > > them
> > > > 
> > > >   to "(none)" to indicate that type isn't present.
> > > 
> > > "(none)" is for character fields that have nothing. Typically we set -1
> > > for
> > > numeric fields that are unset. If numbers are expected, its going to get
> > > the strtol() treatment and "(none)" will cause a conversion error.
> > 
> > Ah, ok.  I certainly don't want to break the parser, so I'll use -1 or
> > find another way to indicate it.
> > 
> > > > - audit_ip4() and audit_ip6 share "saddr=", "daddr=", proto=", but ip4
> > > > 
> > > >   adds "ipid=", which would be set to "(none)" for ip6.
> 
> I assume that v4, v6 and mac address fields count as text?

Yes. We also use '?' in places where there is no value if that looks better.

-Steve

> > > That is numeric. -1?
> > 
> > Yup, 16-bit.  I'll make it -1.
> > 
> > > -Steve
> > > 
> > > > - audit_proto() pulls in "truncated=" again, then either "sport=" and
> > > > 
> > > >   "dport=" OR "icmptype=" and "icmpcode=".
> > > > 
> > > > If all fields are pulled in, we end up adding 10 fields beyond a
> > > > standard well-formed packet, and 15 beyond a truncated packet.
> > > > 
> > > > Note: In the cases of "mark" and "secmark" both are unions.  In the
> > > > case of
> > > > "mark", I don't see a problem since it isn't conditionally compiled
> > > > out
> > > > and won't be mis-interpreted.  In the case of "secmark=", it could be
> > > > mis-interpreted as offload_fwd_mark if that field is even compiled in,
> > > > but that would be addressed in the compiler directive...
> > > > 
> > > > 
> > > > One last question: Does anyone have a test suite that can generate any
> > > > or all of these types of packets?
> > > > 
> > > > 
> > > > Thanks!
> > > > 
> > > > 
> > > > - RGB
> > 
> > - RGB
> > 
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Kernel Security Engineering, Base Operating Systems, Red Hat
> > Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635
> 
> - RGB
> 
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-01-17 08:55, Steve Grubb wrote:
>> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:

...

>> > Ones that are not so straightforward:
>> > - "secmark" depends on a kernel config setting, so should it always be
>> >   present but "(none)" if that kernel feature is compiled out?
>>
>> If this is selinux related, I'd treat it the same way that we do subj
>> everywhere else.
>
> Ok.

To be clear, a packet's secmark should be recorded via a dedicated
field, e.g. "secmark", and not use the "subj" field (it isn't a
subject label in the traditional sense).

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 15:17, Paul Moore wrote:
> On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-01-17 08:55, Steve Grubb wrote:
> >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> 
> ...
> 
> >> > Ones that are not so straightforward:
> >> > - "secmark" depends on a kernel config setting, so should it always be
> >> >   present but "(none)" if that kernel feature is compiled out?
> >>
> >> If this is selinux related, I'd treat it the same way that we do subj
> >> everywhere else.
> >
> > Ok.
> 
> To be clear, a packet's secmark should be recorded via a dedicated
> field, e.g. "secmark", and not use the "subj" field (it isn't a
> subject label in the traditional sense).

I think Steve was talking about if, when or where to include that field,
not what its label is.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-17 21:34, Richard Guy Briggs wrote:
> On 2017-01-17 15:17, Paul Moore wrote:
> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > > On 2017-01-17 08:55, Steve Grubb wrote:
> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> > 
> > ...
> > 
> > >> > Ones that are not so straightforward:
> > >> > - "secmark" depends on a kernel config setting, so should it always be
> > >> >   present but "(none)" if that kernel feature is compiled out?
> > >>
> > >> If this is selinux related, I'd treat it the same way that we do subj
> > >> everywhere else.
> > >
> > > Ok.
> > 
> > To be clear, a packet's secmark should be recorded via a dedicated
> > field, e.g. "secmark", and not use the "subj" field (it isn't a
> > subject label in the traditional sense).
> 
> I think Steve was talking about if, when or where to include that field,
> not what its label is.

In this case it is an "obj=" field, but since it is part of the LSM,
each one has its own fields.

> > paul moore
> 
> - RGB

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-01-17 21:34, Richard Guy Briggs wrote:
>> On 2017-01-17 15:17, Paul Moore wrote:
>> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > > On 2017-01-17 08:55, Steve Grubb wrote:
>> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
>> >
>> > ...
>> >
>> > >> > Ones that are not so straightforward:
>> > >> > - "secmark" depends on a kernel config setting, so should it always be
>> > >> >   present but "(none)" if that kernel feature is compiled out?
>> > >>
>> > >> If this is selinux related, I'd treat it the same way that we do subj
>> > >> everywhere else.
>> > >
>> > > Ok.
>> >
>> > To be clear, a packet's secmark should be recorded via a dedicated
>> > field, e.g. "secmark", and not use the "subj" field (it isn't a
>> > subject label in the traditional sense).
>>
>> I think Steve was talking about if, when or where to include that field,
>> not what its label is.
>
> In this case it is an "obj=" field, but since it is part of the LSM,
> each one has its own fields.

As I said above, use a "secmark" field and not the subject or object
fields; packet labeling is rather complex and there is value in
differentiating between secmark labels and network peer labels.

-- 
paul moore
security @ redhat

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Wednesday, January 18, 2017 7:32:40 AM EST Paul Moore wrote:
> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-01-17 21:34, Richard Guy Briggs wrote:
> >> On 2017-01-17 15:17, Paul Moore wrote:
> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> 
wrote:
> >> > > On 2017-01-17 08:55, Steve Grubb wrote:
> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs 
wrote:
> >> > ...
> >> > 
> >> > >> > Ones that are not so straightforward:
> >> > >> > - "secmark" depends on a kernel config setting, so should it
> >> > >> > always be
> >> > >> > 
> >> > >> >   present but "(none)" if that kernel feature is compiled out?
> >> > >> 
> >> > >> If this is selinux related, I'd treat it the same way that we do
> >> > >> subj
> >> > >> everywhere else.
> >> > > 
> >> > > Ok.
> >> > 
> >> > To be clear, a packet's secmark should be recorded via a dedicated
> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a
> >> > subject label in the traditional sense).
> >> 
> >> I think Steve was talking about if, when or where to include that field,
> >> not what its label is.
> > 
> > In this case it is an "obj=" field, but since it is part of the LSM,
> > each one has its own fields.
> 
> As I said above, use a "secmark" field and not the subject or object
> fields; packet labeling is rather complex and there is value in
> differentiating between secmark labels and network peer labels.

As Richard said, I was talking about when to include it, not what to include. 
Context labels go through this test to check if there is a secid and log 
context information if its there. This keeps the logs self consistent if a MAC 
framework is compiled in or not.

-Steve

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-18 07:32, Paul Moore wrote:
> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-01-17 21:34, Richard Guy Briggs wrote:
> >> On 2017-01-17 15:17, Paul Moore wrote:
> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >> > > On 2017-01-17 08:55, Steve Grubb wrote:
> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
> >> >
> >> > ...
> >> >
> >> > >> > Ones that are not so straightforward:
> >> > >> > - "secmark" depends on a kernel config setting, so should it always be
> >> > >> >   present but "(none)" if that kernel feature is compiled out?
> >> > >>
> >> > >> If this is selinux related, I'd treat it the same way that we do subj
> >> > >> everywhere else.
> >> > >
> >> > > Ok.
> >> >
> >> > To be clear, a packet's secmark should be recorded via a dedicated
> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a
> >> > subject label in the traditional sense).
> >>
> >> I think Steve was talking about if, when or where to include that field,
> >> not what its label is.
> >
> > In this case it is an "obj=" field, but since it is part of the LSM,
> > each one has its own fields.
> 
> As I said above, use a "secmark" field and not the subject or object
> fields; packet labeling is rather complex and there is value in
> differentiating between secmark labels and network peer labels.

Ok, I'll change it from the existing "obj=" to "secmark=".  Since it is
an LSM-dependent field, it will go away when that LSM module does.  It
is the very last item in the list of fields, so I don't see this as a
problem.


I have more questions and observations:

Do we care if the rest of the record's fields are there if the packet is
truncated?  In other words, can I omit all the following fields (that
will end up being set to (none) or -1 since there is no data for them)?
I'd prefer to complete the record, but Steve may not care and might
prefer to save the bandwidth.

Can I truncate the field name "truncated" to "trunc" (since I don't see
it yet in the audit field dictionary) if we do include all the fields?

I observe that support for IPPROTO_DCCP and IPPROTO_SCTP can be added
virtually for free since the source and desination ports in their packet
formats is identical to TCP and UDP (and UDPLITE).


At this point, it looks like having one record for IP/IPv6 with
TCP/UDP/DCCP/SCTP makes sense.  Whether or not to add ethernet bridge
headers and ICMP* is a more difficult question.  Ethernet bridge adds 40 chars
if it isn't used, up to 62 if it is.  ICMP* adds 26 max.

It is an independent record, but it would be nice to be able to reuse
the message ID with a new record type to list sub-parts of the packet,
for example, reuse the existing record type (AUDIT_NETFILTER_PKT) for
the first 5 fields, mark and secmark, then another record type
(AUDIT_NETFILTER_PKT_ETH) for ethernet header, a record
(AUDIT_NETFILTER_PKT_IP) for IP/IPv6 header, then another
(AUDIT_NETFILTER_PKT_PROTO) for transport layer protocol.  This way, the
absence of an ethernet bridge header won't swing out three fields, or waste 40
chars.  IPv4 adds about 20 chars not used by IPv6.  TCP/UDP/DCCP/SCTP vs ICMP*
is about 25 chars each.  The max message is 322 chars (eth bridge, IPv6).  A
non-ethernet-bridge non-IP* message would be as little as 76 without the extra
fields, but as much as 219 with the extra fields filled with unset values.

A full message could look like (I've left off secmark, which would go at the end):
action=9 hook=9999999999 len=9999999999 inif=ZZZZ outif=ZZZZ mark=0xffffffff smac=FF:FF:FF:FF:FF:FF dmac=FF:FF:FF:FF:FF:FF macproto=0xffff trunc=9 saddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF daddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ipid=-1 proto=255 frag=-1 trunc=9 sport=99999 dport=99999 icmptype=999 icmpcode=999


> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-01-18 07:32, Paul Moore wrote:
>> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2017-01-17 21:34, Richard Guy Briggs wrote:
>> >> On 2017-01-17 15:17, Paul Moore wrote:
>> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> >> > > On 2017-01-17 08:55, Steve Grubb wrote:
>> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs wrote:
>> >> >
>> >> > ...
>> >> >
>> >> > >> > Ones that are not so straightforward:
>> >> > >> > - "secmark" depends on a kernel config setting, so should it always be
>> >> > >> >   present but "(none)" if that kernel feature is compiled out?
>> >> > >>
>> >> > >> If this is selinux related, I'd treat it the same way that we do subj
>> >> > >> everywhere else.
>> >> > >
>> >> > > Ok.
>> >> >
>> >> > To be clear, a packet's secmark should be recorded via a dedicated
>> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a
>> >> > subject label in the traditional sense).
>> >>
>> >> I think Steve was talking about if, when or where to include that field,
>> >> not what its label is.
>> >
>> > In this case it is an "obj=" field, but since it is part of the LSM,
>> > each one has its own fields.
>>
>> As I said above, use a "secmark" field and not the subject or object
>> fields; packet labeling is rather complex and there is value in
>> differentiating between secmark labels and network peer labels.
>
> Ok, I'll change it from the existing "obj=" to "secmark=".  Since it is
> an LSM-dependent field, it will go away when that LSM module does.  It
> is the very last item in the list of fields, so I don't see this as a
> problem.
>
>
> I have more questions and observations:
>
> Do we care if the rest of the record's fields are there if the packet is
> truncated?  In other words, can I omit all the following fields (that
> will end up being set to (none) or -1 since there is no data for them)?
> I'd prefer to complete the record, but Steve may not care and might
> prefer to save the bandwidth.
>
> Can I truncate the field name "truncated" to "trunc" (since I don't see
> it yet in the audit field dictionary) if we do include all the fields?
>
> I observe that support for IPPROTO_DCCP and IPPROTO_SCTP can be added
> virtually for free since the source and desination ports in their packet
> formats is identical to TCP and UDP (and UDPLITE).
>
>
> At this point, it looks like having one record for IP/IPv6 with
> TCP/UDP/DCCP/SCTP makes sense.  Whether or not to add ethernet bridge
> headers and ICMP* is a more difficult question.  Ethernet bridge adds 40 chars
> if it isn't used, up to 62 if it is.  ICMP* adds 26 max.
>
> It is an independent record, but it would be nice to be able to reuse
> the message ID with a new record type to list sub-parts of the packet,
> for example, reuse the existing record type (AUDIT_NETFILTER_PKT) for
> the first 5 fields, mark and secmark, then another record type
> (AUDIT_NETFILTER_PKT_ETH) for ethernet header, a record
> (AUDIT_NETFILTER_PKT_IP) for IP/IPv6 header, then another
> (AUDIT_NETFILTER_PKT_PROTO) for transport layer protocol.  This way, the
> absence of an ethernet bridge header won't swing out three fields, or waste 40
> chars.  IPv4 adds about 20 chars not used by IPv6.  TCP/UDP/DCCP/SCTP vs ICMP*
> is about 25 chars each.  The max message is 322 chars (eth bridge, IPv6).  A
> non-ethernet-bridge non-IP* message would be as little as 76 without the extra
> fields, but as much as 219 with the extra fields filled with unset values.
>
> A full message could look like (I've left off secmark, which would go at the end):
> action=9 hook=9999999999 len=9999999999 inif=ZZZZ outif=ZZZZ mark=0xffffffff smac=FF:FF:FF:FF:FF:FF dmac=FF:FF:FF:FF:FF:FF macproto=0xffff trunc=9 saddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF daddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ipid=-1 proto=255 frag=-1 trunc=9 sport=99999 dport=99999 icmptype=999 icmpcode=999
>

At this point I think it would be good to hear what requirements exist
for per-packet auditing.  Steve, are there any current Common Criteria
(or other) requirements that impact per-packet auditing?

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote:
> On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-01-18 07:32, Paul Moore wrote:
> >> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@redhat.com> 
wrote:
> >> > On 2017-01-17 21:34, Richard Guy Briggs wrote:
> >> >> On 2017-01-17 15:17, Paul Moore wrote:
> >> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs 
<rgb@redhat.com> wrote:
> >> >> > > On 2017-01-17 08:55, Steve Grubb wrote:
> >> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs 
wrote:
> >> >> > ...
> >> >> > 
> >> >> > >> > Ones that are not so straightforward:
> >> >> > >> > - "secmark" depends on a kernel config setting, so should it
> >> >> > >> > always be
> >> >> > >> > 
> >> >> > >> >   present but "(none)" if that kernel feature is compiled out?
> >> >> > >> 
> >> >> > >> If this is selinux related, I'd treat it the same way that we do
> >> >> > >> subj
> >> >> > >> everywhere else.
> >> >> > > 
> >> >> > > Ok.
> >> >> > 
> >> >> > To be clear, a packet's secmark should be recorded via a dedicated
> >> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a
> >> >> > subject label in the traditional sense).
> >> >> 
> >> >> I think Steve was talking about if, when or where to include that
> >> >> field,
> >> >> not what its label is.
> >> > 
> >> > In this case it is an "obj=" field, but since it is part of the LSM,
> >> > each one has its own fields.
> >> 
> >> As I said above, use a "secmark" field and not the subject or object
> >> fields; packet labeling is rather complex and there is value in
> >> differentiating between secmark labels and network peer labels.
> > 
> > Ok, I'll change it from the existing "obj=" to "secmark=".  Since it is
> > an LSM-dependent field, it will go away when that LSM module does.  It
> > is the very last item in the list of fields, so I don't see this as a
> > problem.
> > 
> > 
> > I have more questions and observations:
> > 
> > Do we care if the rest of the record's fields are there if the packet is
> > truncated?  In other words, can I omit all the following fields (that
> > will end up being set to (none) or -1 since there is no data for them)?
> > I'd prefer to complete the record, but Steve may not care and might
> > prefer to save the bandwidth.
> > 
> > Can I truncate the field name "truncated" to "trunc" (since I don't see
> > it yet in the audit field dictionary) if we do include all the fields?
> > 
> > I observe that support for IPPROTO_DCCP and IPPROTO_SCTP can be added
> > virtually for free since the source and desination ports in their packet
> > formats is identical to TCP and UDP (and UDPLITE).
> > 
> > 
> > At this point, it looks like having one record for IP/IPv6 with
> > TCP/UDP/DCCP/SCTP makes sense.  Whether or not to add ethernet bridge
> > headers and ICMP* is a more difficult question.  Ethernet bridge adds 40
> > chars if it isn't used, up to 62 if it is.  ICMP* adds 26 max.
> > 
> > It is an independent record, but it would be nice to be able to reuse
> > the message ID with a new record type to list sub-parts of the packet,
> > for example, reuse the existing record type (AUDIT_NETFILTER_PKT) for
> > the first 5 fields, mark and secmark, then another record type
> > (AUDIT_NETFILTER_PKT_ETH) for ethernet header, a record
> > (AUDIT_NETFILTER_PKT_IP) for IP/IPv6 header, then another
> > (AUDIT_NETFILTER_PKT_PROTO) for transport layer protocol.  This way, the
> > absence of an ethernet bridge header won't swing out three fields, or
> > waste 40 chars.  IPv4 adds about 20 chars not used by IPv6. 
> > TCP/UDP/DCCP/SCTP vs ICMP* is about 25 chars each.  The max message is
> > 322 chars (eth bridge, IPv6).  A non-ethernet-bridge non-IP* message
> > would be as little as 76 without the extra fields, but as much as 219
> > with the extra fields filled with unset values.
> > 
> > A full message could look like (I've left off secmark, which would go at
> > the end): action=9 hook=9999999999 len=9999999999 inif=ZZZZ outif=ZZZZ
> > mark=0xffffffff smac=FF:FF:FF:FF:FF:FF dmac=FF:FF:FF:FF:FF:FF
> > macproto=0xffff trunc=9 saddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
> > daddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ipid=-1 proto=255 frag=-1
> > trunc=9 sport=99999 dport=99999 icmptype=999 icmpcode=999
>
> At this point I think it would be good to hear what requirements exist
> for per-packet auditing.  Steve, are there any current Common Criteria
> (or other) requirements that impact per-packet auditing?

I don't think you want to flood your logs. That is not helpful. It asks for the 
ability to detect information flow. Typically you want to know source and 
destination, protocol, where on the system its coming from or going to, pid if 
possible and the subject information if available. I know that you can be 
acting as a proxy and forwarding outside packets into a network. That is not 
the typical case CC is concerned about. Its more about what the user is doing.

-Steve

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Fri, Jan 20, 2017 at 9:49 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote:
>> At this point I think it would be good to hear what requirements exist
>> for per-packet auditing.  Steve, are there any current Common Criteria
>> (or other) requirements that impact per-packet auditing?
>
> I don't think you want to flood your logs. That is not helpful. It asks for the
> ability to detect information flow. Typically you want to know source and
> destination, protocol, where on the system its coming from or going to, pid if
> possible and the subject information if available. I know that you can be
> acting as a proxy and forwarding outside packets into a network. That is not
> the typical case CC is concerned about. Its more about what the user is doing.

Determining the pid/subj of a packet is notoriously
difficult/impossible in netfilter so let's drop that; with proper
policy/rules you should be able to match proto/port with a given
process so this shouldn't be that critical.  The source/destination
addresses and proto/port (assuming IP) should be easy enough.

All right, now that we've got the "must" items down, are their any
"should" items we want?

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Patrick PIGNOL]

Hi all,

I disagree !

Many people in the world would like to allow an software A to go to 
internet through OUTPUT TCP port 80 but disallow software B to go to the 
internet through this same OUTPUT TCP port 80. Don't you know about 
viruses on linux ? Viruses ALWAYS use HTTP/HTTPS ports to get payloads 
on internet and OUTPUT TCP port 443 COULD NOT be CLOSED for ALL SOFTWARE 
if you want to access internet services (via internet browsers for example).

And we cannot know every dangerous IP in the world. Even because there 
are new one every time in the world. There could be a not dangerous 
server that became dangerous one because it became a hacked server.

So it's an EXCELLENT idea to make Software socket/PID accessible from 
packet netfilter API. That could prevent some malware to access opened 
standard ports and give to the users a way to make better protection 
with closest control on which software ave right to get information from 
the internet.

BE USER FRIENDLY PLEASE !!!!

Best regards,

Patrick PIGNOL

Le 20/01/2017 à 21:37, Paul Moore a écrit :
> On Fri, Jan 20, 2017 at 9:49 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>> On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote:
>>> At this point I think it would be good to hear what requirements exist
>>> for per-packet auditing.  Steve, are there any current Common Criteria
>>> (or other) requirements that impact per-packet auditing?
>> I don't think you want to flood your logs. That is not helpful. It asks for the
>> ability to detect information flow. Typically you want to know source and
>> destination, protocol, where on the system its coming from or going to, pid if
>> possible and the subject information if available. I know that you can be
>> acting as a proxy and forwarding outside packets into a network. That is not
>> the typical case CC is concerned about. Its more about what the user is doing.
> Determining the pid/subj of a packet is notoriously
> difficult/impossible in netfilter so let's drop that; with proper
> policy/rules you should be able to match proto/port with a given
> process so this shouldn't be that critical.  The source/destination
> addresses and proto/port (assuming IP) should be easy enough.
>
> All right, now that we've got the "must" items down, are their any
> "should" items we want?
>

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Sat, Jan 21, 2017 at 6:27 AM, Patrick PIGNOL
<patrick.pignol@gmail.com> wrote:
> Hi all,
>
> I disagree !
>
> Many people in the world would like to allow an software A to go to internet
> through OUTPUT TCP port 80 but disallow software B to go to the internet
> through this same OUTPUT TCP port 80. Don't you know about viruses on linux
> ? Viruses ALWAYS use HTTP/HTTPS ports to get payloads on internet and OUTPUT
> TCP port 443 COULD NOT be CLOSED for ALL SOFTWARE if you want to access
> internet services (via internet browsers for example).

The Linux audit subsystem simply logs system events, it does not
enforce security policy.  I suggest you investigate the different
Linux firewall tools and LSMs, e.g. SELinux, as they should help you
accomplish what you describe.

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Patrick PIGNOL]

Hi all,

I just writen that because I read

"

Determining the pid/subj of a packet is notoriously
difficult/impossible in netfilter so let's drop that; with proper
policy/rules you should be able to match proto/port with a given
process so this shouldn't be that critical.  The source/destination
addresses and proto/port (assuming IP) should be easy enough.

"

OK you explain me you talk about "Linux audit" sub-system. Cool I didn't 
read it like that ! (I'm waiting for netfilter-dev ml).

Don't tell me that windows is better than linux on that point (see 
ZoneAlarm). I know ZoneAlarm is a Firewall. But if Linux could trace it 
from netfilter you should integrate it in your audit sub system.

I think it should be good to have to know witch application ask for 
send/receive packet on witch protocol and on witch port and for witch IP 
target(from/to) at a given level of verbosity(debug) and how many time 
for a given time-unit (minute-hour).

At this level content of packet is not really useful, I think wire-shark 
is better for that.

Sorry for the noise but it still important for me as a user to can trace 
who have access to an from my computer.

Best regards,

Patrick PIGNOL


Le 21/01/2017 à 18:37, Paul Moore a écrit :
> On Sat, Jan 21, 2017 at 6:27 AM, Patrick PIGNOL
> <patrick.pignol@gmail.com> wrote:
>> Hi all,
>>
>> I disagree !
>>
>> Many people in the world would like to allow an software A to go to internet
>> through OUTPUT TCP port 80 but disallow software B to go to the internet
>> through this same OUTPUT TCP port 80. Don't you know about viruses on linux
>> ? Viruses ALWAYS use HTTP/HTTPS ports to get payloads on internet and OUTPUT
>> TCP port 443 COULD NOT be CLOSED for ALL SOFTWARE if you want to access
>> internet services (via internet browsers for example).
> The Linux audit subsystem simply logs system events, it does not
> enforce security policy.  I suggest you investigate the different
> Linux firewall tools and LSMs, e.g. SELinux, as they should help you
> accomplish what you describe.
>

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-21 20:12, Patrick PIGNOL wrote:
> Hi all,
> 
> I just writen that because I read
> 
> "
> 
> Determining the pid/subj of a packet is notoriously
> difficult/impossible in netfilter so let's drop that; with proper
> policy/rules you should be able to match proto/port with a given
> process so this shouldn't be that critical.  The source/destination
> addresses and proto/port (assuming IP) should be easy enough.
> 
> "
> 
> OK you explain me you talk about "Linux audit" sub-system. Cool I
> didn't read it like that ! (I'm waiting for netfilter-dev ml).
> 
> Don't tell me that windows is better than linux on that point (see
> ZoneAlarm). I know ZoneAlarm is a Firewall. But if Linux could trace
> it from netfilter you should integrate it in your audit sub system.
> 
> I think it should be good to have to know witch application ask for
> send/receive packet on witch protocol and on witch port and for
> witch IP target(from/to) at a given level of verbosity(debug) and
> how many time for a given time-unit (minute-hour).
> 
> At this level content of packet is not really useful, I think
> wire-shark is better for that.
> 
> Sorry for the noise but it still important for me as a user to can
> trace who have access to an from my computer.

As Paul points out, there are things we know about all packets that we
can put into that report.  There are things we don't know that can't be
a MUST, but can be a SHOULD if we know them to be able to record them
and would be useful.  The challenge here is that if we add a number of
fields from the SHOULD list that are unknown for some use cases
(FORWARD, userless in-kernel targets, ...) they will consume bandwidth
to report empty values, and we are trying to normalize this audit record
type so that fields don't swing in and out needlessly.

> Best regards,
> 
> Patrick PIGNOL
> 
> 
> Le 21/01/2017 à 18:37, Paul Moore a écrit :
> >On Sat, Jan 21, 2017 at 6:27 AM, Patrick PIGNOL
> ><patrick.pignol@gmail.com> wrote:
> >>Hi all,
> >>
> >>I disagree !
> >>
> >>Many people in the world would like to allow an software A to go to internet
> >>through OUTPUT TCP port 80 but disallow software B to go to the internet
> >>through this same OUTPUT TCP port 80. Don't you know about viruses on linux
> >>? Viruses ALWAYS use HTTP/HTTPS ports to get payloads on internet and OUTPUT
> >>TCP port 443 COULD NOT be CLOSED for ALL SOFTWARE if you want to access
> >>internet services (via internet browsers for example).
> >The Linux audit subsystem simply logs system events, it does not
> >enforce security policy.  I suggest you investigate the different
> >Linux firewall tools and LSMs, e.g. SELinux, as they should help you
> >accomplish what you describe.
> >
> 

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-01-20 09:49, Steve Grubb wrote:
> On Wednesday, January 18, 2017 6:35:29 PM EST Paul Moore wrote:
> > On Wed, Jan 18, 2017 at 10:15 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > > On 2017-01-18 07:32, Paul Moore wrote:
> > >> On Wed, Jan 18, 2017 at 12:39 AM, Richard Guy Briggs <rgb@redhat.com> 
> wrote:
> > >> > On 2017-01-17 21:34, Richard Guy Briggs wrote:
> > >> >> On 2017-01-17 15:17, Paul Moore wrote:
> > >> >> > On Tue, Jan 17, 2017 at 11:12 AM, Richard Guy Briggs 
> <rgb@redhat.com> wrote:
> > >> >> > > On 2017-01-17 08:55, Steve Grubb wrote:
> > >> >> > >> On Tuesday, January 17, 2017 12:25:51 AM EST Richard Guy Briggs 
> wrote:
> > >> >> > ...
> > >> >> > 
> > >> >> > >> > Ones that are not so straightforward:
> > >> >> > >> > - "secmark" depends on a kernel config setting, so should it
> > >> >> > >> > always be
> > >> >> > >> > 
> > >> >> > >> >   present but "(none)" if that kernel feature is compiled out?
> > >> >> > >> 
> > >> >> > >> If this is selinux related, I'd treat it the same way that we do
> > >> >> > >> subj
> > >> >> > >> everywhere else.
> > >> >> > > 
> > >> >> > > Ok.
> > >> >> > 
> > >> >> > To be clear, a packet's secmark should be recorded via a dedicated
> > >> >> > field, e.g. "secmark", and not use the "subj" field (it isn't a
> > >> >> > subject label in the traditional sense).
> > >> >> 
> > >> >> I think Steve was talking about if, when or where to include that
> > >> >> field,
> > >> >> not what its label is.
> > >> > 
> > >> > In this case it is an "obj=" field, but since it is part of the LSM,
> > >> > each one has its own fields.
> > >> 
> > >> As I said above, use a "secmark" field and not the subject or object
> > >> fields; packet labeling is rather complex and there is value in
> > >> differentiating between secmark labels and network peer labels.
> > > 
> > > Ok, I'll change it from the existing "obj=" to "secmark=".  Since it is
> > > an LSM-dependent field, it will go away when that LSM module does.  It
> > > is the very last item in the list of fields, so I don't see this as a
> > > problem.
> > > 
> > > 
> > > I have more questions and observations:
> > > 
> > > Do we care if the rest of the record's fields are there if the packet is
> > > truncated?  In other words, can I omit all the following fields (that
> > > will end up being set to (none) or -1 since there is no data for them)?
> > > I'd prefer to complete the record, but Steve may not care and might
> > > prefer to save the bandwidth.
> > > 
> > > Can I truncate the field name "truncated" to "trunc" (since I don't see
> > > it yet in the audit field dictionary) if we do include all the fields?
> > > 
> > > I observe that support for IPPROTO_DCCP and IPPROTO_SCTP can be added
> > > virtually for free since the source and desination ports in their packet
> > > formats is identical to TCP and UDP (and UDPLITE).
> > > 
> > > 
> > > At this point, it looks like having one record for IP/IPv6 with
> > > TCP/UDP/DCCP/SCTP makes sense.  Whether or not to add ethernet bridge
> > > headers and ICMP* is a more difficult question.  Ethernet bridge adds 40
> > > chars if it isn't used, up to 62 if it is.  ICMP* adds 26 max.
> > > 
> > > It is an independent record, but it would be nice to be able to reuse
> > > the message ID with a new record type to list sub-parts of the packet,
> > > for example, reuse the existing record type (AUDIT_NETFILTER_PKT) for
> > > the first 5 fields, mark and secmark, then another record type
> > > (AUDIT_NETFILTER_PKT_ETH) for ethernet header, a record
> > > (AUDIT_NETFILTER_PKT_IP) for IP/IPv6 header, then another
> > > (AUDIT_NETFILTER_PKT_PROTO) for transport layer protocol.  This way, the
> > > absence of an ethernet bridge header won't swing out three fields, or
> > > waste 40 chars.  IPv4 adds about 20 chars not used by IPv6. 
> > > TCP/UDP/DCCP/SCTP vs ICMP* is about 25 chars each.  The max message is
> > > 322 chars (eth bridge, IPv6).  A non-ethernet-bridge non-IP* message
> > > would be as little as 76 without the extra fields, but as much as 219
> > > with the extra fields filled with unset values.
> > > 
> > > A full message could look like (I've left off secmark, which would go at
> > > the end): action=9 hook=9999999999 len=9999999999 inif=ZZZZ outif=ZZZZ
> > > mark=0xffffffff smac=FF:FF:FF:FF:FF:FF dmac=FF:FF:FF:FF:FF:FF
> > > macproto=0xffff trunc=9 saddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
> > > daddr=FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ipid=-1 proto=255 frag=-1
> > > trunc=9 sport=99999 dport=99999 icmptype=999 icmpcode=999
> >
> > At this point I think it would be good to hear what requirements exist
> > for per-packet auditing.  Steve, are there any current Common Criteria
> > (or other) requirements that impact per-packet auditing?
> 
> I don't think you want to flood your logs. That is not helpful. It asks for the 
> ability to detect information flow. Typically you want to know source and 
> destination, protocol, where on the system its coming from or going to, pid if 
> possible and the subject information if available. I know that you can be 
> acting as a proxy and forwarding outside packets into a network. That is not 
> the typical case CC is concerned about. Its more about what the user is doing.

So while I'm not advocating this is what should be done and I'm trying
to establish bounds to the scope of this feature, but would it be
reasonable to simply not log packets that were transiting this machine
without a local endpoint?

> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> So while I'm not advocating this is what should be done and I'm trying
> to establish bounds to the scope of this feature, but would it be
> reasonable to simply not log packets that were transiting this machine
> without a local endpoint?

I'm still waiting on more detailed requirements information from
Steve, but based on what we've heard so far, it seems that ignoring
forwarded traffic is a reasonable thing to do.

-- 
paul moore
security @ redhat

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > So while I'm not advocating this is what should be done and I'm trying
> > to establish bounds to the scope of this feature, but would it be
> > reasonable to simply not log packets that were transiting this machine
> > without a local endpoint?
> 
> I'm still waiting on more detailed requirements information from
> Steve, but based on what we've heard so far, it seems that ignoring
> forwarded traffic is a reasonable thing to do.

OK, I have done teh analysis to see where things stand on this. A long time 
ago, there was no security requirements around virtualization except OSPP v2.0 
from BSI which had a virtualization extended module. In it, it had the 
following requirements:

FDP_IFF.1.2 The TSF shall permit an information flow between a controlled 
subject and controlled information via a controlled operation if the following 
rules hold: [assignment: for each operation, the security attribute-based
relationship that must hold between subject and information security
attributes, which must allow to define the security attribute-based
relationship between two subjects such that information flow
between the compartments is not permitted].
FDP_IFF.1.3 The TSF shall enforce the [assignment: additional information flow 
control SFP rules].
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the
following rules: [assignment: rules, based on security attributes, that
explicitly authorise information flows].
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the 
following rules: [assignment: rules, based on security attributes, that 
explicitly deny information flows].

So, whenever there was an allow or deny, then that needed to be auditable. The 
audit target was added and it can be configured to closely mirrored the rules. 
When auditing sufficient information needs to be recorded to make sense of why 
the flow was allowed or denied. Ultimately you really want this connected to a 
process and user if applicable.

However, in reviewing server virtualization protection profile v1.1 and 
operating system protection profile v4.1, there is no FDP_IFF.1 requirement 
which means that there are no more requirements to audit network packets. I 
did not review the network device protection profile which may or may not levy 
requirements for network auditing.

At this point, I would say there is no purpose for xt_AUDIT.c based on Common 
Criteria. It looks like its built in response to the 
CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly 
deprecated.

-Steve

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
>> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > So while I'm not advocating this is what should be done and I'm trying
>> > to establish bounds to the scope of this feature, but would it be
>> > reasonable to simply not log packets that were transiting this machine
>> > without a local endpoint?
>>
>> I'm still waiting on more detailed requirements information from
>> Steve, but based on what we've heard so far, it seems that ignoring
>> forwarded traffic is a reasonable thing to do.
>
> OK, I have done teh analysis to see where things stand on this ...

...

> At this point, I would say there is no purpose for xt_AUDIT.c based on Common
> Criteria. It looks like its built in response to the
> CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly
> deprecated.

Based on some off-list discussions with Richard it would appear that
there are several users of the NETFILTER_PKT record so I am in no
hurry to deprecate it.  Considering that there are no CC requirements
on the record, I think we can focus on simply providing a basic record
that satisfies the whims of the userspace tools without adding any
pain to the kernel.  I believe Richard is currently working on a
proposal to do that, let's discuss it further in that thread.

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Pablo Neira Ayuso]

Hi Paul,

On Wed, Feb 08, 2017 at 06:09:07PM -0500, Paul Moore wrote:
> On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >> > So while I'm not advocating this is what should be done and I'm trying
> >> > to establish bounds to the scope of this feature, but would it be
> >> > reasonable to simply not log packets that were transiting this machine
> >> > without a local endpoint?
> >>
> >> I'm still waiting on more detailed requirements information from
> >> Steve, but based on what we've heard so far, it seems that ignoring
> >> forwarded traffic is a reasonable thing to do.
> >
> > OK, I have done teh analysis to see where things stand on this ...
> 
> ...
> 
> > At this point, I would say there is no purpose for xt_AUDIT.c based on Common
> > Criteria. It looks like its built in response to the
> > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly
> > deprecated.
> 
> Based on some off-list discussions with Richard it would appear that
> there are several users of the NETFILTER_PKT record so I am in no
> hurry to deprecate it.  Considering that there are no CC requirements
> on the record, I think we can focus on simply providing a basic record
> that satisfies the whims of the userspace tools without adding any
> pain to the kernel.  I believe Richard is currently working on a
> proposal to do that, let's discuss it further in that thread.

If the concern is to keep the existing output format around, you can
add new functions with the specific new layout at the cost of keeping
more code around. That should be fine since this code is not much
complex IMO. You can probably add a new explicit command line option,
eg. --version, that indicates what audit format version you want to
use, so users don't break.

BTW, any plans to add audit support to nf_tables?

Thanks.

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Thu, Feb 9, 2017 at 5:56 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> Hi Paul,
>
> On Wed, Feb 08, 2017 at 06:09:07PM -0500, Paul Moore wrote:
>> On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> wrote:
>> > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
>> >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> >> > So while I'm not advocating this is what should be done and I'm trying
>> >> > to establish bounds to the scope of this feature, but would it be
>> >> > reasonable to simply not log packets that were transiting this machine
>> >> > without a local endpoint?
>> >>
>> >> I'm still waiting on more detailed requirements information from
>> >> Steve, but based on what we've heard so far, it seems that ignoring
>> >> forwarded traffic is a reasonable thing to do.
>> >
>> > OK, I have done teh analysis to see where things stand on this ...
>>
>> ...
>>
>> > At this point, I would say there is no purpose for xt_AUDIT.c based on Common
>> > Criteria. It looks like its built in response to the
>> > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly
>> > deprecated.
>>
>> Based on some off-list discussions with Richard it would appear that
>> there are several users of the NETFILTER_PKT record so I am in no
>> hurry to deprecate it.  Considering that there are no CC requirements
>> on the record, I think we can focus on simply providing a basic record
>> that satisfies the whims of the userspace tools without adding any
>> pain to the kernel.  I believe Richard is currently working on a
>> proposal to do that, let's discuss it further in that thread.
>
> If the concern is to keep the existing output format around, you can
> add new functions with the specific new layout at the cost of keeping
> more code around. That should be fine since this code is not much
> complex IMO. You can probably add a new explicit command line option,
> eg. --version, that indicates what audit format version you want to
> use, so users don't break.

There are several things to consider, and I'm not going to worry too
much about it until Richard posts his updated RFC.  In quick summary,
Steve is worried about record formats which don't meet a specific
format specification (e.g. fields that optionally appear depending on
the protocol are bad from his perspective) and I'm worried about
adding a bunch of additional code to the kernel.

We can discuss this further once we see Richard's patches, he is aware
of all the concerns and I expect he will have something interesting to
use as a starting point for further discussion.

> BTW, any plans to add audit support to nf_tables?

It would be nice, but it isn't on my TODO list at the moment; if you
want to work on it I think that would be great!

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-08 18:09, Paul Moore wrote:
> On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> >> > So while I'm not advocating this is what should be done and I'm trying
> >> > to establish bounds to the scope of this feature, but would it be
> >> > reasonable to simply not log packets that were transiting this machine
> >> > without a local endpoint?
> >>
> >> I'm still waiting on more detailed requirements information from
> >> Steve, but based on what we've heard so far, it seems that ignoring
> >> forwarded traffic is a reasonable thing to do.
> >
> > OK, I have done the analysis to see where things stand on this ...
> 
> ...
> 
> > At this point, I would say there is no purpose for xt_AUDIT.c based on Common
> > Criteria. It looks like its built in response to the
> > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly
> > deprecated.
> 
> Based on some off-list discussions with Richard it would appear that
> there are several users of the NETFILTER_PKT record so I am in no
> hurry to deprecate it.  Considering that there are no CC requirements
> on the record, I think we can focus on simply providing a basic record
> that satisfies the whims of the userspace tools without adding any
> pain to the kernel.  I believe Richard is currently working on a
> proposal to do that, let's discuss it further in that thread.

If there is no strict rule about turning any other type of record other than
SYSCALLs into compound records, we could add the user credentials if
they are identifyable without having a number of unset fields by using
an auxilliary record.  If this isn't possible or desirable, we'd need to
include those fields as unset in every message unless we discard
messages for which there is no identifying information.


We probably don't want to trot out all the fields in a packet like
tcpdump does, since many of them won't be of interest to us.  We want
protocol family, end points, type of packet.  The ones that would be
quite useful but may be hard to get are pid, auid, sessionid.


There is no packet for which all fields are valid.  This is why using
"unset" values in those fields was suggested.

I'd start by splitting data from control protocols if we even need
source/destination ports or icmp* details.  Those seem like pretty
important details, so I think we need to start there.

I'd be inclined to use the same message type for IPv4 and IPv6 and just
drop the IPv4-specific fields, or include them with the IPv6 record and
set them to "unset" (ipid, frag).

As for the MAC (Media Access Control) addresses I'm not sure what to
recommend.  We could fill them in with the outer MAC, we could leave them as
unset or could just delete them entirely.

Source IP addresses can be easily spoofed, particularly for UDP, so they
are not particularly useful and a MAC may have more useful information
if there are multiple potential local sources.  Depending on the local
hardware there is usually a MAC address, but may have been stripped by
the time we see that packet, but I think it is worth adding, but not
sure the best way to do this if there is a second MAC for tunnelling,
etc...


Ok, with that guidance...  from the start of the message:

helpful		action, hook
useless?	len
helpful		inif, outif, mark
useless?	smac, dmac, macproto
helpful		protocol family
useless?	truncated
helpful		saddr, daddr
useless?	ipid
helpful		proto
useless?	frag
useless?	truncated
helpful		sport, dport
helpful		icmptype, icmpcode
helpful		secmark (I forgot to change it from "obj" to "secmark" in my patch).

I agree truncate is not helpful, neither is ipid or frag I'm guessing.  I'm not
sure what the 3 MAC fields give us, other than some idea of routing
information (which might actually be useful in this context due to the
ease of IP addr and port spoofing).  I'd be tempted to add a network
protocol field between mark and saddr.

That could potentially bring us down to 4 distinct messages with no useless fields:
-IP data	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto, sport, dport[, secmark]
-IP control	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto, icmptype, icmpcode[, secmark]
-other IP	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto[, secmark]
-other non-IP	-action, hook, inif, outif, mark, pfam[, secmark]

I'd like to see a CHAIN name in there, but that doesn't appear to be
available, so we'd have to make do with the "mark" field.

(I'd add DCCP/SCTP to TCP/UDP under data since it is trivial.)


Swinging fields in and out makes it very handy to use one message type
for all of them and can save precious disk bandwidth, but the point was
to normalize these messages.  Is that still realistic and necessary?  If
so, we're trying to find a balance between message type explosion and
disk bandwidth.  We either need to make this more fine-grained by
message type, ignore fields that aren't valid for that type indicated
with "unset", or swing fields in and out.


> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Thursday, February 9, 2017 6:49:38 PM EST Richard Guy Briggs wrote:
> On 2017-02-08 18:09, Paul Moore wrote:
> > On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> > >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> 
wrote:
> > >> > So while I'm not advocating this is what should be done and I'm
> > >> > trying
> > >> > to establish bounds to the scope of this feature, but would it be
> > >> > reasonable to simply not log packets that were transiting this
> > >> > machine
> > >> > without a local endpoint?
> > >> 
> > >> I'm still waiting on more detailed requirements information from
> > >> Steve, but based on what we've heard so far, it seems that ignoring
> > >> forwarded traffic is a reasonable thing to do.
> > > 
> > > OK, I have done the analysis to see where things stand on this ...
> > 
> > ...
> > 
> > > At this point, I would say there is no purpose for xt_AUDIT.c based on
> > > Common Criteria. It looks like its built in response to the
> > > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly
> > > deprecated.
> > 
> > Based on some off-list discussions with Richard it would appear that
> > there are several users of the NETFILTER_PKT record so I am in no
> > hurry to deprecate it.  Considering that there are no CC requirements
> > on the record, I think we can focus on simply providing a basic record
> > that satisfies the whims of the userspace tools without adding any
> > pain to the kernel.  I believe Richard is currently working on a
> > proposal to do that, let's discuss it further in that thread.
> 
> If there is no strict rule about turning any other type of record other than
> SYSCALLs into compound records, we could add the user credentials if they
> are identifyable without having a number of unset fields by using an
> auxilliary record.  If this isn't possible or desirable, we'd need to
> include those fields as unset in every message unless we discard
> messages for which there is no identifying information.

There's no actual rule on this, but its not expected and I'd have to check to 
see what this would do to the parsers. The main drawback is that just setting 
up an auxiliary record is going to eat 40 bytes without the record name. That 
will also make processing them more difficult because information is on multiple 
lines. And we'd need clear rules about what the last record is to know when 
the event is complete if they are interlaced.


> We probably don't want to trot out all the fields in a packet like
> tcpdump does, since many of them won't be of interest to us.  We want
> protocol family, end points, type of packet.  The ones that would be
> quite useful but may be hard to get are pid, auid, sessionid.
> 
> There is no packet for which all fields are valid.  This is why using
> "unset" values in those fields was suggested.
> 
> I'd start by splitting data from control protocols if we even need
> source/destination ports or icmp* details.  Those seem like pretty
> important details, so I think we need to start there.
> 
> I'd be inclined to use the same message type for IPv4 and IPv6 and just
> drop the IPv4-specific fields, or include them with the IPv6 record and
> set them to "unset" (ipid, frag).
> 
> As for the MAC (Media Access Control) addresses I'm not sure what to
> recommend.  We could fill them in with the outer MAC, we could leave them as
> unset or could just delete them entirely.
> 
> Source IP addresses can be easily spoofed, particularly for UDP, so they
> are not particularly useful and a MAC may have more useful information
> if there are multiple potential local sources.  Depending on the local
> hardware there is usually a MAC address, but may have been stripped by
> the time we see that packet, but I think it is worth adding, but not
> sure the best way to do this if there is a second MAC for tunnelling,
> etc...

I don't think audit should worry about spoofing. Yes it can be done, but we 
should accurately record what was presented to the system. Other tools can be 
employed to watch for arp spoofing and source routed packets. Its a biiger 
problem than just the audit logs.


> Ok, with that guidance...  from the start of the message:
> 
> helpful		action, hook
> useless?	len
> helpful		inif, outif, mark
> useless?	smac, dmac, macproto
> helpful		protocol family
> useless?	truncated
> helpful		saddr, daddr
> useless?	ipid
> helpful		proto
> useless?	frag
> useless?	truncated
> helpful		sport, dport
> helpful		icmptype, icmpcode
> helpful		secmark (I forgot to change it from "obj" to "secmark" in my
> patch).
> 
> I agree truncate is not helpful, neither is ipid or frag I'm guessing.  I'm
> not sure what the 3 MAC fields give us, other than some idea of routing
> information (which might actually be useful in this context due to the ease
> of IP addr and port spoofing).  I'd be tempted to add a network protocol
> field between mark and saddr.
> 
> That could potentially bring us down to 4 distinct messages with no useless
> fields: -IP data	-action, hook, inif, outif, mark, pfam, saddr, daddr,
> proto, sport, dport[, secmark] -IP control	-action, hook, inif, outif,
> mark, pfam, saddr, daddr, proto, icmptype, icmpcode[, secmark] -other
> IP	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto[, secmark]
> -other non-IP	-action, hook, inif, outif, mark, pfam[, secmark]

I'd want to see proto near the begining to guid interpretation of later fields.


> I'd like to see a CHAIN name in there, but that doesn't appear to be
> available, so we'd have to make do with the "mark" field.
> 
> (I'd add DCCP/SCTP to TCP/UDP under data since it is trivial.)
> 
> 
> Swinging fields in and out makes it very handy to use one message type
> for all of them and can save precious disk bandwidth, but the point was
> to normalize these messages.  Is that still realistic and necessary?

I prefer seeing 4 event types that follow an exact order everytime.

> If so, we're trying to find a balance between message type explosion and
> disk bandwidth. 

4 is not really an explosion. However, there is no actual requirement for 
these events any more. If we are going to keep them, the really should follow 
an exact order each time.

-Steve

> We either need to make this more fine-grained by
> message type, ignore fields that aren't valid for that type indicated
> with "unset", or swing fields in and out.

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-09 19:09, Steve Grubb wrote:
> On Thursday, February 9, 2017 6:49:38 PM EST Richard Guy Briggs wrote:
> > On 2017-02-08 18:09, Paul Moore wrote:
> > > On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> > > > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> > > >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com> 
> wrote:
> > > >> > So while I'm not advocating this is what should be done and I'm
> > > >> > trying
> > > >> > to establish bounds to the scope of this feature, but would it be
> > > >> > reasonable to simply not log packets that were transiting this
> > > >> > machine
> > > >> > without a local endpoint?
> > > >> 
> > > >> I'm still waiting on more detailed requirements information from
> > > >> Steve, but based on what we've heard so far, it seems that ignoring
> > > >> forwarded traffic is a reasonable thing to do.
> > > > 
> > > > OK, I have done the analysis to see where things stand on this ...
> > > 
> > > ...
> > > 
> > > > At this point, I would say there is no purpose for xt_AUDIT.c based on
> > > > Common Criteria. It looks like its built in response to the
> > > > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be cleanly
> > > > deprecated.
> > > 
> > > Based on some off-list discussions with Richard it would appear that
> > > there are several users of the NETFILTER_PKT record so I am in no
> > > hurry to deprecate it.  Considering that there are no CC requirements
> > > on the record, I think we can focus on simply providing a basic record
> > > that satisfies the whims of the userspace tools without adding any
> > > pain to the kernel.  I believe Richard is currently working on a
> > > proposal to do that, let's discuss it further in that thread.
> > 
> > If there is no strict rule about turning any other type of record other than
> > SYSCALLs into compound records, we could add the user credentials if they
> > are identifyable without having a number of unset fields by using an
> > auxilliary record.  If this isn't possible or desirable, we'd need to
> > include those fields as unset in every message unless we discard
> > messages for which there is no identifying information.
> 
> There's no actual rule on this, but its not expected and I'd have to check to 
> see what this would do to the parsers. The main drawback is that just setting 
> up an auxiliary record is going to eat 40 bytes without the record name. That 
> will also make processing them more difficult because information is on multiple 
> lines. And we'd need clear rules about what the last record is to know when 
> the event is complete if they are interlaced.

I agree it is not ideal.  So could you please commit to an alternative
that works so we can move forward?  The alternatives that I currently
see are to drop packets for which there is no local process ownership,
or to leave the ownership fields unset.
> 
> > We probably don't want to trot out all the fields in a packet like
> > tcpdump does, since many of them won't be of interest to us.  We want
> > protocol family, end points, type of packet.  The ones that would be
> > quite useful but may be hard to get are pid, auid, sessionid.
> > 
> > There is no packet for which all fields are valid.  This is why using
> > "unset" values in those fields was suggested.
> > 
> > I'd start by splitting data from control protocols if we even need
> > source/destination ports or icmp* details.  Those seem like pretty
> > important details, so I think we need to start there.
> > 
> > I'd be inclined to use the same message type for IPv4 and IPv6 and just
> > drop the IPv4-specific fields, or include them with the IPv6 record and
> > set them to "unset" (ipid, frag).
> > 
> > As for the MAC (Media Access Control) addresses I'm not sure what to
> > recommend.  We could fill them in with the outer MAC, we could leave them as
> > unset or could just delete them entirely.
> > 
> > Source IP addresses can be easily spoofed, particularly for UDP, so they
> > are not particularly useful and a MAC may have more useful information
> > if there are multiple potential local sources.  Depending on the local
> > hardware there is usually a MAC address, but may have been stripped by
> > the time we see that packet, but I think it is worth adding, but not
> > sure the best way to do this if there is a second MAC for tunnelling,
> > etc...
> 
> I don't think audit should worry about spoofing. Yes it can be done, but we 
> should accurately record what was presented to the system. Other tools can be 
> employed to watch for arp spoofing and source routed packets. Its a biiger 
> problem than just the audit logs.

I find this statement a bit surprising given we're trying to find out
who's doing what where.
> 
> > Ok, with that guidance...  from the start of the message:
> > 
> > helpful		action, hook
> > useless?	len
> > helpful		inif, outif, mark
> > useless?	smac, dmac, macproto
> > helpful		protocol family
> > useless?	truncated
> > helpful		saddr, daddr
> > useless?	ipid
> > helpful		proto
> > useless?	frag
> > useless?	truncated
> > helpful		sport, dport
> > helpful		icmptype, icmpcode
> > helpful		secmark (I forgot to change it from "obj" to "secmark" in my
> > patch).
> > 
> > I agree truncate is not helpful, neither is ipid or frag I'm guessing.  I'm
> > not sure what the 3 MAC fields give us, other than some idea of routing
> > information (which might actually be useful in this context due to the ease
> > of IP addr and port spoofing).  I'd be tempted to add a network protocol
> > field between mark and saddr.
> > 
> > That could potentially bring us down to 4 distinct messages with no useless
> > fields: -IP data	-action, hook, inif, outif, mark, pfam, saddr, daddr,
> > proto, sport, dport[, secmark] -IP control	-action, hook, inif, outif,
> > mark, pfam, saddr, daddr, proto, icmptype, icmpcode[, secmark] -other
> > IP	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto[, secmark]
> > -other non-IP	-action, hook, inif, outif, mark, pfam[, secmark]
> 
> I'd want to see proto near the begining to guid interpretation of later fields.

>From a network perspective that doesn't make sense, unless you flip
around the entire set of fields.  "pfam" is "protocol family", encoded
in the ethernet or hardware link headers to point to which address
family so we can decode the next two fields, then inside the "pfam"
header is a field that tells us the protocol, which helps us decode the
next two port/icmp fields.  Network folks using this are likely to care
about the order.  Is there a performance issue that concerns you?
> 
> > I'd like to see a CHAIN name in there, but that doesn't appear to be
> > available, so we'd have to make do with the "mark" field.
> > 
> > (I'd add DCCP/SCTP to TCP/UDP under data since it is trivial.)
> > 
> > 
> > Swinging fields in and out makes it very handy to use one message type
> > for all of them and can save precious disk bandwidth, but the point was
> > to normalize these messages.  Is that still realistic and necessary?
> 
> I prefer seeing 4 event types that follow an exact order everytime.

I am leaning this way myself.

> > If so, we're trying to find a balance between message type explosion and
> > disk bandwidth. 
> 
> 4 is not really an explosion. However, there is no actual requirement for 
> these events any more. If we are going to keep them, the really should follow 
> an exact order each time.

What about ownership information?  Do you have any suggestions how to
add this to what we have?

> -Steve
> 
> > We either need to make this more fine-grained by
> > message type, ignore fields that aren't valid for that type indicated
> > with "unset", or swing fields in and out.

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Thursday, February 9, 2017 8:12:47 PM EST Richard Guy Briggs wrote:
> On 2017-02-09 19:09, Steve Grubb wrote:
> > On Thursday, February 9, 2017 6:49:38 PM EST Richard Guy Briggs wrote:
> > > On 2017-02-08 18:09, Paul Moore wrote:
> > > > On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> 
wrote:
> > > > > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> > > > >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com>
> > 
> > wrote:
> > > > >> > So while I'm not advocating this is what should be done and I'm
> > > > >> > trying
> > > > >> > to establish bounds to the scope of this feature, but would it be
> > > > >> > reasonable to simply not log packets that were transiting this
> > > > >> > machine
> > > > >> > without a local endpoint?
> > > > >> 
> > > > >> I'm still waiting on more detailed requirements information from
> > > > >> Steve, but based on what we've heard so far, it seems that ignoring
> > > > >> forwarded traffic is a reasonable thing to do.
> > > > > 
> > > > > OK, I have done the analysis to see where things stand on this ...
> > > > 
> > > > ...
> > > > 
> > > > > At this point, I would say there is no purpose for xt_AUDIT.c based
> > > > > on
> > > > > Common Criteria. It looks like its built in response to the
> > > > > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be
> > > > > cleanly
> > > > > deprecated.
> > > > 
> > > > Based on some off-list discussions with Richard it would appear that
> > > > there are several users of the NETFILTER_PKT record so I am in no
> > > > hurry to deprecate it.  Considering that there are no CC requirements
> > > > on the record, I think we can focus on simply providing a basic record
> > > > that satisfies the whims of the userspace tools without adding any
> > > > pain to the kernel.  I believe Richard is currently working on a
> > > > proposal to do that, let's discuss it further in that thread.
> > > 
> > > If there is no strict rule about turning any other type of record other
> > > than SYSCALLs into compound records, we could add the user credentials
> > > if they are identifyable without having a number of unset fields by
> > > using an auxilliary record.  If this isn't possible or desirable, we'd
> > > need to include those fields as unset in every message unless we
> > > discard messages for which there is no identifying information.
> > 
> > There's no actual rule on this, but its not expected and I'd have to check
> > to see what this would do to the parsers. The main drawback is that just
> > setting up an auxiliary record is going to eat 40 bytes without the
> > record name. That will also make processing them more difficult because
> > information is on multiple lines. And we'd need clear rules about what
> > the last record is to know when the event is complete if they are
> > interlaced.
> 
> I agree it is not ideal.  So could you please commit to an alternative
> that works so we can move forward? 

I am trying to strongly discourage adding auxiliary records like we do for 
syscalls.

> The alternatives that I currently see are to drop packets for which there is
> no local process ownership, or to leave the ownership fields unset.

What ownership fields are we talking about?

> > > We probably don't want to trot out all the fields in a packet like
> > > tcpdump does, since many of them won't be of interest to us.  We want
> > > protocol family, end points, type of packet.  The ones that would be
> > > quite useful but may be hard to get are pid, auid, sessionid.
> > > 
> > > There is no packet for which all fields are valid.  This is why using
> > > "unset" values in those fields was suggested.
> > > 
> > > I'd start by splitting data from control protocols if we even need
> > > source/destination ports or icmp* details.  Those seem like pretty
> > > important details, so I think we need to start there.
> > > 
> > > I'd be inclined to use the same message type for IPv4 and IPv6 and just
> > > drop the IPv4-specific fields, or include them with the IPv6 record and
> > > set them to "unset" (ipid, frag).
> > > 
> > > As for the MAC (Media Access Control) addresses I'm not sure what to
> > > recommend.  We could fill them in with the outer MAC, we could leave
> > > them as unset or could just delete them entirely.
> > > 
> > > Source IP addresses can be easily spoofed, particularly for UDP, so they
> > > are not particularly useful and a MAC may have more useful information
> > > if there are multiple potential local sources.  Depending on the local
> > > hardware there is usually a MAC address, but may have been stripped by
> > > the time we see that packet, but I think it is worth adding, but not
> > > sure the best way to do this if there is a second MAC for tunnelling,
> > > etc...
> > 
> > I don't think audit should worry about spoofing. Yes it can be done, but
> > we should accurately record what was presented to the system. Other tools
> > can be employed to watch for arp spoofing and source routed packets. Its a
> > biiger problem than just the audit logs.
> 
> I find this statement a bit surprising given we're trying to find out
> who's doing what where.

We're just recording what's presented to the system that meets the rules 
programmed in.

> > > Ok, with that guidance...  from the start of the message:
> > > 
> > > helpful		action, hook
> > > useless?	len
> > > helpful		inif, outif, mark
> > > useless?	smac, dmac, macproto
> > > helpful		protocol family
> > > useless?	truncated
> > > helpful		saddr, daddr
> > > useless?	ipid
> > > helpful		proto
> > > useless?	frag
> > > useless?	truncated
> > > helpful		sport, dport
> > > helpful		icmptype, icmpcode
> > > helpful		secmark (I forgot to change it from "obj" to "secmark" in 
my
> > > patch).
> > > 
> > > I agree truncate is not helpful, neither is ipid or frag I'm guessing. 
> > > I'm
> > > not sure what the 3 MAC fields give us, other than some idea of routing
> > > information (which might actually be useful in this context due to the
> > > ease
> > > of IP addr and port spoofing).  I'd be tempted to add a network protocol
> > > field between mark and saddr.
> > > 
> > > That could potentially bring us down to 4 distinct messages with no
> > > useless
> > > fields: -IP data	-action, hook, inif, outif, mark, pfam, saddr, daddr,
> > > proto, sport, dport[, secmark] -IP control	-action, hook, inif, outif,
> > > mark, pfam, saddr, daddr, proto, icmptype, icmpcode[, secmark] -other
> > > IP	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto[,
> > > secmark]
> > > -other non-IP	-action, hook, inif, outif, mark, pfam[, secmark]
> > 
> > I'd want to see proto near the begining to guid interpretation of later
> > fields.
>
> From a network perspective that doesn't make sense, unless you flip
> around the entire set of fields.  "pfam" is "protocol family", encoded
> in the ethernet or hardware link headers to point to which address
> family so we can decode the next two fields, then inside the "pfam"
> header is a field that tells us the protocol, which helps us decode the
> next two port/icmp fields.  Network folks using this are likely to care
> about the order.  Is there a performance issue that concerns you?

Leave it as you proposed it.
 
> > > I'd like to see a CHAIN name in there, but that doesn't appear to be
> > > available, so we'd have to make do with the "mark" field.
> > > 
> > > (I'd add DCCP/SCTP to TCP/UDP under data since it is trivial.)
> > > 
> > > 
> > > Swinging fields in and out makes it very handy to use one message type
> > > for all of them and can save precious disk bandwidth, but the point was
> > > to normalize these messages.  Is that still realistic and necessary?
> > 
> > I prefer seeing 4 event types that follow an exact order everytime.
> 
> I am leaning this way myself.
> 
> > > If so, we're trying to find a balance between message type explosion and
> > > disk bandwidth.
> > 
> > 4 is not really an explosion. However, there is no actual requirement for
> > these events any more. If we are going to keep them, the really should
> > follow an exact order each time.
> 
> What about ownership information?  Do you have any suggestions how to
> add this to what we have?

What ownership information are you talking about?

-Steve

> > > We either need to make this more fine-grained by
> > > message type, ignore fields that aren't valid for that type indicated
> > > with "unset", or swing fields in and out.
> 
> - RGB
> 
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-10 17:39, Steve Grubb wrote:
> On Thursday, February 9, 2017 8:12:47 PM EST Richard Guy Briggs wrote:
> > On 2017-02-09 19:09, Steve Grubb wrote:
> > > On Thursday, February 9, 2017 6:49:38 PM EST Richard Guy Briggs wrote:
> > > > On 2017-02-08 18:09, Paul Moore wrote:
> > > > > On Wed, Feb 8, 2017 at 11:30 AM, Steve Grubb <sgrubb@redhat.com> 
> wrote:
> > > > > > On Tuesday, February 7, 2017 10:56:39 PM EST Paul Moore wrote:
> > > > > >> On Tue, Feb 7, 2017 at 3:52 PM, Richard Guy Briggs <rgb@redhat.com>
> > > 
> > > wrote:
> > > > > >> > So while I'm not advocating this is what should be done and I'm
> > > > > >> > trying
> > > > > >> > to establish bounds to the scope of this feature, but would it be
> > > > > >> > reasonable to simply not log packets that were transiting this
> > > > > >> > machine
> > > > > >> > without a local endpoint?
> > > > > >> 
> > > > > >> I'm still waiting on more detailed requirements information from
> > > > > >> Steve, but based on what we've heard so far, it seems that ignoring
> > > > > >> forwarded traffic is a reasonable thing to do.
> > > > > > 
> > > > > > OK, I have done the analysis to see where things stand on this ...
> > > > > 
> > > > > ...
> > > > > 
> > > > > > At this point, I would say there is no purpose for xt_AUDIT.c based
> > > > > > on
> > > > > > Common Criteria. It looks like its built in response to the
> > > > > > CONFIG_NETFILTER_XT_TARGET_AUDIT config option. So, it can be
> > > > > > cleanly
> > > > > > deprecated.
> > > > > 
> > > > > Based on some off-list discussions with Richard it would appear that
> > > > > there are several users of the NETFILTER_PKT record so I am in no
> > > > > hurry to deprecate it.  Considering that there are no CC requirements
> > > > > on the record, I think we can focus on simply providing a basic record
> > > > > that satisfies the whims of the userspace tools without adding any
> > > > > pain to the kernel.  I believe Richard is currently working on a
> > > > > proposal to do that, let's discuss it further in that thread.
> > > > 
> > > > If there is no strict rule about turning any other type of record other
> > > > than SYSCALLs into compound records, we could add the user credentials
> > > > if they are identifyable without having a number of unset fields by
> > > > using an auxilliary record.  If this isn't possible or desirable, we'd
> > > > need to include those fields as unset in every message unless we
> > > > discard messages for which there is no identifying information.
> > > 
> > > There's no actual rule on this, but its not expected and I'd have to check
> > > to see what this would do to the parsers. The main drawback is that just
> > > setting up an auxiliary record is going to eat 40 bytes without the
> > > record name. That will also make processing them more difficult because
> > > information is on multiple lines. And we'd need clear rules about what
> > > the last record is to know when the event is complete if they are
> > > interlaced.
> > 
> > I agree it is not ideal.  So could you please commit to an alternative
> > that works so we can move forward? 
> 
> I am trying to strongly discourage adding auxiliary records like we do for 
> syscalls.

I get that.  I'm trying to figure out other ways of approaching the issue.

> > The alternatives that I currently see are to drop packets for which there is
> > no local process ownership, or to leave the ownership fields unset.
> 
> What ownership fields are we talking about?

The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
terminology.  What technical term is there for the collection of subject
identifiers?

> > > > We probably don't want to trot out all the fields in a packet like
> > > > tcpdump does, since many of them won't be of interest to us.  We want
> > > > protocol family, end points, type of packet.  The ones that would be
> > > > quite useful but may be hard to get are pid, auid, sessionid.
> > > > 
> > > > There is no packet for which all fields are valid.  This is why using
> > > > "unset" values in those fields was suggested.
> > > > 
> > > > I'd start by splitting data from control protocols if we even need
> > > > source/destination ports or icmp* details.  Those seem like pretty
> > > > important details, so I think we need to start there.
> > > > 
> > > > I'd be inclined to use the same message type for IPv4 and IPv6 and just
> > > > drop the IPv4-specific fields, or include them with the IPv6 record and
> > > > set them to "unset" (ipid, frag).
> > > > 
> > > > As for the MAC (Media Access Control) addresses I'm not sure what to
> > > > recommend.  We could fill them in with the outer MAC, we could leave
> > > > them as unset or could just delete them entirely.
> > > > 
> > > > Source IP addresses can be easily spoofed, particularly for UDP, so they
> > > > are not particularly useful and a MAC may have more useful information
> > > > if there are multiple potential local sources.  Depending on the local
> > > > hardware there is usually a MAC address, but may have been stripped by
> > > > the time we see that packet, but I think it is worth adding, but not
> > > > sure the best way to do this if there is a second MAC for tunnelling,
> > > > etc...
> > > 
> > > I don't think audit should worry about spoofing. Yes it can be done, but
> > > we should accurately record what was presented to the system. Other tools
> > > can be employed to watch for arp spoofing and source routed packets. Its a
> > > biiger problem than just the audit logs.
> > 
> > I find this statement a bit surprising given we're trying to find out
> > who's doing what where.
> 
> We're just recording what's presented to the system that meets the rules 
> programmed in.

I don't quite understand.  Are you saying only display the fields that
were specifically used in the netfilter rule to trigger the target that
records a packet?  I don't think that's what you want and it isn't easy
to get without being more invasive in netfilter and swinging fields.
I'd record the MAC header since it is part of the packet that tells us
where it came from and where it's going.

> > > > Ok, with that guidance...  from the start of the message:
> > > > 
> > > > helpful		action, hook
> > > > useless?	len
> > > > helpful		inif, outif, mark
> > > > useless?	smac, dmac, macproto
> > > > helpful		protocol family
> > > > useless?	truncated
> > > > helpful		saddr, daddr
> > > > useless?	ipid
> > > > helpful		proto
> > > > useless?	frag
> > > > useless?	truncated
> > > > helpful		sport, dport
> > > > helpful		icmptype, icmpcode
> > > > helpful		secmark (I forgot to change it from "obj" to "secmark" in 
> my
> > > > patch).
> > > > 
> > > > I agree truncate is not helpful, neither is ipid or frag I'm guessing. 
> > > > I'm
> > > > not sure what the 3 MAC fields give us, other than some idea of routing
> > > > information (which might actually be useful in this context due to the
> > > > ease
> > > > of IP addr and port spoofing).  I'd be tempted to add a network protocol
> > > > field between mark and saddr.
> > > > 
> > > > That could potentially bring us down to 4 distinct messages with no
> > > > useless
> > > > fields: -IP data	-action, hook, inif, outif, mark, pfam, saddr, daddr,
> > > > proto, sport, dport[, secmark] -IP control	-action, hook, inif, outif,
> > > > mark, pfam, saddr, daddr, proto, icmptype, icmpcode[, secmark] -other
> > > > IP	-action, hook, inif, outif, mark, pfam, saddr, daddr, proto[,
> > > > secmark]
> > > > -other non-IP	-action, hook, inif, outif, mark, pfam[, secmark]
> > > 
> > > I'd want to see proto near the begining to guid interpretation of later
> > > fields.
> >
> > From a network perspective that doesn't make sense, unless you flip
> > around the entire set of fields.  "pfam" is "protocol family", encoded
> > in the ethernet or hardware link headers to point to which address
> > family so we can decode the next two fields, then inside the "pfam"
> > header is a field that tells us the protocol, which helps us decode the
> > next two port/icmp fields.  Network folks using this are likely to care
> > about the order.  Is there a performance issue that concerns you?
> 
> Leave it as you proposed it.

Thanks.

> > > > I'd like to see a CHAIN name in there, but that doesn't appear to be
> > > > available, so we'd have to make do with the "mark" field.
> > > > 
> > > > (I'd add DCCP/SCTP to TCP/UDP under data since it is trivial.)
> > > > 
> > > > 
> > > > Swinging fields in and out makes it very handy to use one message type
> > > > for all of them and can save precious disk bandwidth, but the point was
> > > > to normalize these messages.  Is that still realistic and necessary?
> > > 
> > > I prefer seeing 4 event types that follow an exact order everytime.
> > 
> > I am leaning this way myself.
> > 
> > > > If so, we're trying to find a balance between message type explosion and
> > > > disk bandwidth.
> > > 
> > > 4 is not really an explosion. However, there is no actual requirement for
> > > these events any more. If we are going to keep them, the really should
> > > follow an exact order each time.
> > 
> > What about ownership information?  Do you have any suggestions how to
> > add this to what we have?
> 
> What ownership information are you talking about?

The information I'm surprised you haven't raised this time as missing.

> -Steve
> 
> > > > We either need to make this more fine-grained by
> > > > message type, ignore fields that aren't valid for that type indicated
> > > > with "unset", or swing fields in and out.
> > 
> > - RGB

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote:
> On 2017-02-10 17:39, Steve Grubb wrote:
> > > The alternatives that I currently see are to drop packets for which
> > > there is no local process ownership, or to leave the ownership fields
> > > unset.> 
>
> > What ownership fields are we talking about?
> 
> The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> terminology.  What technical term is there for the collection of subject
> identifiers?

Subject attributes.

 
> > > > I don't think audit should worry about spoofing. Yes it can be done,
> > > > but we should accurately record what was presented to the system.
> > > > Other tools can be employed to watch for arp spoofing and source routed
> > > > packets. Its a bigger problem than just the audit logs.
> > > 
> > > I find this statement a bit surprising given we're trying to find out
> > > who's doing what where.
> > 
> > We're just recording what's presented to the system that meets the rules
> > programmed in.
> 
> I don't quite understand.  Are you saying only display the fields that
> were specifically used in the netfilter rule to trigger the target that
> records a packet?

No. I'm saying we shouldn't do any processing to figure out if we have a 
spoofed or source routed packet. There are other tools that do that kind of 
thing.


> I don't think that's what you want and it isn't easy
> to get without being more invasive in netfilter and swinging fields.
> I'd record the MAC header since it is part of the packet that tells us
> where it came from and where it's going.

Do we really need the MAC header for every event? I really don't think so.

-Steve

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-13 12:57, Steve Grubb wrote:
> On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote:
> > On 2017-02-10 17:39, Steve Grubb wrote:
> > > > The alternatives that I currently see are to drop packets for which
> > > > there is no local process ownership, or to leave the ownership fields
> > > > unset.> 
> >
> > > What ownership fields are we talking about?
> > 
> > The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> > terminology.  What technical term is there for the collection of subject
> > identifiers?
> 
> Subject attributes.

Ah ok, I'll try to remember to use that term...

Now that you know what I'm talking about, can you go back and answer the
questions I had about packet "ownership" (which is really packet subject
attributes)?  If we have that information, how to we include it in the
message format?  And if we don't have it, do we ignore the packet, or do
we swing fields out, or do we set those fields to "unset" or do we use
an auxiliary record?

> > > > > I don't think audit should worry about spoofing. Yes it can be done,
> > > > > but we should accurately record what was presented to the system.
> > > > > Other tools can be employed to watch for arp spoofing and source routed
> > > > > packets. Its a bigger problem than just the audit logs.
> > > > 
> > > > I find this statement a bit surprising given we're trying to find out
> > > > who's doing what where.
> > > 
> > > We're just recording what's presented to the system that meets the rules
> > > programmed in.
> > 
> > I don't quite understand.  Are you saying only display the fields that
> > were specifically used in the netfilter rule to trigger the target that
> > records a packet?
> 
> No. I'm saying we shouldn't do any processing to figure out if we have a 
> spoofed or source routed packet. There are other tools that do that kind of 
> thing.

I never suggested that.  I only suggested including that information so
that some other tool actually has the information to work with.

> > I don't think that's what you want and it isn't easy
> > to get without being more invasive in netfilter and swinging fields.
> > I'd record the MAC header since it is part of the packet that tells us
> > where it came from and where it's going.
> 
> Do we really need the MAC header for every event? I really don't think so.

It certainly makes my job simpler to just ignore the MAC header and
avoid complicating things, but if I were a network admin and a packet
came in that I wasn't expecting because of other network rules that had
been set up to prevent it, I'd want more information to figure out why.

> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-13 12:57, Steve Grubb wrote:
>> On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote:
>> > On 2017-02-10 17:39, Steve Grubb wrote:
>> > > > The alternatives that I currently see are to drop packets for which
>> > > > there is no local process ownership, or to leave the ownership fields
>> > > > unset.>
>> >
>> > > What ownership fields are we talking about?
>> >
>> > The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
>> > terminology.  What technical term is there for the collection of subject
>> > identifiers?
>>
>> Subject attributes.
>
> Ah ok, I'll try to remember to use that term...
>
> Now that you know what I'm talking about, can you go back and answer the
> questions I had about packet "ownership" (which is really packet subject
> attributes)?  If we have that information, how to we include it in the
> message format?  And if we don't have it, do we ignore the packet, or do
> we swing fields out, or do we set those fields to "unset" or do we use
> an auxiliary record?

Packet "ownership" is likely going to be impossible to determine
reliably since in some cases you can't even match a packet to a
socket, let alone a process.  To back up a few messages in this
thread, to Richard's list of things to potentially log:

> helpful         action, hook

I haven't checked, but do we allow setting of an audit key in
NETFILTER_PKT records?  It seems like that might be a good thing for
the userspace tools and would likely make logging the action/hook
unncessary.

> useless?        len

I don't see much point in this.

> helpful         inif, outif, mark

Let's split this into two things: the interfaces and the mark.  I
don't see much value in logging the mark, but I could see some value
in logging the interface.

> useless?        smac, dmac, macproto

Probably useless in the majority of use cases.

> helpful         protocol family

I think we need some clarity on protocol logging; we've got "macproto"
(I assume this is the ethertype, or similar), "protocol family" (I
assume this to be a duplicate of ethertype, e.g. AF_INET), and "proto"
(see below, I assume this to be TCP/UDP/etc.).

> useless?        truncated

Definitely useless.  Only keep this if we need it for some backwards
compatibility.

> helpful         saddr, daddr

Helpful.

> useless?        ipid

Useless.

> helpful         proto
> helpful         sport, dport

Assuming "proto" means the TCP/UDP/etc. then we should treat the
proto/ports as one block; you can't log the ports without logging
"proto".

> useless?        frag
> useless?        truncated

Yes, useless.

> helpful         icmptype, icmpcode

Similar to proto/port above.

> helpful         secmark (I forgot to change it from "obj" to "secmark" in my patch).

We may also want to log the peer label if we are going to log the secmark.

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-13 18:50, Paul Moore wrote:
> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-02-13 12:57, Steve Grubb wrote:
> >> On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote:
> >> > On 2017-02-10 17:39, Steve Grubb wrote:
> >> > > > The alternatives that I currently see are to drop packets for which
> >> > > > there is no local process ownership, or to leave the ownership fields
> >> > > > unset.>
> >> >
> >> > > What ownership fields are we talking about?
> >> >
> >> > The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> >> > terminology.  What technical term is there for the collection of subject
> >> > identifiers?
> >>
> >> Subject attributes.
> >
> > Ah ok, I'll try to remember to use that term...
> >
> > Now that you know what I'm talking about, can you go back and answer the
> > questions I had about packet "ownership" (which is really packet subject
> > attributes)?  If we have that information, how to we include it in the
> > message format?  And if we don't have it, do we ignore the packet, or do
> > we swing fields out, or do we set those fields to "unset" or do we use
> > an auxiliary record?
> 
> Packet "ownership" is likely going to be impossible to determine
> reliably since in some cases you can't even match a packet to a
> socket, let alone a process.  To back up a few messages in this
> thread, to Richard's list of things to potentially log:
> 
> > helpful         action, hook
> 
> I haven't checked, but do we allow setting of an audit key in
> NETFILTER_PKT records?  It seems like that might be a good thing for
> the userspace tools and would likely make logging the action/hook
> unncessary.

Not that I am aware of.  That would be way useful if it were possible.
"AUDIT" is a netfilter target and you can set the type to "accept",
"drop" or "reject".  Similarly, having the sub-chain name would be
useful but that doesn't appear to be available either.  This is why I
used a "mark" in the testsuite to track packets.

> > useless?        len
> 
> I don't see much point in this.
> 
> > helpful         inif, outif, mark
> 
> Let's split this into two things: the interfaces and the mark.  I
> don't see much value in logging the mark, but I could see some value
> in logging the interface.

In fact, the mark I found to be a useful way to track which rule was
involved and I'd be pretty surprised if others don't try to do the same.

> > useless?        smac, dmac, macproto
> 
> Probably useless in the majority of use cases.

How do we deal with the minority of cases where it could be quite useful?

> > helpful         protocol family
> 
> I think we need some clarity on protocol logging; we've got "macproto"
> (I assume this is the ethertype, or similar), "protocol family" (I
> assume this to be a duplicate of ethertype, e.g. AF_INET), and "proto"
> (see below, I assume this to be TCP/UDP/etc.).

Sorry, you are right.  I know that field as "ethertype" which defines
the "protocol family" (network layer protocol, IPv4/6, etc...).  "proto"
is the transport layer protocol.  For some reason, I was thinking
"macproto" was the link layer type, but that's obvious from the media.

> > useless?        truncated
> 
> Definitely useless.  Only keep this if we need it for some backwards
> compatibility.
> 
> > helpful         saddr, daddr
> 
> Helpful.
> 
> > useless?        ipid
> 
> Useless.
> 
> > helpful         proto
> > helpful         sport, dport
> 
> Assuming "proto" means the TCP/UDP/etc. then we should treat the
> proto/ports as one block; you can't log the ports without logging
> "proto".
> 
> > useless?        frag
> > useless?        truncated
> 
> Yes, useless.
> 
> > helpful         icmptype, icmpcode
> 
> Similar to proto/port above.
> 
> > helpful         secmark (I forgot to change it from "obj" to "secmark" in my patch).
> 
> We may also want to log the peer label if we are going to log the secmark.

Ok, noted.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-13 18:50, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:

...

>> > useless?        smac, dmac, macproto
>>
>> Probably useless in the majority of use cases.
>
> How do we deal with the minority of cases where it could be quite useful?

First you first need to show me why I should care about this, in other
words, why *must* you have the fields in the audit record.

>> > helpful         secmark (I forgot to change it from "obj" to "secmark" in my patch).
>>
>> We may also want to log the peer label if we are going to log the secmark.
>
> Ok, noted.

Please note well the "*if*" portion in the above statement.  I'm not
overly convinced that either field is all that useful in the majority
of cases.

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Steve Grubb]

On Monday, February 13, 2017 3:50:05 PM EST Richard Guy Briggs wrote:
> > > > > The alternatives that I currently see are to drop packets for which
> > > > > there is no local process ownership, or to leave the ownership
> > > > > fields unset.
> > > > 
> > > > What ownership fields are we talking about?
> > > 
> > > The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> > > terminology.  What technical term is there for the collection of subject
> > > identifiers?
> > 
> > Subject attributes.
> 
> Ah ok, I'll try to remember to use that term...
> 
> Now that you know what I'm talking about, can you go back and answer the
> questions I had about packet "ownership" (which is really packet subject
> attributes)? 

The format for subject attributes would be:
pid, uid, auid, ses, subj, comm, exe, ...then whatever else you want to add

This also goes for the netfilter_cfg events.

> If we have that information, how to we include it in the
> message format?  And if we don't have it, do we ignore the packet, or do
> we swing fields out, or do we set those fields to "unset" or do we use
> an auxiliary record?

If you have this for the majority of events, I'd say leave it unset when you 
don't. We really don't care about packets that simply transit through the 
system. Also, I suppose it depends on what kind of packet it is. For example, 
a icmp echo sent to the machine that is blocked is obviously not going to have 
an owner. But one originating in the machine heading out should.

-Steve

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-13 18:50, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:

...

>> > helpful         action, hook
>>
>> I haven't checked, but do we allow setting of an audit key in
>> NETFILTER_PKT records?  It seems like that might be a good thing for
>> the userspace tools and would likely make logging the action/hook
>> unncessary.
>
> Not that I am aware of.  That would be way useful if it were possible.
> "AUDIT" is a netfilter target and you can set the type to "accept",
> "drop" or "reject".  Similarly, having the sub-chain name would be
> useful but that doesn't appear to be available either.  This is why I
> used a "mark" in the testsuite to track packets.

I've been thinking about this off and on and I think you are on to
something here ... the netfilter mark is very similar to what we do
with the audit keys and the audit-folk on this thread already know how
helpful audit keys can be for associating records with a specific [set
of] audit rules; I'm thinking we should treat the netfilter mark the
same way, after all, this is very much in keeping with how
netfilter/iptables uses the mark data.  In an effort to simplify
things greatly for the NETFILTER_PKT record I'm going to offer the
following suggestion:

* Limit NETFILTER_PKT fields to only those present in the IPv4/IPv6
header, e.g. src/dest addresses and next level protocol, and the
netfilter mark.
* Teach ausearch and the other relevant audit userspace tools to
search on the netfilter mark much like they currently search on the
audit key.

This puts a reasonable bound on the fields in the NETFILTER_PKT record
and insulates us from protocol specifics (both very desirable things);
I also think we should be able to do this without having to introduce
a new record, e.g. NETFILTER_PKT2 (another big win).  Any additional
packet information can be conveyed by the netfilter mark and careful
netfilter rule construction.

What do you think Richard?

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-14 16:31, Steve Grubb wrote:
> On Monday, February 13, 2017 3:50:05 PM EST Richard Guy Briggs wrote:
> > > > > > The alternatives that I currently see are to drop packets for which
> > > > > > there is no local process ownership, or to leave the ownership
> > > > > > fields unset.
> > > > > 
> > > > > What ownership fields are we talking about?
> > > > 
> > > > The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> > > > terminology.  What technical term is there for the collection of subject
> > > > identifiers?
> > > 
> > > Subject attributes.
> > 
> > Ah ok, I'll try to remember to use that term...
> > 
> > Now that you know what I'm talking about, can you go back and answer the
> > questions I had about packet "ownership" (which is really packet subject
> > attributes)? 
> 
> The format for subject attributes would be:
> pid, uid, auid, ses, subj, comm, exe, ...then whatever else you want to add
> 
> This also goes for the netfilter_cfg events.

Ok, this I can deal with.  Thank you.

> > If we have that information, how to we include it in the
> > message format?  And if we don't have it, do we ignore the packet, or do
> > we swing fields out, or do we set those fields to "unset" or do we use
> > an auxiliary record?
> 
> If you have this for the majority of events, I'd say leave it unset when you 
> don't. We really don't care about packets that simply transit through the 
> system. Also, I suppose it depends on what kind of packet it is. For example, 
> a icmp echo sent to the machine that is blocked is obviously not going to have 
> an owner. But one originating in the machine heading out should.

I'll add them to the message format and leave them unset if we have no
information.

The way that the AUDIT target is used by users is going to determine
what is the majority of events.  The user has complete freedom to set up
rules such that all of them only log packets transiting the system, but
this is clearly not the intent of this record.

This sounds like it deserves a blog post to clarify the intent and the
limitations and/or an update to the xt_AUDIT manpage.

> -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-15 19:32, Paul Moore wrote:
> On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-02-13 18:50, Paul Moore wrote:
> >> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> ...
> 
> >> > helpful         action, hook
> >>
> >> I haven't checked, but do we allow setting of an audit key in
> >> NETFILTER_PKT records?  It seems like that might be a good thing for
> >> the userspace tools and would likely make logging the action/hook
> >> unncessary.
> >
> > Not that I am aware of.  That would be way useful if it were possible.
> > "AUDIT" is a netfilter target and you can set the type to "accept",
> > "drop" or "reject".  Similarly, having the sub-chain name would be
> > useful but that doesn't appear to be available either.  This is why I
> > used a "mark" in the testsuite to track packets.
> 
> I've been thinking about this off and on and I think you are on to
> something here ... the netfilter mark is very similar to what we do
> with the audit keys and the audit-folk on this thread already know how
> helpful audit keys can be for associating records with a specific [set
> of] audit rules; I'm thinking we should treat the netfilter mark the
> same way, after all, this is very much in keeping with how
> netfilter/iptables uses the mark data.

I felt like I was kind of cheating to use it, but no other fine-grained
method was evident to me when I wrote that test script.  In a test
script it is a controlled environment with no other conflicting users.

My thoughts were that use of it as a key for tracking audit events
itself might not be as viable due to other uses of the nfmark.

What it comes down to is simply spending a bit more careful design
effort to have the uses of nfmark co-exist since I don't see any
inherent conflicts.

>  In an effort to simplify
> things greatly for the NETFILTER_PKT record I'm going to offer the
> following suggestion:
> 
> * Limit NETFILTER_PKT fields to only those present in the IPv4/IPv6
> header, e.g. src/dest addresses and next level protocol, and the
> netfilter mark.

(I'd start with: mark, saddr, daddr, proto)

That seems a bit oversimplified, requiring a lot more effort and lists
of rules to track down different application-layer protocols (ports).

This reminds me of Rusty's sig a while back "Premature optmztion is rt
of all evl."  ;-)

There are a limited number of actions, hooks, interfaces and protocol
families, so this seems plausibly reasonable to ditch in favour of
nfmark, but all of these would just need to be re-coded in the nfmark if
needed, although the typical assumption about number of interfaces may
be naive for those users who may find this sort of auditing very useful.
(I'm thinking of network appliances.)

It would be tempting to just keep the reports of data packets
(TCP/UDP...) and forego the control packets (ICMP) but that somehow
seems like cheating and irresponsible.

I'm still inclined to keep the 4 message types proposed, minimum data
and control, then the other two as more general catchers.

> * Teach ausearch and the other relevant audit userspace tools to
> search on the netfilter mark much like they currently search on the
> audit key.

That sounds potentially useful, and until that happens, a user could
pull together a perl or python script to deal with them.

> This puts a reasonable bound on the fields in the NETFILTER_PKT record
> and insulates us from protocol specifics (both very desirable things);

Steve has requested the subject attributes which prefixes 7 fields.

If you are ditching port numbers, then it seems reasonable to ditch IP
addresses too, at which point all we keep is the subject attributes and
the nfmark which could be argued should be enough.  What's the point in
keeping the protocol if we don't keep the source and destination ports?

> I also think we should be able to do this without having to introduce
> a new record, e.g. NETFILTER_PKT2 (another big win).  Any additional
> packet information can be conveyed by the netfilter mark and careful
> netfilter rule construction.

I'm sure sure either way if we are absolved from introducing a new
record type since we are changing the existing one.

> What do you think Richard?

There's my thoughts.  I'd love to get some from users.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-14 16:06, Paul Moore wrote:
> On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-02-13 18:50, Paul Moore wrote:
> >> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> 
> ...
> 
> >> > useless?        smac, dmac, macproto
> >>
> >> Probably useless in the majority of use cases.
> >
> > How do we deal with the minority of cases where it could be quite useful?
> 
> First you first need to show me why I should care about this, in other
> words, why *must* you have the fields in the audit record.

Well, as I've just argued in my other reply, the only fields that are a
*must* are the subject attributes and the nfmark.

You've jettisoned the ports while keeping the addresses, which puzzles
me other than for expediancy.

MAC, IP and ports can all be spoofed, each layer easier as you get
higher, but it is all potentially useful information.

> >> > helpful         secmark (I forgot to change it from "obj" to "secmark" in my patch).
> >>
> >> We may also want to log the peer label if we are going to log the secmark.
> >
> > Ok, noted.
> 
> Please note well the "*if*" portion in the above statement.  I'm not
> overly convinced that either field is all that useful in the majority
> of cases.

Thank you for that reminder to link the two.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

[NOTE: I'll respond back to the other part of your email later but I'm
running out of time in the day and this was a quick but important
response]

On Thu, Feb 16, 2017 at 5:36 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> Steve has requested the subject attributes which prefixes 7 fields.

I already commented on this earlier in this thread - or some other
related thread, I've lost track, but both you and Steve were on the
To/CC line - last time I checked, you can't reliably link packets to
the sender/subject in the netfilter hooks (I'll be shocked if this has
changed).  The best you can do in some cases is to link the packet to
the socket, and that isn't going to help you.

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-16 20:57, Paul Moore wrote:
> [NOTE: I'll respond back to the other part of your email later but I'm
> running out of time in the day and this was a quick but important
> response]
> 
> On Thu, Feb 16, 2017 at 5:36 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > Steve has requested the subject attributes which prefixes 7 fields.
> 
> I already commented on this earlier in this thread - or some other
> related thread, I've lost track, but both you and Steve were on the
> To/CC line - last time I checked, you can't reliably link packets to
> the sender/subject in the netfilter hooks (I'll be shocked if this has
> changed).  The best you can do in some cases is to link the packet to
> the socket, and that isn't going to help you.

Ok, thanks for this clarification.  Maybe I'm mis-remembering what user
information is available in software interrupts rather than user
context.  This will need more investigation...

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: AUDIT_NETFILTER_PKT message format

[Paul Moore]

On Thu, Feb 16, 2017 at 5:36 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2017-02-15 19:32, Paul Moore wrote:
>> On Mon, Feb 13, 2017 at 7:24 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2017-02-13 18:50, Paul Moore wrote:
>> >> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
>>
>> ...
>>
>> >> > helpful         action, hook
>> >>
>> >> I haven't checked, but do we allow setting of an audit key in
>> >> NETFILTER_PKT records?  It seems like that might be a good thing for
>> >> the userspace tools and would likely make logging the action/hook
>> >> unncessary.
>> >
>> > Not that I am aware of.  That would be way useful if it were possible.
>> > "AUDIT" is a netfilter target and you can set the type to "accept",
>> > "drop" or "reject".  Similarly, having the sub-chain name would be
>> > useful but that doesn't appear to be available either.  This is why I
>> > used a "mark" in the testsuite to track packets.
>>
>> I've been thinking about this off and on and I think you are on to
>> something here ... the netfilter mark is very similar to what we do
>> with the audit keys and the audit-folk on this thread already know how
>> helpful audit keys can be for associating records with a specific [set
>> of] audit rules; I'm thinking we should treat the netfilter mark the
>> same way, after all, this is very much in keeping with how
>> netfilter/iptables uses the mark data.
>
> I felt like I was kind of cheating to use it, but no other fine-grained
> method was evident to me when I wrote that test script.  In a test
> script it is a controlled environment with no other conflicting users.
>
> My thoughts were that use of it as a key for tracking audit events
> itself might not be as viable due to other uses of the nfmark.
>
> What it comes down to is simply spending a bit more careful design
> effort to have the uses of nfmark co-exist since I don't see any
> inherent conflicts.

I think it is safe to say that anyone who is going to the trouble of
using NETFILTER_PKT is going to have a well considered security
configuration.  I don't view using the nfmark as a shorthand for audit
to help identify complex netfilter matches to be a major ask in these
situations, and it seems in keeping with the intent of the nfmark
concept.

>>  In an effort to simplify
>> things greatly for the NETFILTER_PKT record I'm going to offer the
>> following suggestion:
>>
>> * Limit NETFILTER_PKT fields to only those present in the IPv4/IPv6
>> header, e.g. src/dest addresses and next level protocol, and the
>> netfilter mark.
>
> (I'd start with: mark, saddr, daddr, proto)

Yeah, that's what I said ;)

> That seems a bit oversimplified, requiring a lot more effort and lists
> of rules to track down different application-layer protocols (ports).

I relies more heavily on the nfmark as discussed above.

> This reminds me of Rusty's sig a while back "Premature optmztion is rt
> of all evl."  ;-)

Perhaps this is being nitpicky, but you optimize something for a given
set of requirements, something which we are lacking here.  This isn't
an optimization, but rather a simplified approach brought about by a
lack of requirements.

Right now the only real requirement we have is that Steve would like
something a bit more predictable in the NETFILTER_PKT record
<insert-my-usual-comments-about-the-audit-kernel/userspace-API-being-a-pile-of-garbage>.
While we have indications that people are using this in the wild, they
aren't letting their voices be heard here, or anywhere else that we
can see, so I'd like to focus on a solution that satisfies Steve and
doesn't burden us in the future in case we have to start adding
additional fields/records.  This is why I'm thinking of limiting us to
just the IP layer information + the nfmark; this should provide a
fairly rich capability without saddling us with a lot of baggage to
worry about in the future.  I do agree that it does add some
administrative setup cost, but as I said earlier, those admins who
make use of this are likely already used to dealing with a high setup
cost.

I *really* don't want to add a bunch of new records and fields for a
bit of functionality with uncertain usage and requirements; that
almost never works out well for anyone, especially those who have to
maintain that crap for the long term.

> There are a limited number of actions, hooks, interfaces and protocol
> families, so this seems plausibly reasonable to ditch in favour of
> nfmark, but all of these would just need to be re-coded in the nfmark if
> needed, although the typical assumption about number of interfaces may
> be naive for those users who may find this sort of auditing very useful.
> (I'm thinking of network appliances.)

... this is a good time to point out that trying to arrive at a set of
fields that fully satisfies every use case that comes our way is going
to be impossible at worst, and increasingly frustrating at best.  I
think we are always going to need to rely on the nfmark to some
extent, let's admit that now and make our lives easier; if we hear
from users (e.g. actual requirements!) in the future we can always add
new fields/records to make their lives easier.

>> * Teach ausearch and the other relevant audit userspace tools to
>> search on the netfilter mark much like they currently search on the
>> audit key.
>
> That sounds potentially useful, and until that happens, a user could
> pull together a perl or python script to deal with them.

Granted I'm stubborn and ornery, but I still do most of lot of log
spelunking with grep and friends.

-- 
paul moore
www.paul-moore.com

Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-13 19:24, Richard Guy Briggs wrote:
> On 2017-02-13 18:50, Paul Moore wrote:
> > On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > > useless?        smac, dmac, macproto
> > 
> > Probably useless in the majority of use cases.
> 
> How do we deal with the minority of cases where it could be quite useful?

It turns out this was required for ebtables support.
	https://bugzilla.redhat.com/show_bug.cgi?id=642391#c6

> > > - RGB
> > 
> > paul moore
> 
> - RGB

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635