Use case not covered by the audit library?

Use case not covered by the audit library?

[Gulland, Scott A]

Hi,

I have a fairly common use case that I'm not sure is covered by the audit library and I need some advice on how best to handle it.   I have a daemon running as root that services REST API calls (or a web UI from a browser).  An external application first establishes a session by authenticating a user which returns a token/session ID to the caller.   All future REST API calls, supplies the token/session ID which allows them authenticated access to the requested resource.   The token/session ID indicates what user the request is associated with.  Obviously, there can be many users simultaneously issuing requests.

What I need to do is specify the user on each audit log call.   For example, I need to have a way to specify which user is issuing the request when I call audit_log_user_message().  Is this possible?   This is a very common use case and really needs to be handled.

Scott Gulland
916.785.1497
HPE Networking, CEB R&D

8000 Foothills Blvd; MS - 5505
Roseville, CA 95747
USA

Re: Use case not covered by the audit library?

[Steve Grubb]

Hello,

On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> I have a fairly common use case that I'm not sure is covered by the audit
> library and I need some advice on how best to handle it.   I have a daemon
> running as root that services REST API calls (or a web UI from a browser). 
> An external application first establishes a session by authenticating a
> user which returns a token/session ID to the caller.   All future REST API
> calls, supplies the token/session ID which allows them authenticated access
> to the requested resource.   The token/session ID indicates what user the
> request is associated with.  Obviously, there can be many users
> simultaneously issuing requests.
> 
> What I need to do is specify the user on each audit log call.   For example,
> I need to have a way to specify which user is issuing the request when I
> call audit_log_user_message().  Is this possible?   This is a very common
> use case and really needs to be handled.

Would these users be able to interact with the system in any way they please? 
If its not an interactive session, then I don't think its a _system_ event. 
There are perfectly fine application logging frameworks to choose from. The 
main issue is making sure that users cannot influence the records being written 
about what they are doing. 

But if you feel that you really would like to have this in the audit trail, 
then you can use the AUDIT_TRUSTED_APP event type and format the event any way 
that you wish. The audit tools sort of ignore those events because there's no 
telling what's in them.

-Steve

Re: Use case not covered by the audit library?

[Burn Alting]

