[refpolicy] semaphores

[refpolicy] semaphores

[Russell Coker]

type=AVC msg=audit(1302788046.768:5309): avc:  denied  { unix_read unix_write 
} for  pid=6009 comm="mplayer" key=5678293  
scontext=abc:user_r:user_t:s0:c0.c255-s0:c0.c511 
tcontext=abc:user_r:mozilla_t:s0:c0.c255-s0:c0.c511 tclass=sem

In Debian we have a policy based on the 20100524 release.  The above is the 
result of trying to run mplayer after doing something in a web browser that 
uses sound (Youtube on Chromium in this case).

Apart from allowing mozilla_t and user_t to access each other's semaphores, 
rewriting the sound libraries, and using ipcrm, how can we solve this?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] semaphores

[Christopher J. PeBenito]

On 4/14/2011 10:15 AM, Russell Coker wrote:
> type=AVC msg=audit(1302788046.768:5309): avc:  denied  { unix_read unix_write
> } for  pid=6009 comm="mplayer" key=5678293
> scontext=abc:user_r:user_t:s0:c0.c255-s0:c0.c511
> tcontext=abc:user_r:mozilla_t:s0:c0.c255-s0:c0.c511 tclass=sem
>
> In Debian we have a policy based on the 20100524 release.  The above is the
> result of trying to run mplayer after doing something in a web browser that
> uses sound (Youtube on Chromium in this case).
>
> Apart from allowing mozilla_t and user_t to access each other's semaphores,
> rewriting the sound libraries, and using ipcrm, how can we solve this?

I don't see any options beyond what you said.  I assume mplayer fails 
due to this denial?  If so, I'm not sure I see what the problem with 
allowing it is.  Of course I'd rather not, but its not as bad as if the 
access were the other way around.  User_t already has to interact with 
mozilla_t.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com