initlog and syslogd performance with setfiles
by Russell Coker
Initlog can save up a large number of log entries (particularly if logging a
SE Linux relabel). If these are processed by syslogd synchronously then the
performance is very poor and the system apparently can be running for quite a
while before the boot messages are logged. Another possible issue is the
memory use of initlog, if using a machine with the minimum recommended RAM
(256M) it is not inconceivable that initlog could run out of memory which
would probably break things in a bad way (relabel happens before swapon).
This was brought to my attention when a RHEL4 user spoke of the "feature"
whereby the files would be relabeled in the background. Of course it turned
out that the relabelling was not happening in the background it was merely
the logging that was happening after the system boot.
I think it would make sense to have this data written directly to a log file
under /var/log (/var/log/setfiles or something).
How about the following:
LOGFILE=/var/log/setfiles
SYSLOGFLAG=""
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
18 years, 6 months
- 2
- 1
strict policy problem
by Richard Hally
would someone please fix the problem with firefox and thunderbird not
starting when using the latest strict
policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages
from audit.log when trying to start them
Thanks,
Richard Hally
type=AVC msg=audit(1128231114.093:32): avc: denied { execmod } for
pid=2731 comm="firefox-bin" name="libxpcom_core.so" dev=dm-0 ino=3965047
scontext=richard:staff_r:staff_mozilla_t:s0-s0:c0.c127
tcontext=system_u:object_r:shlib_t:s0 tclass=file
type=SYSCALL msg=audit(1128231114.093:32): arch=40000003 syscall=125
success=no exit=-13 a0=e9c000 a1=e0000 a2=5 a3=bfd2a710 items=0 pid=2731
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin"
type=AVC_PATH msg=audit(1128231114.093:32):
path="/usr/lib/firefox-1.5/libxpcom_core.so"
-----------------------------------------------------------
type=AVC msg=audit(1128231322.472:40): avc: denied { execmod } for
pid=2869 comm="thunderbird-bin" name="libxpcom_core.so" dev=dm-0
ino=3701297 scontext=richard:staff_r:staff_thunderbird_t:s0-s0:c0.c127
tcontext=system_u:object_r:shlib_t:s0 tclass=file
type=SYSCALL msg=audit(1128231322.472:40): arch=40000003 syscall=125
success=no exit=-13 a0=739000 a1=e0000 a2=5 a3=bfe1ebc0 items=0 pid=2869
auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 comm="thunderbird-bin"
exe="/usr/lib/thunderbird-1.5/thunderbird-bin"
type=AVC_PATH msg=audit(1128231322.472:40):
path="/usr/lib/thunderbird-1.5/libxpcom_core.so"
18 years, 6 months
- 4
- 7
devel's mcs breaks prelink and FC4 compat
by Alexandre Oliva
I've been running FC devel forever. Ever since mcs was introduced,
prelink has started displaying odd behavior: it would fail to set the
context for some of the linked binaries and crash at the end. Some
time ago, I put some time aside to investigate the issue.
As it turned out, prelink would getxattr("selinux.context") for the
old binary, and setxattr the new binary with the same context. For
some reason, for binaries whose context did not end in :s0, the
setxattr was denied.
Running restorecon -F or chcon would reset the context of the binary
correctly, enabling prelink to run; a simple fixfiles relabel would
not; perhaps fixfiles -F relabel would, but I didn't try that.
Oddly, even after I cleaned up all binaries to enable a full prelink
run to complete successfully, after additional updates installed by
yum, new libraries and binaries were introduced that fail to prelink,
and I have to reset their contexts to get :s0 added in order for it to
succeed.
Since I'm told the mcs thingie was designed to not require relabeling
and to be totally transparent, I thought I'd report this. I'm just
not sure what package to file it against in bugzilla.
Thoughts?
For reference, here's the command I used to get all contexts reset.
It can run for hours, so beware.
rm -f /tmp/prelink.restorecon.log; while /usr/sbin/prelink -av -mR -q 2>&1 | tee /tmp/prelink.log; sed -n 's,/usr/sbin/prelink: Could not set security context for \(.*\): Invalid argument,\1,p' /tmp/prelink.log | xargs restorecon -v -F | tee -a /tmp/prelink.restorecon.log | grep .; do cmp /tmp/prelink.log /tmp/prelink.log.prev && break; mv -f /tmp/prelink.log /tmp/prelink.log.prev; done
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
18 years, 6 months
- 2
- 2