System: Gentoo SELinux
Kernel: selinux-sources-2.4.25-r2
Patch: evlog-1.4.2_kernel2.4.20.patch
EVLog Version: v1.6.0
I've come across a couple of issues:
As the docs state, to get evlog to handle user-space
syslog messages, one must call the /sbin/slog_fwd
script, which creates a reference to
"/lib/libevlsyslog.so.1" within /etc/ld.so.preload
1) Upon compiling and installing v1.6.0 of evlog,
/lib/libevlsyslog.so.0.0.0 is created, but the
/etc/ld.so.preload reference will not work until
/lib/libevlsyslog.so.1 points to /lib/libevlsyslog.so.0.0.0
2) Once fixed, the /etc/ld.so.preload reference
proceeds to work within the system -- until the system
is rebooted. Upon the next reboot, /sbin/init tries to
call /lib/libevlsyslog.so.0.0.0 and the following error
message is produced:
Can't open stat
Kernel panic: Attempted to kill init!
The error originates within the file:
evlog-1.6.0/usr/libevlsyslog/libevlsyslog.c
Specifically, line 407 within the _evlSysGetProcId()
function:
if ((fd = open("/proc/self/stat", O_RDONLY)) == -1) {
fprintf(stderr, "Can't open stat\n");
exit(1);
}
Basically, it seems that the library is attempting to
find out which CPU processor ID /sbin/init is currently
running from, by accessing the /proc/self/stat
dynamically created file.
The only problem is, at the time when /sbin/init is
running, the /proc filesystem has not been mounted yet,
so the reference does not work.
Since, I don't particularly care which CPU ID is
recorded by evlog, I simply uncommented your assignment
on line 258 and commented the assignment on line 259.
entry.log_processor = 0;
/* entry.log_processor = _evlSysGetProcId(); */
As a more permantent fix, I'm not sure how
libevlsyslog.so.0.0.0 would obtain information about
the CPU processor ID from within a bare-bones context
such as /sbin/init; however, I'd advise against
referencing files that might not exist this early in
the bootup process.
If /proc must be used, then you may need to tackle
mounting and verification of that operation before
information can be queried from it.
Regards,
Darien Kindlund
InfoSec Engr/Scientist
The MITRE Corporation
kindlund@mitre.org