RE: Re: Use case not covered by the audit library?
by Maupertuis Philippe
I am new to the subject of user audit record.
I have some newbie questions.
Is it possible to generate these records in any language , python or java for example ?
Where can I find example or newbie documentation ?
Regards
Philippe
-----Message d'origine-----
De : linux-audit-bounces(a)redhat.com [mailto:linux-audit-bounces@redhat.com] De la part de linux-audit-request(a)redhat.com
Envoyé : vendredi 18 décembre 2015 18:00
À : linux-audit(a)redhat.com
Objet : Linux-audit Digest, Vol 135, Issue 9
Send Linux-audit mailing list submissions to
linux-audit(a)redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/linux-audit
or, via email, send a message with subject or body 'help' to
linux-audit-request(a)redhat.com
You can reach the person managing the list at
linux-audit-owner(a)redhat.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of Linux-audit digest..."
Today's Topics:
1. Re: Use case not covered by the audit library? (Steve Grubb)
2. Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check (Burn Alting)
3. Re: New draft standards (Burn Alting)
4. Re: Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check (Steve Grubb)
----------------------------------------------------------------------
Message: 1
Date: Thu, 17 Dec 2015 21:51:15 -0500
From: Steve Grubb <sgrubb(a)redhat.com>
To: "Gulland, Scott A" <scott.gulland(a)hpe.com>
Cc: Richard Guy Briggs <rgb(a)redhat.com>, "linux-audit(a)redhat.com"
<linux-audit(a)redhat.com>
Subject: Re: Use case not covered by the audit library?
Message-ID: <1484204.GzGFVCTWQh@x2>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 2
Date: Fri, 18 Dec 2015 14:20:44 +1100
From: Burn Alting <burn(a)swtf.dyndns.org>
To: "linux-audit(a)redhat.com" <linux-audit(a)redhat.com>
Subject: Simple bug fix for PROCTITLE not being recognised with
ausearch --debug check
Message-ID: <1450408844.14944.4.camel(a)swtf.swtf.dyndns.org>
Content-Type: text/plain; charset="utf-8"
Steve,
When ausearch is given the --debug option, malformed events are written to stderr. The PROCTITLE type record is considered to be malformed. This patch corrects for this.
8 years, 10 months
Weird timestamp length constraint in auparse.c
by Santosh Ananthakrishnan
Hi list
auparse breaks if supplied events with timestamps that are less than 10
characters long, including the milliseconds field. This should never happen
in production, but it can make for fairly mysterious output during testing
if you're generating your own timestamp and eventid numbers :-)
I think the issue is in the str2event function:
static int str2event(char *s, au_event_t *e)
{
char *ptr;
errno = 0;
ptr = strchr(s*+10*, ':');
if (ptr) {
e->serial = strtoul(ptr+1, NULL, 10);
This function seems to be searching for the colon that splits the timestamp
from the eventId, but it's starting at s+10, instead of just s. The
variable s points to the first byte after the "msg=audit(" prefix. (10 also
happens to be the length of that prefix, which is what made me suspicious
this might not be micro-optimization)
-Santosh
8 years, 10 months
SELinux/audit kernel repo process changes
by Paul Moore
In an effort to make it a bit easier to maintain the kernel-secnext COPR I'm
making some slight changes to how I manage the SELinux and audit kernel
repositories. The downside is that there is now going to be a regular rebase
as part of the release cycle, but at least it will be well defined and part of
the process, unlike the current reactionary rebases.
Starting with the next merge window, I'll be following the process below:
1. When a new kernel is released, rebase the repository's upstream branch to
the tagged kernel release (or the latest LSM upstream branch in the case of
SELinux) and apply the next branch on top of the upstream branch. Send a pull
request for the upstream branch to the next level maintainer.
2. Create a new branch, stable-X.XX, a copy of the upstream branch that was
sent during the merge window.
3. Reset the next branch to the upstream branch that was sent during the merge
window. At this point the upstream, next, and latest stable-X.XX branch
should be identical.
4. Accept patches into both the stable-X.XX and next branches; as necessary,
send pull requests for stable-X.XX to the next level maintainer. Continue
until the next kernel is released and the process repeats.
As in the past, this process is subject to change, but I'm hopeful that this
approach should work for the foreseeable future.
--
paul moore
www.paul-moore.com
8 years, 10 months
Re: Wrong audit message type when policy is reloaded
by Laurent Bigonville
I guess I should have CCed the linux-audit mailing list from the start.
As said in my initial mail (see bellow) wheb SELinux user object manager
are reloading the policy, an audit message with a wrong type is logged
USER_AVC vs USER_MAC_POLICY_LOAD.
Le 06/11/15 17:29, Stephen Smalley a écrit :
> On 11/06/2015 11:10 AM, Laurent Bigonville wrote:
>> Hi,
>>
>> When the policy is reloaded, systemd and dbus are sending a USER_AVC
>> audit event instead of a USER_MAC_POLICY_LOAD one.
>>
>> Looking at an other object manager (the xserver) it uses the following
>> code:
>> http://cgit.freedesktop.org/xorg/xserver/tree/Xext/xselinux_hooks.c#n300
>>
>> Can we really link SELINUX_INFO to AUDIT_USER_MAC_POLICY_LOAD? Is there
>> a better way to achieve this?
>>
>> An downstream bug has been opened:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1195330
>
> I think when they introduced the audit support, they should have added
> a new type value in libselinux for MAC_POLICY_LOAD, and then they
> could have handled this cleanly in their callback functions. That is
> what I would do. I guess now we have to figure out how to do so
> compatibly...
>
>
8 years, 10 months
Audit Framework and namespaces
by Gulland, Scott A
Does the audit framework work with linux namespaces?
Scott Gulland
HP Networking, CEB R&D
916.785.1497
Hewlett-Packard Company
8000 Foothills Blvd; MS - 5505
Roseville, CA 95747
USA
[hp]<http://www.hp.com/>
8 years, 10 months
