Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 438840

Summary: sec-policy/selinux-logwatch lacks correct fcontext
Product: Gentoo Linux Reporter: Stan Sander <stsander>
Component: SELinuxAssignee: Sven Vermeulen (RETIRED) <swift>
Status: VERIFIED FIXED    
Severity: normal CC: alunduil, selinux
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: sec-policy r6
Package list:
Runtime testing required: ---

Description Stan Sander 2012-10-18 19:42:57 UTC
Been a while since I've had time to deal with SELinux, but am getting back to it.  Seems that the selinux-logwatch module does not contain the correct file context label for the logwatch executable, /usr/sbin/logwatch.pl When running logwatch from cron, this results in the process running as system_cronjob_t instead of the correct logwatch_t.  This produces a myriad of denials and improper behavior by logwatch when launched from cron.  

Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4666): avc:  denied  { write } for  pid=3629 comm="logwatch.pl" name="logwatch" dev="sda3" ino=6317669 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir
Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4667): avc:  denied  { add_name } for  pid=3629 comm="logwatch.pl" name="logwatch.SPo7fGYl" scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir
Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4668): avc:  denied  { create } for  pid=3629 comm="logwatch.pl" name="logwatch.SPo7fGYl" scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir
Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4669): avc:  denied  { setattr } for  pid=3629 comm="logwatch.pl" name="logwatch.SPo7fGYl" dev="sda3" ino=6292067 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir
Oct 18 00:05:02 iax kernel: type=1400 audit(1350540302.024:4670): avc:  denied  { create } for  pid=3631 comm="sh" name="maillog-archive" scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=file
Oct 18 00:05:02 iax kernel: type=1400 audit(1350540302.024:4671): avc:  denied  { append open } for  pid=3631 comm="sh" path="/var/cache/logwatch/logwatch.SPo7fGYl/maillog-archive" dev="sda3" ino=6292403 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=file


By adding a file context rule to label /usr/sbin/logwatch.pl as logwatch_exec_t the process is then allowed to transition to logwatch_t and then runs normally
Comment 1 Alex Brandt (RETIRED) gentoo-dev 2012-10-18 21:13:56 UTC
I'm guessing this is due to a move of the executable to /usr/sbin/logwatch.pl.  The current policies show that this script is expected in /usr/share/logwatch/scripts/logwatch\.pl:

/usr/share/logwatch/scripts/logwatch\.pl        --      gen_context(system_u:object_r:logwatch_exec_t, s0)

Full:

/usr/sbin/logcheck      --      gen_context(system_u:object_r:logwatch_exec_t,s0)
/usr/sbin/epylog        --      gen_context(system_u:object_r:logwatch_exec_t,s0)

/usr/share/logwatch/scripts/logwatch\.pl        --      gen_context(system_u:object_r:logwatch_exec_t, s0)

/var/cache/logwatch(/.*)?       gen_context(system_u:object_r:logwatch_cache_t, s0)

/var/lib/logcheck(/.*)? gen_context(system_u:object_r:logwatch_cache_t,s0)
/var/lib/epylog(/.*)?   gen_context(system_u:object_r:logwatch_cache_t,s0)

/var/lock/logcheck.*    gen_context(system_u:object_r:logwatch_lock_t,s0)

/var/run/epylog\.pid    --      gen_context(system_u:object_r:logwatch_var_run_t,s0)

The full filecontext file shows that there is no rule in the logwatch.fc policy covering /usr/sbin/logwatch.pl.

Should we change the policy to include both locations or simply update it to have the new location?
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2012-10-19 08:22:14 UTC
Just adding the context to it should be sufficient; we'll need to "support" some form of backwards compatibility anyhow. I've sent it upstream, and since it's a contrib module it'll get in rather quickly.
Comment 3 Sven Vermeulen (RETIRED) gentoo-dev 2012-10-19 15:26:27 UTC
Merged upstream, will be in r6
Comment 4 Sven Vermeulen (RETIRED) gentoo-dev 2012-11-03 17:37:31 UTC
In hardened-dev, r6 release
Comment 5 Sven Vermeulen (RETIRED) gentoo-dev 2012-11-18 15:26:46 UTC
In main tree, ~arch'ed
Comment 6 Sven Vermeulen (RETIRED) gentoo-dev 2012-12-13 10:12:59 UTC
r8 is now stable