On 08/29/2010 05:00 PM, Mr Dash Four wrote:
> its a fifo_file on device pipefs with name/path: pipe:[11951]
>
> This type of internal communication is very common. We use the following
> policy for this:
>
> allow voip_sandbox_t self:fifo_file rw_fifo_file_perms;
>
This worked, though I get the following AVC when starting the process:
type=AVC msg=audit(1283088703.670:16403): avc: denied { execmem } for
pid=1847 comm="voip_sandbox"
scontext=unconfined_u:system_r:voip_sandbox_t:s0
tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process
type=SYSCALL msg=audit(1283088703.670:16403): arch=40000003 syscall=90
per=400000 success=no exit=-13 a0=8e997d4 a1=bfc01000 a2=bfc00000
a3=1ff000 items=0 ppid=1845 pid=1847 auid=0 uid=496 gid=496 euid=496
suid=496 fsuid=496 egid=496 sgid=496 fsgid=496 tty=(none) ses=1
comm="voip_sandbox" exe="/usr/local/bin/voip_sandbox"
subj=unconfined_u:system_r:voip_sandbox_t:s0 key=(null)
Even though the 2 spawned processes are still in memory (though nothing
works) when I try to terminate the application nothing happens and when
I try to reboot I get this in the audit log:
type=AVC msg=audit(1283088703.670:16404): avc: denied { signal } for
pid=1847 comm="voip_sandbox"
scontext=unconfined_u:system_r:voip_sandbox_t:s0
tcontext=unconfined_u:system_r:voip_sandbox_t:s0 tclass=process
Tried to add 'allow voip_sandbox_t self:process { execmem signal };' but
that did not help one iota - I am getting the same avcs!
writing policy requires testing. i usually do my testing in permissive
mode or with permissive domains.
basically in my initial policy i declare type for know object and
subjects, i make the types usable. Then i add file context
specifications so that the objects are labelled properly. in my initial
policy i also define the domain transitions.
Then i usually test in permissive mode. collect as many AVC denials as i
can and then translate them into human readable policy and extend the
policy module, rebuild, reload and start over again, test, collect,
extend, build, install etc.