On Tuesday 20 December 2005 18:29, Alexey Tarasov <glorg(a)bk.ru> wrote:
Problem 2.
ping is called by bash script, executed by cron with root rights (comand
line: ping -c 1 -w 5 > /dev/null )
---
type=AVC msg=audit(1133295301.930:2739): avc: denied { write } for
pid=30341 comm="ping" name="[56893]" dev=pipefs ino=56893
scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0
tclass=fifo_file
type=AVC msg=audit(1133295301.930:2739): avc: denied { read } for
pid=30341 comm="ping" name="[56892]" dev=pipefs ino=56892
scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0
tclass=fifo_file
allow domain crond_t:fifo_file rw_file_perms;
An obvious solution to this would be to grant permissions somewhat equivalent
to the above (actually we would not grant that, but it would creep towards it
over time). But that sort of thing isn't what we really desire.
I'm wondering whether the design of cron is ideal in this regard. Maybe it
would be better if the functionality of collecting output and sending the
email would be better performed after dropping privs. It would be easy
enough to write a little program that spawns a program, collects it's output,
and then email's such output (if any) to a specified address and then have
cron call such a program. This would result in reducing the amount of code
in the cron daemon (IE reducing the amount of code running with significant
privs that can break the entire system if it is compromised), providing a
neat email utility that can be used for other purposes, and making the SE
Linux policy cleaner at the same time.
What do you think of this idea?
PS Please write two emails about two problems with two different subjects in
future.
--
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