Discussion:
Logging from within kernel
Ranran
2018-11-23 23:47:25 UTC
Permalink
Hello,

Is it possible to log all messages from within kernel, (without any
userspace application and daemon) ?

Thank you,
Ran
Richard Guy Briggs
2018-11-25 17:06:03 UTC
Permalink
Post by Ranran
Hello,
Is it possible to log all messages from within kernel, (without any
userspace application and daemon) ?
No. The log messages leave the kernel via the audit netlink socket and
get consumed by a userspace process.

There is no facility to write it directly to disk in the kernel if that
is what you are asking.
Post by Ranran
Ran
- RGB

--
Richard Guy Briggs <***@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Paul Moore
2018-11-26 16:48:08 UTC
Permalink
Post by Ranran
Hello,
Is it possible to log all messages from within kernel, (without any
userspace application and daemon) ?
If you are not running an audit daemon then the audit records will be
written to kernel's ring buffer (look for them in dmesg). This is not
really considered ideal (e.g. one drawback is that the output is rate
limited), but it can be attractive for small systems with a limited
number of audit events; last I checked this is the approach used by
Android.

If you want to configure the audit subsystem beyond the "audit=1/0" on
the kernel command line, or whatever systemd is doing these days, you
will need to use auditctl (or a similar tool). Unfortunately the
in-kernel audit subsystem does a number of really awful things when it
comes to the netlink interface so that generic netlink tools can not
be used to configure the audit subsystem, you must use an audit
specific tool.
--
paul moore
www.paul-moore.com
William Roberts
2018-11-26 17:05:51 UTC
Permalink
Post by Paul Moore
Post by Ranran
Hello,
Is it possible to log all messages from within kernel, (without any
userspace application and daemon) ?
If you are not running an audit daemon then the audit records will be
written to kernel's ring buffer (look for them in dmesg). This is not
really considered ideal (e.g. one drawback is that the output is rate
limited), but it can be attractive for small systems with a limited
number of audit events; last I checked this is the approach used by
Android.
Not since the official merge into mainline. I wrote a libaudit port
and Android's
logd system uses it. It pulls them up from audit into userspace, does some stuff
and send them out to log cat and back down to dmesg (I have no idea why).

It also does things like make sure any denials seen are tracked by a
bug and outputs
the bug information in the log.

If you have the AOSP tree checked out, you can see it:
system/core/logd/LogAudit.cpp
Post by Paul Moore
If you want to configure the audit subsystem beyond the "audit=1/0" on
the kernel command line, or whatever systemd is doing these days, you
will need to use auditctl (or a similar tool). Unfortunately the
in-kernel audit subsystem does a number of really awful things when it
comes to the netlink interface so that generic netlink tools can not
be used to configure the audit subsystem, you must use an audit
specific tool.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit
Paul Moore
2018-11-26 17:54:16 UTC
Permalink
On Mon, Nov 26, 2018 at 12:06 PM William Roberts
Post by William Roberts
Post by Paul Moore
Post by Ranran
Hello,
Is it possible to log all messages from within kernel, (without any
userspace application and daemon) ?
If you are not running an audit daemon then the audit records will be
written to kernel's ring buffer (look for them in dmesg). This is not
really considered ideal (e.g. one drawback is that the output is rate
limited), but it can be attractive for small systems with a limited
number of audit events; last I checked this is the approach used by
Android.
Not since the official merge into mainline. I wrote a libaudit port
and Android's logd system uses it ...
Good to know, thanks!
--
paul moore
www.paul-moore.com
Continue reading on narkive:
Loading...