[opensuse-security] No time stamps in audit.log?
Hello, it seems events in audit.log do not have time stamps. This makes analyzing events a bit uncomfortable I think. Can you make the audit system somehow to add a time stamp to logged events? Just like in /var/log/messages. Thanks
On Tue, Sep 02, 2014 at 06:22:47PM +0200, pinguin74 wrote:
Hello,
it seems events in audit.log do not have time stamps. This makes analyzing events a bit uncomfortable I think.
Can you make the audit system somehow to add a time stamp to logged events? Just like in /var/log/messages.
It is there ... :) type=AVC msg=audit(1409728889.981:41): apparmor="STATUS" operation="profile_load" name="/usr/share/gitweb/gitweb.cgi" pid=655 comm="apparmor_parser" The timestamp is 1409728889.981 $ date --date="@1409728889.981" Wed Sep 3 09:21:29 CEST 2014 $ Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Am 03.09.2014 09:44, schrieb Marcus Meissner:
On Tue, Sep 02, 2014 at 06:22:47PM +0200, pinguin74 wrote:
Hello,
it seems events in audit.log do not have time stamps. This makes analyzing events a bit uncomfortable I think.
Can you make the audit system somehow to add a time stamp to logged events? Just like in /var/log/messages.
It is there ... :)
type=AVC msg=audit(1409728889.981:41): apparmor="STATUS" operation="profile_load" name="/usr/share/gitweb/gitweb.cgi" pid=655 comm="apparmor_parser"
The timestamp is 1409728889.981
$ date --date="@1409728889.981" Wed Sep 3 09:21:29 CEST 2014
Is this their goal, to make reading the log file as hard as possible? Why not encrypt it with AES to be sure you can´t read it.....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-09-04 00:46, pinguin74 wrote:
The timestamp is 1409728889.981
$ date --date="@1409728889.981" Wed Sep 3 09:21:29 CEST 2014
Is this their goal, to make reading the log file as hard as possible?
Because it is faster for reading it by software, I'd guess. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQHoyQACgkQtTMYHG2NR9VmpACfTBiqN3CyjslMMaPCkGLUT25N V7sAnRo6CJ6hrK3fUnZTmm0H5WsHOmY7 =T00g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 09/03/2014 07:24 PM, Carlos E. R. wrote:
On 2014-09-04 00:46, pinguin74 wrote:
The timestamp is 1409728889.981
$ date --date="@1409728889.981" Wed Sep 3 09:21:29 CEST 2014
Is this their goal, to make reading the log file as hard as possible?
Because it is faster for reading it by software, I'd guess.
In particular if you are sticking those fields into some sort of database and indexing on the 'timestamp'. I realise that sophisticated databases can index date fields but they do so by converting the YY/MM/DD:HH:NN:SS,ss into a an integer and converting it back on display. So why not start with the integer? In a corporate setting syslog or whatever can be throwing a lot of records and the delay of having to do that conversion before stuffing the record in the database will slow things down. Why database? There are tools that can do interesting things in a corporate setting like look for a penetration coming in though firewall, switch host application. All very automated. Most of us just look at the syslog files of a single machine as in "why is that application misbehaving", but there is a whole business of detecting attacks. I mean, after all, this is apparmor we are talking about here, not vanilla syslog, so it *is* about attacks. -- shin (n): A device for finding furniture in the dark. -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 2014-09-04 01:53, Anton Aylward wrote:
On 09/03/2014 07:24 PM, Carlos E. R. wrote:
On 2014-09-04 00:46, pinguin74 wrote:
The timestamp is 1409728889.981
$ date --date="@1409728889.981" Wed Sep 3 09:21:29 CEST 2014
Is this their goal, to make reading the log file as hard as possible?
Because it is faster for reading it by software, I'd guess.
In particular if you are sticking those fields into some sort of database and indexing on the 'timestamp'.
I realise that sophisticated databases can index date fields but they do so by converting the YY/MM/DD:HH:NN:SS,ss into a an integer and converting it back on display. So why not start with the integer?
Well, a database can be processed "offline", or delayed, so processing time is not that crucial. But logs have to be written fast. Not formatting a field makes it just a bit faster, and also a bit faster to read (and understand) by another process, if needed. But syslog not always writes to a plain text file, it can write to binary databases as well. These take more processing to create, so optimizing starts to become important... After all, you record some type of longint, not a text string. Way, way faster.
In a corporate setting syslog or whatever can be throwing a lot of records and the delay of having to do that conversion before stuffing the record in the database will slow things down.
Yep. :-)
Why database? There are tools that can do interesting things in a corporate setting like look for a penetration coming in though firewall, switch host application. All very automated. Most of us just look at the syslog files of a single machine as in "why is that application misbehaving", but there is a whole business of detecting attacks.
I mean, after all, this is apparmor we are talking about here, not vanilla syslog, so it *is* about attacks.
And, when apparmour starts logging a , it slows down the processes it is watching, I believe. The processes can not go ahead faster than those events are written, they have to wait - so everything crawls. Thus writing those events fast is important. This is a guess, I haven't verified it, but an educated guess. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 09/03/2014 08:16 PM, Carlos E. R. wrote:
And, when apparmour starts logging a , it slows down the processes it is watching, I believe. The processes can not go ahead faster than those events are written, they have to wait - so everything crawls. Thus writing those events fast is important. This is a guess, I haven't verified it, but an educated guess.
I've worked in those settings and yes it matters! Our great hate was the old DEC stuff that sent multi line "status" and "completion" announcements -- I can't call them nice neat syslogs or records such as we are discussing in this thread -- with lots of junk, rather than the stripped down raw data. Just stuffing all that in the database was a PIG. Well those old machines were slow compared to a modern intel server. Archaic accounting software that *had* to be supported since the brokerage firm wouldn't let go. Heck, one keen programmer coded up a replacement in perl. It was faster! Mind you, a shell script would be faster! But noooooo, they wouldn't let go. We hated that machine. Even the poor guy who, in a weak moment, admitted he had once, long ago, syadmin'd them and so got lumped with doing it again in there-and-now hated them. Career limiting move, that, poor guy. *WE* wanted to turn off the logging since it was slowing down the log database parser, but noooooo. I don't know what happened in the end. I transferred, the guys that installed and ran it transferred ... I suspect that poor sysadmin found another job elsewhere. Of course to the people in Mahogany Row who bought out that brokerage firm such implementation and operation details never matter. Right until they get to the point where they have no sysadmin and it falls over. They never really figure "Operational Risk" in that sense, do they? -- helicopter (n): 30,000 parts in tight orbit around a hydraulic fluid leak, waiting for metal fatigue to set in. -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Thu, Sep 04, 2014 at 12:46:47AM +0200, pinguin74 wrote:
Am 03.09.2014 09:44, schrieb Marcus Meissner:
On Tue, Sep 02, 2014 at 06:22:47PM +0200, pinguin74 wrote:
Hello,
it seems events in audit.log do not have time stamps. This makes analyzing events a bit uncomfortable I think.
Can you make the audit system somehow to add a time stamp to logged events? Just like in /var/log/messages.
It is there ... :)
type=AVC msg=audit(1409728889.981:41): apparmor="STATUS" operation="profile_load" name="/usr/share/gitweb/gitweb.cgi" pid=655 comm="apparmor_parser"
The timestamp is 1409728889.981
$ date --date="@1409728889.981" Wed Sep 3 09:21:29 CEST 2014
Is this their goal, to make reading the log file as hard as possible? Why not encrypt it with AES to be sure you can´t read it.....
This logfile needs be easily machine readable without ambiguities, and human readable timestamps are kind of harder to parse than just seconds since 1970. It is assumed that tools will be used to post-process it, e.g. aureport or aa-logprof or others. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Is this their goal, to make reading the log file as hard as possible? Why not encrypt it with AES to be sure you can´t read it.....
This logfile needs be easily machine readable without ambiguities, and human readable timestamps are kind of harder to parse than just seconds since 1970.
It is assumed that tools will be used to post-process it, e.g. aureport or aa-logprof or others.
Ok. When I use aureport --mac I get only "no events of interest were found". Currently I use less, tail and grep to read audit.log. I read there is a GUI tool audit-viewer, but it seems not available at openSUSE. What convenient way do you suggest to read audit logs? Especially for AppArmor. Thanks
Hello, Am Donnerstag, 4. September 2014 schrieb pinguin74:
What convenient way do you suggest to read audit logs? Especially for AppArmor.
Personally, I let logdigest mail me the interesting parts of audit.log (which basically means grep -v $boring_lines). For something that is easier readable, I can recommend aa-notify -v -s 1 which would also make a nice cron.daily if you do aa-notify -v -s 1 | mail -s "AppArmor report" root (see aa-notify --help or man aa-notify for details and other options) Regards, Christian Boltz -- Erfinder und Entwickler sind von Natur aus faul, denn Erfindern und Entwickler, entwickeln Dinge, die das Leben einfacher machen sollen. Die Hauptinitiative hierfür ist meist Faulheit. [http://miraspostgresqlwelt.blogspot.com/2011/09/technische-unterschiede-post...] -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Am 05.09.2014 00:43, schrieb Christian Boltz:
Hello,
Am Donnerstag, 4. September 2014 schrieb pinguin74:
What convenient way do you suggest to read audit logs? Especially for AppArmor.
Personally, I let logdigest mail me the interesting parts of audit.log (which basically means grep -v $boring_lines).
For something that is easier readable, I can recommend
aa-notify -v -s 1
Ah, okay, works. I just thought, aa-notify gives a graphical popup note on the desktop? I gues it can´t do that? Oh, wait, I have a cool idea, I will pipe the aa-notify output to KDE KWrite and create a new KWrite color highlighting schema, this way I get a optical nice log file output! And with sudo´ed I even don´t need the root password!
Hello, Am Sonntag, 7. September 2014 schrieb pinguin74:
Am 05.09.2014 00:43, schrieb Christian Boltz:
Am Donnerstag, 4. September 2014 schrieb pinguin74:
What convenient way do you suggest to read audit logs? Especially for AppArmor.
Personally, I let logdigest mail me the interesting parts of audit.log (which basically means grep -v $boring_lines).
For something that is easier readable, I can recommend
aa-notify -v -s 1
Ah, okay, works.
I just thought, aa-notify gives a graphical popup note on the desktop? I gues it can´t do that?
It can do both ;-)
Oh, wait, I have a cool idea, I will pipe the aa-notify output to KDE KWrite and create a new KWrite color highlighting schema, this way I get a optical nice log file output! And with sudo´ed I even don´t need the root password!
Just to make it clear, "-s 1" gives you a summary of the last day.
If you want real-time desktop notifications, use
sudo aa-notify -p --display $DISPLAY
Regards,
Christian Boltz
--
Jetzt kriege ich es echt mit der Angst: da gibt es Zeilen in meinem
Code der identisch mit dem von SCO ist, etwa ein "include
participants (6)
-
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Marcus Meissner -
pinguin74