Chris PeBenito a écrit :
On Sun, 2008-04-20 at 12:12 +0200, François Valenduc wrote:
[EMAIL PROTECTED] a écrit :
type=1400 audit(1208682664.167:223): avc: denied { read write } for
pid=29607 comm="hwclock" path="/var/log/faillog" dev=dm-6 ino=271083
scontext=root:system_r:hwclock_t tcontext=system_u:object_r:faillog_t
tclass=file
This is just an error about hwclock being unable to write to "faillog" so
there must be something that goes wrong (making hwclock want to write to
faillog).
I also got this error:
type=1400 audit(1208679707.497:84): avc: denied { read } for
pid=18454 comm="hwclock" path="/dev/urandom" dev=tmpfs ino=2059
scontext=root:system_r:hwclock_t
tcontext=system_u:object_r:urandom_device_t tclass=chr_file
However, I think I solved it by issuing the commands "setsebool -P
global_ssp 1" and "load_policy"
This is becouse you have the hardened toolchain, compiling everything with
PIE/SSP by default. SSP want a random number (picked from /dev/urandom)
when the binaries start. SELinux disables access to urandom per default so
you have to (as you did with sebool) tell SELinux that your system is
compiled with SSP and thus the access to urandom should be permitted.
Yes, this has been solved with sebool. However, I still got the second
error (related to faillog). It also blocks distccd like this: (even if
the corresponding selinux policy is loaded):
type=1400 audit(1208681304.633:191): avc: denied { read write } for
pid=27886 comm="distccd" path="/var/log/faillog" dev=dm-6 ino=271083
scontext=root:system_r:distccd_t tcontext=system_u:object_r:faillog_t
tclass=file
Do you know how to solve this second type of errors ?
Thanks for your help.
Seems weird that either of these programs would be writing to faillog,
since that file is usually for logging login failures. Do you have any
idea why this might be happening on your system?
So, since it's not expected that these programs wil write to faillog,
selinux prevent that. I don't have any idea why this is happening. I
don't know the internals of these programs. How could I find the reason
? Maybe a bad configuration of syslog-ng ?
François Valenduc
--
gentoo-hardened@lists.gentoo.org mailing list