[-- Attachment #1.1: Type: text/plain, Size: 2324 bytes --]

On 17 Dec 2015 1:24 am, "Steve Grubb" <sgrubb@redhat.com> wrote:
>
> Hello,
>
> On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > I have a fairly common use case that I'm not sure is covered by the
audit
> > library and I need some advice on how best to handle it.   I have a
daemon
> > running as root that services REST API calls (or a web UI from a
browser).
> > An external application first establishes a session by authenticating a
> > user which returns a token/session ID to the caller.   All future REST
API
> > calls, supplies the token/session ID which allows them authenticated
access
> > to the requested resource.   The token/session ID indicates what user
the
> > request is associated with.  Obviously, there can be many users
> > simultaneously issuing requests.
> >
> > What I need to do is specify the user on each audit log call.   For
example,
> > I need to have a way to specify which user is issuing the request when I
> > call audit_log_user_message().  Is this possible?   This is a very
common
> > use case and really needs to be handled.
>
> Would these users be able to interact with the system in any way they
please?
> If its not an interactive session, then I don't think its a _system_
event.
> There are perfectly fine application logging frameworks to choose from.
The
> main issue is making sure that users cannot influence the records being
written
> about what they are doing.
>
> But if you feel that you really would like to have this in the audit
trail,
> then you can use the AUDIT_TRUSTED_APP event type and format the event
any way
> that you wish. The audit tools sort of ignore those events because
there's no
> telling what's in them.
>
> -Steve
>
Scott,

If you have to use auditd as your auditing framework, then can you
a. Test your application running on a system with a comprehensive autiting
posture already deployed. That is take a CAPP configuration and add execve
system call monitoring. I have found applications that extensively use
auditd for application audit, slow down in such an environment.
b. If you use the auditd api then please use well formed key value pair
content in your events. Follow the auditd documentation in this reguard. If
not well formed, tools using auparse () and friends may discard data during
the parsing.

Regard
Burn

[-- Attachment #1.2: Type: text/html, Size: 2777 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Use case not covered by the audit library?

[Gulland, Scott A]

[-- Attachment #1.1: Type: text/plain, Size: 3098 bytes --]

Hi Burn,

From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Burn Alting
Sent: Wednesday, December 16, 2015 11:56 AM
To: Steve Grubb
Cc: linux-audit@redhat.com
Subject: Re: Use case not covered by the audit library?


On 17 Dec 2015 1:24 am, "Steve Grubb" <sgrubb@redhat.com<mailto:sgrubb@redhat.com>> wrote:
>
> Hello,
>
> On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > I have a fairly common use case that I'm not sure is covered by the audit
> > library and I need some advice on how best to handle it.   I have a daemon
> > running as root that services REST API calls (or a web UI from a browser).
> > An external application first establishes a session by authenticating a
> > user which returns a token/session ID to the caller.   All future REST API
> > calls, supplies the token/session ID which allows them authenticated access
> > to the requested resource.   The token/session ID indicates what user the
> > request is associated with.  Obviously, there can be many users
> > simultaneously issuing requests.
> >
> > What I need to do is specify the user on each audit log call.   For example,
> > I need to have a way to specify which user is issuing the request when I
> > call audit_log_user_message().  Is this possible?   This is a very common
> > use case and really needs to be handled.
>
> Would these users be able to interact with the system in any way they please?
> If its not an interactive session, then I don't think its a _system_ event.
> There are perfectly fine application logging frameworks to choose from. The
> main issue is making sure that users cannot influence the records being written
> about what they are doing.
>
> But if you feel that you really would like to have this in the audit trail,
> then you can use the AUDIT_TRUSTED_APP event type and format the event any way
> that you wish. The audit tools sort of ignore those events because there's no
> telling what's in them.
>
> -Steve
>
Scott,

If you have to use auditd as your auditing framework, then can you
a. Test your application running on a system with a comprehensive autiting posture already deployed. That is take a CAPP configuration and add execve system call monitoring. I have found applications that extensively use auditd for application audit, slow down in such an environment.
b. If you use the auditd api then please use well formed key value pair content in your events. Follow the auditd documentation in this reguard. If not well formed, tools using auparse () and friends may discard data during the parsing.

We want to use the audit framework because after all, it is designed to track changes made to a system, and that is exactly what we want to do.  We definitely want to use well formed key-value pairs, but you’ve probably seem my post to Steve.   I don’t know what the “keys” I should be using or what the values for those keys should be.   I’m looking for information on these key-value pairs.  We need to follow the appropriate rules.

Scott

[-- Attachment #1.2: Type: text/html, Size: 6218 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Use case not covered by the audit library?

[Gulland, Scott A]

Hi Steve,

> On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > I have a fairly common use case that I'm not sure is covered by the audit
> > library and I need some advice on how best to handle it.   I have a daemon
> > running as root that services REST API calls (or a web UI from a browser).
> > An external application first establishes a session by authenticating a
> > user which returns a token/session ID to the caller.   All future REST API
> > calls, supplies the token/session ID which allows them authenticated access
> > to the requested resource.   The token/session ID indicates what user the
> > request is associated with.  Obviously, there can be many users
> > simultaneously issuing requests.
> >
> > What I need to do is specify the user on each audit log call.   For example,
> > I need to have a way to specify which user is issuing the request when I
> > call audit_log_user_message().  Is this possible?   This is a very common
> > use case and really needs to be handled.
> 
> Would these users be able to interact with the system in any way they
> please?
> If its not an interactive session, then I don't think its a _system_ event.
> There are perfectly fine application logging frameworks to choose from. The
> main issue is making sure that users cannot influence the records being
> written about what they are doing.
> 
> But if you feel that you really would like to have this in the audit trail, then
> you can use the AUDIT_TRUSTED_APP event type and format the event any
> way that you wish. The audit tools sort of ignore those events because
> there's no telling what's in them.
> 
> -Steve

No, this is an HTTP server that handles standard HTTP requests like GET, POST, PUT, and DELETE.  The URI specifies what resource is being acted upon.  These requests could come from something as simple as curl, or a full blown management application, or a web GUI (which is interactive in the browser).  For example, you could issue a POST request to URI /openswitch/v1/users to create a new user.  The body of the request would contain JSON or XML data indicating the user and password.  There are pre-determined actions/resources that can be changed.   In standard REST APIs, all of the URIs, their parameters and the scheme of the body are documented and only these requests can be issued.

It's based on client/server and the client may or may not be interactive (e.g. a web browser).   In these types of servers, we'd almost exclusively be using the audit_log_user_message() API with an event type of AUDIT_USYS_CONFIG.   We're only logging configuration changes to the switch.   I think I don't understand how the "message" parameter is used in this call.  The man page implies a simple text message, but looking at the audit.log file it appears to consist of a set of key-value pairs.   Is my understanding correct?

My problem is I don't know what the proper set of "keys" are and the values they should contain.  If my assumptions are correct, is there any documentation on on the key-value pairs and how to format the contents of the message parameter?  Based on what I've seen in the audit log file, I would add "acct=<user>" to the contents of the message to reflect the particular authenticated user who issued the REST API call.

Thanks,

Scott

Re: Use case not covered by the audit library?

[Richard Guy Briggs]

On 15/12/17, Gulland, Scott A wrote:
> Hi Steve,
> 
> > On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > > I have a fairly common use case that I'm not sure is covered by the audit
> > > library and I need some advice on how best to handle it.   I have a daemon
> > > running as root that services REST API calls (or a web UI from a browser).
> > > An external application first establishes a session by authenticating a
> > > user which returns a token/session ID to the caller.   All future REST API
> > > calls, supplies the token/session ID which allows them authenticated access
> > > to the requested resource.   The token/session ID indicates what user the
> > > request is associated with.  Obviously, there can be many users
> > > simultaneously issuing requests.
> > >
> > > What I need to do is specify the user on each audit log call.   For example,
> > > I need to have a way to specify which user is issuing the request when I
> > > call audit_log_user_message().  Is this possible?   This is a very common
> > > use case and really needs to be handled.
> > 
> > Would these users be able to interact with the system in any way they
> > please?
> > If its not an interactive session, then I don't think its a _system_ event.
> > There are perfectly fine application logging frameworks to choose from. The
> > main issue is making sure that users cannot influence the records being
> > written about what they are doing.
> > 
> > But if you feel that you really would like to have this in the audit trail, then
> > you can use the AUDIT_TRUSTED_APP event type and format the event any
> > way that you wish. The audit tools sort of ignore those events because
> > there's no telling what's in them.
> > 
> > -Steve
> 
> No, this is an HTTP server that handles standard HTTP requests like GET, POST, PUT, and DELETE.  The URI specifies what resource is being acted upon.  These requests could come from something as simple as curl, or a full blown management application, or a web GUI (which is interactive in the browser).  For example, you could issue a POST request to URI /openswitch/v1/users to create a new user.  The body of the request would contain JSON or XML data indicating the user and password.  There are pre-determined actions/resources that can be changed.   In standard REST APIs, all of the URIs, their parameters and the scheme of the body are documented and only these requests can be issued.
> 
> It's based on client/server and the client may or may not be interactive (e.g. a web browser).   In these types of servers, we'd almost exclusively be using the audit_log_user_message() API with an event type of AUDIT_USYS_CONFIG.   We're only logging configuration changes to the switch.   I think I don't understand how the "message" parameter is used in this call.  The man page implies a simple text message, but looking at the audit.log file it appears to consist of a set of key-value pairs.   Is my understanding correct?
> 
> My problem is I don't know what the proper set of "keys" are and the values they should contain.  If my assumptions are correct, is there any documentation on on the key-value pairs and how to format the contents of the message parameter?  Based on what I've seen in the audit log file, I would add "acct=<user>" to the contents of the message to reflect the particular authenticated user who issued the REST API call.

Well, Steve has published these as a starting point.  I'm sure he'll
chime in when he sees your message.

	http://people.redhat.com/sgrubb/audit/audit-events.txt
	http://people.redhat.com/sgrubb/audit/audit-parse.txt

> Thanks,
> 
> Scott

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

Re: Use case not covered by the audit library?

[Steve Grubb]

On Thursday, December 17, 2015 01:10:03 AM Richard Guy Briggs wrote:
> > No, this is an HTTP server that handles standard HTTP requests like GET,
> > POST, PUT, and DELETE.  The URI specifies what resource is being acted
> > upon.  These requests could come from something as simple as curl, or a
> > full blown management application, or a web GUI (which is interactive in
> > the browser).  For example, you could issue a POST request to URI
> > /openswitch/v1/users to create a new user.  The body of the request would
> > contain JSON or XML data indicating the user and password.  There are
> > pre-determined actions/resources that can be changed.   In standard REST
> > APIs, all of the URIs, their parameters and the scheme of the body are
> > documented and only these requests can be issued.>
> > 
> >
> > It's based on client/server and the client may or may not be interactive
> > (e.g. a web browser).   In these types of servers, we'd almost
> > exclusively be using the audit_log_user_message() API with an event type
> > of AUDIT_USYS_CONFIG.   We're only logging configuration changes to the
> > switch.   I think I don't understand how the "message" parameter is used
> > in this call.  The man page implies a simple text message, but looking at
> > the audit.log file it appears to consist of a set of key-value
> > pairs.   Is my understanding correct?>
> > 
> >
> > My problem is I don't know what the proper set of "keys" are and the
> > values they should contain.  If my assumptions are correct, is there any
> > documentation on on the key-value pairs and how to format the contents of
> > the message parameter?  Based on what I've seen in the audit log file, I
> > would add "acct=<user>" to the contents of the message to reflect the
> > particular authenticated user who issued the REST API call.
> Well, Steve has published these as a starting point.  I'm sure he'll
> chime in when he sees your message.
> 
>         http://people.redhat.com/sgrubb/audit/audit-events.txt
>         http://people.redhat.com/sgrubb/audit/audit-parse.txt

Thanks for pointing these out, Richard.

The basic guidance for AUDIT_USYS_CONFIG is to record old and new values. 
Typically old values are prefixed with 'old-' and new values are the name of 
the field with no prefix. 

Any field that the user could influence the value has to be handled in such a 
way as to not allow them to trick the parser if they are malicious. For the 
most part, we hex encode those fields and then write some code to label the 
fields as encoded so that interpretation can be done later.

Since your field names may not be official names in the audit system, you may 
have to filter illegal characters the user sent during event construction and 
fill in spaces with an underscore or dash.

-Steve

RE: Use case not covered by the audit library?

[Gulland, Scott A]

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Thursday, December 17, 2015 6:51 PM

> > > My problem is I don't know what the proper set of "keys" are and the
> > > values they should contain.  If my assumptions are correct, is there
> > > any documentation on on the key-value pairs and how to format the
> > > contents of the message parameter?  Based on what I've seen in the
> > > audit log file, I would add "acct=<user>" to the contents of the
> > > message to reflect the particular authenticated user who issued the REST
> API call.
> > Well, Steve has published these as a starting point.  I'm sure he'll
> > chime in when he sees your message.
> >
> >         http://people.redhat.com/sgrubb/audit/audit-events.txt
> >         http://people.redhat.com/sgrubb/audit/audit-parse.txt
> 
> Thanks for pointing these out, Richard.
> 
> The basic guidance for AUDIT_USYS_CONFIG is to record old and new values.
> Typically old values are prefixed with 'old-' and new values are the name of
> the field with no prefix.
> 
> Any field that the user could influence the value has to be handled in such a
> way as to not allow them to trick the parser if they are malicious. For the
> most part, we hex encode those fields and then write some code to label the
> fields as encoded so that interpretation can be done later.
> 
> Since your field names may not be official names in the audit system, you
> may have to filter illegal characters the user sent during event construction
> and fill in spaces with an underscore or dash.

Thanks for the feedback and information.  It has been very helpful.  I've done
some testing using a "val" and "old-val" field names with data values encoded
by audit_encode_nv_string(...).  However, when I try to display the event with
"ausearch --interpret ..." neither field's data is decoded back into asci text.  So 
I plan on using the "op", "data" and "euid" fields.   Only the data field needs to
encoded and ausearch does decode this field correctly.  My message text
would look like:

    "op=<op text> data=<encoded data> euid=<uid>"

When I was using ausearch I expected to be able to find events by uid using
either the "-ua" or "-ue" option that would match the euid field's value, but no
matching events were found.  Is this expected behavior?  The "-I" option did
correctly convert the euid into the user name.

Scott G.

Re: Use case not covered by the audit library?

[Steve Grubb]

On Tuesday, January 05, 2016 09:59:25 PM Gulland, Scott A wrote:
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > Sent: Thursday, December 17, 2015 6:51 PM
> > 
> > > > My problem is I don't know what the proper set of "keys" are and the
> > > > values they should contain.  If my assumptions are correct, is there
> > > > any documentation on on the key-value pairs and how to format the
> > > > contents of the message parameter?  Based on what I've seen in the
> > > > audit log file, I would add "acct=<user>" to the contents of the
> > > > message to reflect the particular authenticated user who issued the
> > > > REST
> > 
> > API call.
> > 
> > > Well, Steve has published these as a starting point.  I'm sure he'll
> > > chime in when he sees your message.
> > > 
> > >         http://people.redhat.com/sgrubb/audit/audit-events.txt
> > >         http://people.redhat.com/sgrubb/audit/audit-parse.txt
> > 
> > Thanks for pointing these out, Richard.
> > 
> > The basic guidance for AUDIT_USYS_CONFIG is to record old and new values.
> > Typically old values are prefixed with 'old-' and new values are the name
> > of the field with no prefix.
> > 
> > Any field that the user could influence the value has to be handled in
> > such a way as to not allow them to trick the parser if they are
> > malicious. For the most part, we hex encode those fields and then write
> > some code to label the fields as encoded so that interpretation can be
> > done later.
> > 
> > Since your field names may not be official names in the audit system, you
> > may have to filter illegal characters the user sent during event
> > construction and fill in spaces with an underscore or dash.
> 
> Thanks for the feedback and information.  It has been very helpful.  I've
> done some testing using a "val" and "old-val" field names with data values
> encoded by audit_encode_nv_string(...).  However, when I try to display the
> event with "ausearch --interpret ..." neither field's data is decoded back
> into asci text.

It has to be a field name that auparse expects to be encoded.


> So I plan on using the "op", "data" and "euid" fields.  

euid would be a kernel originating field name. User space could lie about it. 
The kernel is the only thing that knows the truth.


> Only the data field needs to encoded and ausearch does decode this field
> correctly.  My message text would look like:
> 
>     "op=<op text> data=<encoded data> euid=<uid>"
> 
> When I was using ausearch I expected to be able to find events by uid using
> either the "-ua" or "-ue" option that would match the euid field's value,  
but no matching events were found.  Is this expected behavior?

What is the record type? ausearch is optimized to expect certain record types 
to have fields in a specific order.


> The "-I" option did correctly convert the euid into the user name.

Interpreting and searching are different areas of the code base and are 
independent. Interpreting is done after searching. No need to interpret fields 
that will never be output.

-Steve

RE: Use case not covered by the audit library?

[Gulland, Scott A]

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, January 06, 2016 8:29 AM
> 
> On Tuesday, January 05, 2016 09:59:25 PM Gulland, Scott A wrote:
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > > Sent: Thursday, December 17, 2015 6:51 PM
> > >
> > > The basic guidance for AUDIT_USYS_CONFIG is to record old and new
> values.
> > > Typically old values are prefixed with 'old-' and new values are the
> > > name of the field with no prefix.
> > >
> > > Any field that the user could influence the value has to be handled
> > > in such a way as to not allow them to trick the parser if they are
> > > malicious. For the most part, we hex encode those fields and then
> > > write some code to label the fields as encoded so that
> > > interpretation can be done later.
> > >
> > > Since your field names may not be official names in the audit
> > > system, you may have to filter illegal characters the user sent
> > > during event construction and fill in spaces with an underscore or dash.
> >
> > Thanks for the feedback and information.  It has been very helpful.
> > I've done some testing using a "val" and "old-val" field names with
> > data values encoded by audit_encode_nv_string(...).  However, when I
> > try to display the event with "ausearch --interpret ..." neither
> > field's data is decoded back into asci text.
> 
> It has to be a field name that auparse expects to be encoded.
> 
> 
> > So I plan on using the "op", "data" and "euid" fields.
> 
> euid would be a kernel originating field name. User space could lie about it.
> The kernel is the only thing that knows the truth.

Unfortunately, that is not true for HTTP servers which run as root but
authenticates the true user issuing the REST request.   The authentication is
done through PAM.  The HTTP server then carries out the action on behalf 
of that user.   The kernel thinks it's a root user, but the HTTP server knows
otherwise.   It sounds like there is no way for a trusted user app to inject
the correct uid into the audit event.   Would you recommend I use the
"user" field instead of "euid" to indicate who is issuing the request?

> > Only the data field needs to encoded and ausearch does decode this
> > field correctly.  My message text would look like:
> >
> >     "op=<op text> data=<encoded data> euid=<uid>"
> >
> > When I was using ausearch I expected to be able to find events by uid
> > using either the "-ua" or "-ue" option that would match the euid
> > field's value,
> but no matching events were found.  Is this expected behavior?
> 
> What is the record type? ausearch is optimized to expect certain record types
> to have fields in a specific order.

I am using the AUDIT_USYS_CONFIG event type as I would like to use
"aureport -c" to get a summary of the configuration changes to the switch.
As an alternative, I could use the AUDIT_TRUSTED_APP event type.

Scott G.
> 
> > The "-I" option did correctly convert the euid into the user name.
> 
> Interpreting and searching are different areas of the code base and are
> independent. Interpreting is done after searching. No need to interpret
> fields
> that will never be output.

Re: Use case not covered by the audit library?

[Steve Grubb]

On Wednesday, January 06, 2016 06:03:58 PM Gulland, Scott A wrote:
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > It has to be a field name that auparse expects to be encoded.
> > 
> > > So I plan on using the "op", "data" and "euid" fields.
> > 
> > euid would be a kernel originating field name. User space could lie about
> > it. The kernel is the only thing that knows the truth.
> 
> Unfortunately, that is not true for HTTP servers which run as root but
> authenticates the true user issuing the REST request.   The authentication
> is done through PAM.  The HTTP server then carries out the action on behalf
> of that user.   The kernel thinks it's a root user, but the HTTP server
> knows otherwise.   It sounds like there is no way for a trusted user app to
> inject the correct uid into the audit event.   Would you recommend I use
> the "user" field instead of "euid" to indicate who is issuing the request?
> > > Only the data field needs to encoded and ausearch does decode this
> > > 
> > > field correctly.  My message text would look like:
> > >     "op=<op text> data=<encoded data> euid=<uid>"
> > > 
> > > When I was using ausearch I expected to be able to find events by uid
> > > using either the "-ua" or "-ue" option that would match the euid
> > > field's value,
> > 
> > but no matching events were found.  Is this expected behavior?
> > 
> > What is the record type? ausearch is optimized to expect certain record
> > types to have fields in a specific order.
> 
> I am using the AUDIT_USYS_CONFIG event type as I would like to use
> "aureport -c" to get a summary of the configuration changes to the switch.
> As an alternative, I could use the AUDIT_TRUSTED_APP event type.

The USYS_CONFIG event is like this:

type=USYS_CONFIG msg=audit(1389095562.552:540): pid=2249 uid=0 auid=4325 ses=1  
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=change-system-
time exe="/usr/sbin/hwclock" hostname=? addr=? terminal=pts/0 res=success'


The kernel supplies all the pieces up to the msg= portion. After that is what 
you build. The only real field the event writer does is the op= field, The rest 
are supplied by libaudit. Ausearch does not parse the op= field.

What I would suggest in a case like this is to create a small utility that 
generates the exact report that you want. The auparse library makes that super 
easy. I can dig up the skeleton code for something like this if you want.

-Steve



> > > The "-I" option did correctly convert the euid into the user name.
> > 
> > Interpreting and searching are different areas of the code base and are
> > independent. Interpreting is done after searching. No need to interpret
> > fields
> > that will never be output.

RE: Use case not covered by the audit library?

[Gulland, Scott A]

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, January 06, 2016 12:06 PM
>
> > > euid would be a kernel originating field name. User space could lie
> > > about it. The kernel is the only thing that knows the truth.
> >
> > Unfortunately, that is not true for HTTP servers which run as root but
> > authenticates the true user issuing the REST request.   The authentication
> > is done through PAM.  The HTTP server then carries out the action on
> behalf
> > of that user.   The kernel thinks it's a root user, but the HTTP server
> > knows otherwise.   It sounds like there is no way for a trusted user app to
> > inject the correct uid into the audit event.   Would you recommend I use
> > the "user" field instead of "euid" to indicate who is issuing the request?
> > > > Only the data field needs to encoded and ausearch does decode this
> > > >
> > > > field correctly.  My message text would look like:
> > > >     "op=<op text> data=<encoded data> euid=<uid>"
> > > >
> > > > When I was using ausearch I expected to be able to find events by
> > > > uid using either the "-ua" or "-ue" option that would match the
> > > > euid field's value,
> > >
> > > but no matching events were found.  Is this expected behavior?
> > >
> > > What is the record type? ausearch is optimized to expect certain
> > > record types to have fields in a specific order.
> >
> > I am using the AUDIT_USYS_CONFIG event type as I would like to use
> > "aureport -c" to get a summary of the configuration changes to the switch.
> > As an alternative, I could use the AUDIT_TRUSTED_APP event type.
> 
> The USYS_CONFIG event is like this:
> 
> type=USYS_CONFIG msg=audit(1389095562.552:540): pid=2249 uid=0
> auid=4325 ses=1
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> msg='op=change-system- time exe="/usr/sbin/hwclock" hostname=?
> addr=? terminal=pts/0 res=success'
> 
> 
> The kernel supplies all the pieces up to the msg= portion. After that is what
> you build. The only real field the event writer does is the op= field, The rest
> are supplied by libaudit. Ausearch does not parse the op= field.
> 
> What I would suggest in a case like this is to create a small utility that
> generates the exact report that you want. The auparse library makes that
> super easy. I can dig up the skeleton code for something like this if you want.

Thanks Steve!   I'd appreciate the skeleton code.   At some point we'll probably
want to create a custom report capability.   It sounds like ausearch really only 
handles the fields written by the kernel.

Scott G.

Re: Use case not covered by the audit library?

[Steve Grubb]

On Wednesday, January 06, 2016 08:27:31 PM Gulland, Scott A wrote:
> > What I would suggest in a case like this is to create a small utility that
> > generates the exact report that you want. The auparse library makes that
> > super easy. I can dig up the skeleton code for something like this if you
> > want.
>
> Thanks Steve!   I'd appreciate the skeleton code.   At some point we'll
> probably want to create a custom report capability.   It sounds like
> ausearch really only handles the fields written by the kernel.

Sorry for the delay, I needed to get the 2.5 package out the door.

There is some example code in the audit package and here:
https://fedorahosted.org/audit/browser/trunk/contrib/plugin/audisp-example.c

If you wanted to read from a file, then you change the code to 

        f = fopen("./test.log", "r");
        if (f == NULL) {
                printf("Can't open log\n");
                return 1;
        }

but keep the AUSOURCE_FEED. Then in the loop

                /* Now the event loop */
                 if (!stop && !hup && retval > 0) {
                        if (fgets_unlocked(tmp, MAX_AUDIT_MESSAGE_LENGTH, f)) {
                                auparse_feed(au, tmp, strnlen(tmp,
                                                MAX_AUDIT_MESSAGE_LENGTH));
                        }
                } else if (retval == 0)
                        auparse_flush_feed(au);
                if (feof(f))
                        break;

Then you put the report in the callback function. You can switch between the
types as shown in the handle_event function.

If you want it to run off of logs, then you would need to structure things a
bit different. The aulastlog program shows a good example of that:

https://fedorahosted.org/audit/browser/trunk/tools/aulastlog/aulastlog.c

Hope this helps...

-Steve